Saw a good article on the websitehttp://www.sqablogs.com/portal.php. share it here for us. I found this website in our 51testing forums.
Software testing is about executing a set of test cases which are well documented and probably anyone after a few rounds of rehearsal can do it well. While practitioners would not agree with this since in practice, you dont find all the bugs from documented test cases. At most you document the basic workflows or the core cases but its not realistic to assume that one would be able to document all the test cases. Typically you would document the ones which are most important, so the big questions is that ‘how much to document’.
I am sure all of us have been into a situation where we found a bug at some crucial time and then everyone would want to look at test cases and while the witch hunting is going on, you as a test manager wonder that we never document everything. So after testing for many years and then managing a small team and complete products, here are some tips on test-case documentation.
1. Divide the functionality-area into sub-area keywords rather then writing sentences. So if one has to test a login screen then start with listing sub-areas as Albhabets, Numerics, Alphamuerics, Blanks, Special Chars, High Ascii Chars, Unicode Chars, UI guidelines, Button etc rather then listing cases as
- Enter a name comprising of ‘Albhapbets’ and click OK and then see….blabla.
Its not worth it. While testing you would not benefit from long sentences and its assumed that the idea is to cover everything and find bugs rather then write well made sentences. The downside is that over time, it may not make sense as functionality area changes hands. It would be difficult for a new person to understand the context from just keywords but the cost of writing clear-complete sentences is not worth the pain and need.
2. Have check-lists of first level actions. So make a list of all the buttons which you can click and while executing just keep ticking off from the list.
3. Dont write simple straight cases or the ones which you know would get covered as you do the complex ones. I have seen so many times where you would see loads n loads of these simple cases. They are not worth documenting, esp in a bulky format.
4. Keep the format simple. Dont add too many fields like Title, Step By Step Procedure, Area, Sub Area, Kind of Test, OS, Milestone etc etc. Think and prioritize a list based on your goal. The goal is to find bugs in areas which users are going to exercise.
5. Dont go over-board in keeping results. Though for a fast changing project, it might help to isolate a break, it might not be worth it over a long period of time.
6. Keep updating the test case document, not only by adding cases but by also removing the unwanted ones. Keep it trimmed and live and meaningful.
