This was a reply to another post, but I believe it's of general interest.
Why do managers keep asking for test cases or test case counts? One answer is that testers keep providing them... because managers keep asking for them... because testers keep providing them... because managers keep asking for them...
But this is nuts, because just as recipes are not cooking, test cases are not testing!
("Test Cases Are Not Testing: Toward a Culture of Test Performance" by James Bach & Aaron Hodder https://lnkd.in/gBtnTXkK)
Imagine you're a cook, and you work for rich and somewhat impulsive client who wants you to create a new meal every day. This evening's meal is based your skills and tools on the one hand, and the client's preferences on the other — including a main ingredient the client selects and has delivered to you in the morning.
In that context, preparation is good. It's important to have your tools in order, and to make sure your pantry and your fridge are well supplied.
What matters most, though, is skill, because you don't get a lot of notice about the client's main ingredient, and the client's preferences for the style of cooking may change from day to day too. You're going to have to work with that — and such recipes as you might have won't help. That's okay; skilled cooks can deal with whatever's available for each new assignment. They treat recipes like historical artifacts; like suggestions.
Just in case you need help with the parallels: the client is your testing client. The new main ingredient is the product you're testing. The dish you produce is your evaluation of the product; your test report. Your fridge, pantry, and tools are your test lab. The recipes are test cases.
Here's a set of heuristics on how to break out of the test case loop:
Learn the product by all means available, performing thought experiments before it's available, and interacting with it when it is. Study it — and everything you can find out about it — systematically. Probe below the surfaces. Develop models and take notes.
While doing so, actively look for problems about the product. Fear not; you will find them (unless you believe that products can be perfect, in which case I can't help you).
Then, when someone asks for a test case count, start by offering a list of problems about the product, ranked in order of significance. Explain how each one can affect the business. As you do so, explain how you found each problem; where you looked for it and how you recognized it. Don't downplay the role of serendipitous discovery; acknowledge it.
If the person doesn't care about the problems you've found, engage them on the subject of what does matter to them, and act on that—unless the answer is only "test cases", "test case counts", or "pass-fail ratios". Then my advice would be to start looking for another job.
The addiction can be addressed. Read more here: https://lnkd.in/g9xfGam
If you're a manager or tester, and want help with this, I'm here. :)
