No I do not think they are the same as code. Let’s start with why. Code is your product. That is the thing that actually runs in production. Test Cases are indicators of work. A written test case with no other work is useless. It is only when a tester have performed the test case in a specific context that it becomes something. Code will be executed in production even when the developers go home.
That being said, depending on your situation you might want to treat them similar to code, for similar reasons. On that note. Can you change a test case. Given this scenario. You have version A of a product and you tested that using test case TC1 (version A), next week the software is updated so you want to test version B with a variation of TC1. If you update that to version B. How do you know what you did when you tested it on version A? Since the test case is a placeholder for work. Just because you change the placeholder does not mean that you changed that work. So if you are using your test cases as documentation of what you did. You cannot change it since they will no longer be correct.
This is a good example of where you really want to reuse versioning and version control systems from code to also keep track of what happens to your test cases.
Also the utility of test cases when you do not keep them updated is of course less than if you do. So keeping them clean as in remove unwanted ones and update changed ones is typically a good thing to do. But again it depends on what you use them for.
I do think test cases are similar to software code (both manual and automated cases). @nito404, You rightly pointed out different ways it could be similar. Just to add to what you already mentioned.
The test cases could be stored in the same location as your development code in Git. In my previous company we wrote all manual and automated tests cases in Gherkin format (Given, When, Then) and some were automated and some were manually tested. All these were stored in Git along with development code in separate folders. Just like development code we had reviews and put in PR’s (Pull Requests) for it. They had to be approved before merging it
I have also worked in projects where we had separate stories for automation tasks. This is because they required considerable effort in terms of coding and testing them as well just like development/feature code. The stories had requirements and acceptance criteria just like development code. I wrote about some of these aspects in this article - https://www.infoq.com/articles/quick-guide-atdd/.