Testing.....WHO? ME?

Testing.....WHO? ME?

Being into the IT industry for the past 4 years now has given me a fair idea of testing and the advantages it brings with it. But one thing that I have never done is thinking about what would be the best way to design a test case document, is there any formal definition of a test case, what all should a test case not have and so on.

Recently when I was given this responsibility of managing a project, i really thought of giving it a thought. We were supposed to implement ISO 9001:2000 in our project and this meant documenting each and everything, and test cases form an integral part of the software development life cycle. So, let me rephrase the statement as "I was FORCED to give it a thought".

A test case is an entity which fully tests all the related aspects of a requirement in an application-be it functionality, be it UI, be it database. In other words, it tests ALL the aspects of a feature or requirement. It includes:

• The reason why the test is being done.
• The process that would be followed for doing the test.
• The scenarios that would arise out of performing a particular test.
• The criteria which would decide when a test has failed.
• The criteria which would decide when a test has succeeded.
• Any specific software and hardware requirements for the test.
• The assumptions that have been done in order to write the test cases.

This is too much of work to do-right? So, then who knows about the project so much that he can write the test case document? The project manager? Does he have all the time to write these test cases? I dont think so...I can feel this now that I am doing project management. In most of the cases, it is mostly a Quality Analyst/Engineer or a team of QAs who sit down along with the Project Manager/Leader, understand the functionality of the entire task and then accordingly write the test cases. Once the test cases have been put down by the QA team, the document has to be reviewed by the peers.

Figure 1.0 lists a sample detailed test case document which the QA of my team Vidya Nair wrote for one on the various modules of the existing application I am working on.

Once the test cases have been reviewed by the peers, it should function as a tool to help the developers in their development. This is one reason why I believe a QA team has a BIG role in delivering the product bug-free and with the best quaity on time. One of the issues, which stops a QA engineer from coming up with a good test case is the plethora of information available to him/her. The key here, I guess is to "work smart"-Pick out the most important scenarios and frame your test cases accordingly-think about the scenarios which are critical for the application to function and work on them first. Then, if you have sufficient time, you can work on more test cases having a lower priority.