Consider the situation. You have your application ready to start tests and you have a bunch of nice test cases. You meet with your QA team where you see some fresh faces so you are about to tell them how you’d like them to do tests, especially how they should use your nice test cases. What do you say?
I’d tell them to forget about test cases for the first iteration of testing.
Why? It’s not because I believe the main value of writing test cases is the writing part. It’s not even about one of shortcomings of unit tests – risk of turning creativity off and blindly following the scenario.
The reason why I’d like to see my fresh QA team left unguided at the beginning is that I get a pretty unique occasion to have an unbiased eye to look at the application. Someone who doesn’t start with scenarios proposed by designers of the app and considered during development. Someone who just tries to figure things out and hits the wall hard with her head if there’s any.
Of course it works better with freshmen but even when you work with people who actually created test cases the advice is the same. After some time they won’t remember every detail they had thought of when designing tests. They’ll be back in the starting point, except they’ll be working on the real application, not the set of requirements or user stories. And that will make them think differently.
After the first iteration of tests go back to your test cases and tell QA people to go through them. Odds are they’ll be able to check out many of them after the first stage. It’s important to make sure that areas omitted during “figuring things out” part of testing are covered. After all writing part may be the most important but isn’t the only reason to write test cases.
You can also check: What is the main benefit of writing test cases?