10 reasons why we really don’t need test cases
Time and again we see people talking about Test cases. You talk to testers working on automation, you hear they are working on converting previously written “manual” test cases. You talk to testers not working on automation, you hear they are working on writing test cases. You hear managers demanding test cases so much so that it becomes an important criteria during appraisals. There is this mad rush to have test cases for everything. Now the real question is
Are test cases required?
Test cases are not required. Here are some thoughts about Test cases…
Detailed test cases are something that do not add value to testing so instead write test ideas and mission statements. These test ideas could be just in the form of scenarios with acceptance criteria. This allows us to focus on real Testing because Testing ≠ Test cases
So what actually is my problem with written test cases?
First and foremost, written test cases restrict my thinking to what has been written. As a tester, we want to keep thinking (inside the box, outside the box and around the box) and a written test case does not allow me to do that. Also we need to look past a pass or fail as testing is not just about passing or failing tests. With test cases it is a mindset to think in terms of pass or fail and that’s where I feel that the thinking is restricted. When I talk about Test ideas I am referring to scenarios which are more like experiments with the following elements : experiment design, modeling of the application (whether you do mental modeling or simulation) and application of critical thinking and system thinking to explore the product more and learn about it thereby also discovering unknowns alongside anomalies. This I feel is restricted with test cases.
In discussions with several other testers on this subject and some of the points made by those who advocate the usage of test cases are listed below with my reservations/rebuttals
1. I can refer back anytime what was tested — You can refer to the test idea and the mission to give you the same information.
2. New joiners can refer to understand the application — Let us be very honest here. How many of us in our careers have learnt about a new product/project by studying the test cases? Not many we would think. I believe most of us learn more about the new product/project by exploring the product. The test ideas/mission and corresponding test reports (not bug reports) serve as a guideline for the exploration. Every tester has his/her way of thinking… giving them written test cases creates bias and restricts thinking.
Yes it makes some sense when you are validating certain SOPs (standard operating procedures) especially in highly regulated industries. You can have a checklist to validate SOPs. I am guessing a checklist is what is being referred to as a test case here however IMO a good tester would/should actually question the SOP. Personally, I would in fact challenge the test case itself.
3. What to automate — why are written checks the basis of automation? if a proper feasibility analysis is carried out then that should give you enough information about the 5W1H (what why when where who and how) of automation. You do not need scripted test cases for that. Besides why is automation restricted to conversion of so-called “manual test cases” to automation scripts? Automation is much more than that. Of course you can think of automating mundane repeatable tasks but you can also think about harnessing the power of automation in test data generation, test results collation, test report creation and much more.
4. Shows your testing approach/skill — Unfortunately it only shows your paraphrasing skills when you change the language from that in the requirements to preparing a checklist. There is not much of critical thinking/ analytical thinking/ reasoning/ questioning in this. As a tester you would not want to be forced to think a certain way.
5. An accepted and verified document — Accepted and verified by whom? How does an accepted and verified document add value to my testing is the question. Minimum required documentation is something that is recommended so that I can focus on some actual testing. If you are talking about the stakeholders, then I would work on my test report to show them what I have done… have logs, screenshots and/or recording of my work.
6. Helps a tester to not miss out on a case as compared to testing done without anything planned — Certainly having a plan of action/mission/ goal helps but you don’t need a test case for that you need a plan/mission/goal instead.
7. Defines scope of testing — this IMO is a weaker argument to make that the premise of testing is decided by a scripted test case. As indicated before, it restricts the testers and limits the thinking . The scope of testing is primarily decided by the answer to the question — is the customer’s problem solved?
8. Developers can refer before checkin to make sure they have covered everything they need to — The same can be done with test ideas… or developers can have their checklist. A detailed test case does not add value. Instead what would help is the tester pairing up with the developer and sharing his/her test ideas with the developer and seeking their feedback on the same.
9. Avoid duplication of effort if a similar story comes — A test case does not avoid the duplication in effort. a review of the test ideas certainly does. A more collaborative effort is what I would again emphasize on a collaborative approach to testing.
10. Input for Traceability matrix — A traceability matrix may provide a link between and test/ check however it may not be conclusive enough in ascertaining that the requirements are correct/complete. My test ideas would include asking questions about the requirements with focus on the actual needs of the customer and trying to find out if I am actually solving the problems of the questions. This should put to rest any questions one may have about coverage as well. You don’t really need test cases to measure coverage. You can measure coverage based on your test ideas. Besides, actual test coverage is also about assessing risk coverage alongside mere requirements.
With these said in essence I would not spend time in detailed test cases. Instead I would focus on establishing/enhancing testability and actually testing. My choice and recommendation would be test ideas with well defined missions/goals.
Now that’s my perspective, what do you think?
