Show Me a Good Test Case

Test cases are usually crap. They have been planned poorly and written even worse!

If you do not believe my claim, feel free to try it out yourself:

Make 100 test cases and give three different testers the same assignment of running them.

All three test cycles are very likely to give out different results. Running them takes every tester a different amount of time, and the pass/fail ratio in the tests differ from each other. I would be as bold as to wager that the number of reported bugs with each tester varies.

When one stops to think about it for a moment, the reason is obvious. The maker of these tests is usually someone else than the test runner. The danger lies in that only a marginal portion of test writers is actually good at programming people’s behavior. The depictions in test cases seldom succeed in giving each reader the same visual image of the test’s goals, background and methods of execution.

Planning accurate test cases is for this reason therefore very risky business. Going for accurate test case specs is often given reasons of accumulating good and comparable history information, especially from regression-type testing. Yet, the people who run these tests often switch and along with that, the test results. In a traditional specs-based testing process a whole lot of work time is consumed by checking the test results and normalizing them.

It can be reasonable way to spend time only when the project’s billing principle is hourly and the client has an endless supply of money.

Therefore I recommend thinking about the problem mentioned earlier with each project. The solution can be discovered with for example:

  1. Each tester runs only test cases they have planned themselves. Procedures made by themselves are usually understood the right way. This ends up saving time from checking test results and normalizing them.
  2. Refrain from making too accurate test cases. Take up, for example, checklists in test case scenarios, or become familiar with threaded process model. This way you save time from both test result checks and normalizing, but from test specs and the review.

Funny. At this moment, I don’t know what a good test case is. Do you?

Software testing

Pay It Forward:

Leave a comment