Tags

A tester’s rendezvous with test-case is like an unending affair. Whether manual or automation, almost everything that a tester does is related explicitly or implicitly to a test case. It could be :

* Checking Testability of Requirement: inception of  a test case.

* Analysing Requirements to gather Test ideas/scenarios.

* Writing a Test Case.

* Execution a Test Case.

* Logging a defect when a test case fails.

* Picking a Test Case for Automation.

* Automating a Test Case.

* Reporting on Test Activities.

Life goes round and round around a test case!!!

As such, writing test cases should be THE most important thing for any tester and for any project. Consequently, it would seem obvious to allocate a large portion of time on this task.  Ironically,  although test cases are important but that does not justify the call for  unscrupulously   spending hell lot of time on it.

I do not abhor writing test cases at all and do acknowledge their importance. At the same time, doing adequate quality testing is more important. In simpler terms, I am against writing test cases where a test case has 20+ steps , each having a corresponding expected result and is bundled with loads of pre-conditions and test data. Its just ridiculous waste of time.

A good tester is gold on any project and we save gold for special ocassions, don’t we?? Hence, every minute of a tester’s time should be spent in working to improve the Product’s quality.  I don’t advocate writing mile long test cases for following reasons:

1. A test case which hard codes everything right from test data to steps kills all the creativity of tester and limits what can be done. Frankly speaking, (and I know every tester reading this would agree with me!!) , during test case execution, a tester is tempted to do something not scripted in the bloody test case! And these things exist for almost all test cases. So, when we won’t really follow test cases line-by-line, why wasting time to write so much of detail?

2. Blindly following only the scripted test cases accounts for bug slippage. Like “Complete Requirements are as mythical as unicorns” , so are Test Cases. Test Cases should only contain just enough information to ignite the tester’s mind and give him opportunity to explore and experiment. Tester’s focus should be on the system and its behaviour rather than on the script during execution.

3. What value does OVER-ELABORATED test cases bring to your Project? I think it is a wasteful practice to some extent. A good inquisitive, detail oriented tester will work equally well with a high level test cases/ scenarios in bullet points/decision table/checklists , basically anything less expensive to create than those test cases. Actually a mindless Robot only would need all the spoonfeeding in form of test cases!!

4. Finally, it saves time, as simple as that. The time saved can be spent on grilling down your software for more bugs or anything more productive for a tester as an individual and for the team/project/organisation.

Tester must write test cases but should not get obsessed with it so much that  the very purpose they are supposed to serve is defeated.

Advertisements