During my initial testing days, I did not show much interest in preparing documents and I have come across many others who shared the same thoughts.
What do we mean by testing documentation? I define it as “ a proof that speaks about the tests we perform”
If a tester maintains the document for the work he did, then he could be in a state to explain the status of his work at any given point of time. Now, what if the tester fails to do it and the reports are demanded by any stakeholder?
Here I will share a personal experience of how a test document helped us to overcome an issue faced during a particular project.
Our team was working on a product that went live with a few new features and some bug fixes. We were also testing the products in a production environment just to make sure that things were working as intended.
There were multiple crashes due to the syncing of data between the database and cloud, leading to the situation where the app stopped responding properly. This was observed in the testing phase before the release and was reported to the development team.
But the same was observed even after the product went live and many end-users starting facing this problem. The impact became high as more and more users started facing the same issue. This problem was escalated to our project manager. So we, the testers, found ourselves standing in the ring to answer.
The good thing was that we identified the bug during the testing phase and had documented our finds. But somehow the bug went unnoticed by the stakeholders so it did not get fixed before the launch. This made me realize that testing is not just about finding bugs, but how we represent the critical bugs in the test report. A well-documented report with clarity in communication helps the developer to rectify the major bugs. Both skills are very important for a tester.
This incident taught me a good lesson for my testing Career. I realized the importance of making a detailed document and also the role of communicating with a team. Though I raised this bug as high severity, I should have asked the stakeholders to prioritize the bugs that were not fixed before giving a signoff.
Setting Test Strategy based on a timeline?
In one of my previous projects, we spent very less time on documentation. We used to interact a lot with the developers and product owners to get the requirement details. Based on the requirement details, we first prepare a Test Approach document in which testers describe the features they are testing. It provides a brief description of the functionality before and after adding the feature so that it becomes easier for a tester and developer to work together. This includes what needs to be tested, exit criteria, scenarios that need automation support and time to write a script for it and get it verified by the concerned person. If they feel that everything is covered then we go ahead with testing and if not then we make the required changes and again send for the review process. All these are set based on the time given for us to test.
“Pretty good testing is easy to do (that’s partly why some people like to say ‘testing is dead’– they think testing isn’t needed as a special focus because they note that anyone can find at least some bugs some of the time). Excellent testing is quite hard to do.”— James Bach
Here are a few important software testing documents I have worked on so far
1) Test Plan
2) Test Data
3) User Acceptance Report
4) User Documents/ manuals
5) Test summary reports
6) Daily QC Checklist
7) Weekly Status Report
8) Test Strategy
9) Traceability Report
10) Test Log, Mind Maps
11) Bug Report
12) Test Report
Balancing Testing and Documentation for better coverage
A document is more important for the tester to describe the work that he/she has done. But balancing the time between testing and documenting creates value to the tester. It’s an art and needs more practice to achieve.
Spending more time in making better test cases and less time on testing is the same as spending more time preparing for exams the night before and end up sleeping in the exam hall! The value comes when the right things are delivered at the right time.
Our brain can’t remember all the work that we do from day one of the projects. So, recording everything in a document would help to remember and access our work.
“Documentation will always keep a TESTER on the safe side because they have a written proof of what they are doing and what they did in the past .”
By Nishant Gohel | Software Test Engineer
1