Test cases - written or not - in general have a basic form:
- Actual test
The first design of a test case considers all of these, explicitly or implicitly. As you design the test case, you think about how to get the software into an interesting situation (prerequisites and setup), what might happen or not happen (test), and look at what occurs when you actually try this (results). The next release, when you're doing a similar test - following a script or whether you simply want to explore the same thing - you don't tend to think as deeply. You assume the same prerequisites and setup, and you do the test. Much of the time, this is okay. In particular if you're doing regression testing where you're looking for lack of change, that's generally fairly safe.
However, it's not complete.
Something has changed every time you redo a test. It might not be obvious what it is, or it might be as straightforward as a new build you're testing. Either way, the entire test case deserves consideration. Don't just redo a test. Redo the prerequisites and the setup analysis, too. You'll find more that way.