Tuesday, August 7, 2012

Why not to create Test Documentation


Before you read further, I would like you to do a small exercise. For each product/release that you have tested, calculate an approximate number for,
  1. Total no of Test documents you have written till date.
  2. Total no of test cases you've written.
  3. If it takes 5 minutes to write one test case along with the scripts, then total time consumed?
  4. Last time the scripts were updated



Once you are over the excitement of the numbers that you see in front of yourself and for those who could imagine how large the number would be and didn’t bother to calculate, answer yourself, what usually happens when the product/feature is released?

Usually, important/happy cases are documented in the regression pack, which is usually automated in many cases. From then onwards, the feature test documentation is not used anymore. Then why do we spend so much time on it? Let me try to answer this.

  • The most obvious reason is that the management has asked us to do so because the piece of documentation is getting the company money or “billing the client”. We all like to earn money but is that the end goal?
  • We might be writing it because this is what testers have been doing for past so many years. The problem with this is that no one questions what they’re doing and gladly accept what they have been taught by their seniors.



What do we usually achieve when we try to follow the above process?

  1. Missed Deadlines because we were so busy writing test scripts and getting them reviewed from the customer that we forgot to test the product
  2. Heated discussion with the developers regarding why they did not mention it in the FSD in the first place?
  3. A Buggy product
  4. An unhappy end user and customer


If the above points doesn’t seem so convincing to you, then ask yourself, “Do I like to write test documentation?” If your answer is still Yes, then I hope god is with the product that you have tested. 


What could you do instead of wasting time in test documentation?
  • Take time in understanding the requirements. Create a mind map.
  • Have a question & answer round with the requirements analyst.
  • Have a debate with the Developers
  • Test to explore the product. Yes, I clearly meant to say, practice exploratory testing.


I don’t have a goal to change the world, but if you are passionate about testing and want to test the product instead of wasting your time in writing how to test the product, then do think about it.



1 comment:

  1. Hi Anuj,

    nice article which shows that the daily testing practics are in a process of radical and massive changes and this process is still ongoing! Modern testing means: less documentation, more testing itself! Modern testing keywords are: rapid software testing (including exploratory testing of course), build your mind sets, testing model, agile testing, context driven testing (school), ...
    So I'm completly agree with you.
    If you like, you can follow my testing blog.
    (thespiritoftesting.wordpress.com)

    kind regards from a passionate tester from Germany, Ralf

    ReplyDelete