By now, we all know that for a tester, Documentation is an integral part of his daily life. There is an overload of testing artifacts that are created, reviewed, approved, used, maintained and distributed. We always have clear-cut processes laid out for how to create a document, how to use it, who should it go to, etc.
Through this article, we are going to shed some light on the small but important topic – Reviews.
Reviewing is a form of testing too – the verification part of the V&V also called Static Testing.
Types Of Reviews
- Reviewing your own work – Self Checking
- Peer- review
- Supervisory
If validation is one-half of the testing practices then verification is the other, but often the guidelines are murky – So let’s change that NOW. Is it a general practice with the articles at STH, we will begin with the questions, What? Why? How?
What Do We Review?
Everything created has to be reviewed. The following are some of the common artifacts reviewed:
- Test plan
- Test scenarios
- Test templates
- Test cases
- Test data
- Reports…etc
Why Review?
For exactly the same reason we test the software, For Example,
- To uncover errors
- To check for completeness
- To make sure the standards and guidelines are adhered to or not …etc.
How To Review?
The following are the list of activities involved:
- Define the criteria – Have a checklist of what to look for?
- Perform the check
- Record your results
- Share, discuss and implement the changes required
- Version control the documents involved
- Sign off and use the doc as intended.
We will now discuss each step in the “How” section – in other words, the process to perform it.
(Isn’t the word processor disliked by the majority of testers? For us, it either entails a great deal of labor or a high-level managerial task that we must perform even if we don’t want to, in order to comply with some unknown compliance. But believe me, it can be enjoyable when you devise a procedure that functions and is easy enough for us to see why we must follow it. Just comply with me.)
Since a supervisor is also a peer, regardless of their higher title, I believe that the procedures for supervisory and peer reviews are the same.
Step 1: Define The Criteria
#1) What are you expecting to find? You can look for things like:
- Spelling mistakes (Sounds too silly? I don’t think so, one time I wrote “Wed Object” instead of “Web Object” in one of my articles – Changes the meaning entirely. Almost makes it too silly to be taken seriously.)
- Format/template compliance
- Functionality coverage and correctness
- Ease of understanding
- Standards followed – naming conventions, consistent numbering …etc.
#2) Make a checklist– Checklists are very versatile. It can be as complicated as a review checklist or as simple as a grocery list. All it takes is some time to make it and once you do, it is as simple as checking ON or OFF.
#3) How to report the Results? – Choose whatever is convenient, preferably a method that can be recorded and tracked.
- Sometimes this can be as simple as adding an extra column in the excel sheet with test cases and writing something in red when it is not what it is supposed to be.
- Can be the word of mouth
- A list in an email
Step 2: Perform The Check
#1) Using the checklist you made earlier, verify the document and provide your feedback.
Step 3: Record Your Results
#1) Again, using the method decided in step 1, record and report your results.
#2) When reporting your comments or suggestions for change, treat it no differently than reporting a defect. Don’t overlook anything. Be detailed.
Step 4: Share, Discuss And Implement The Changes Required
#1) Nobody likes to be told that their work is incorrect or incomplete. So keep in mind the following guidelines when you are providing negative feedback.
- Provide constructive criticism – Remember not to be critical of the person but point out flaws in this product
- Don’t get competitive – just because he turned in 30 review comments on your test cases, don’t try to beat it.
- Give reasons to back your comments
#2) Obtain a sign-off.
#3) Have the changes made
Step 5: Version Control The Documents Involved
#1) Don’t delete the older versions of any of the documents. Name them appropriately and keep them in a centralized project folder. After all, this is the evidence to all our work
Step 6: Sign Off And Use The Doc As Intended
#1) Once all the changes are incorporated, version saved, give the review process a sign-off and move on to using the document for what it was created for.
#2) Another question that comes up is – do we recheck after the changes are made? How many times is this process going to go on – work- review-fix-and then reviewed again? Until when?
No, a review does not have to happen over and over again. It is a quality control activity that focuses on verifying if the testing aides are created right or not. As always, zero-defect documents are impossible. So a reasonable level of review- one time by a peer is acceptable.
There, you are done. Isn’t this process simple?
Points To Remember
- Every project does not have to follow this formalized method of review, but even if they have an informal method in place, these steps will help set the expectation and guide you along.
- Test documentation timeline estimates are typically based on the time required for creating and reviewing the documents- so it is inbuilt into it even though we don’t always recognize it.
- Reviewing is not a process that is limited to manual testing teams. Automation teams also perform code walkthroughs, design reviews, etc.
Lastly, this is how a typical review comments document for test cases looks like. The comments are in red. Not necessarily real comments, but something to show how it’s done.
Sample Test cases review Document: (click to enlarge image)
Over To You
So, do you still feel that processes are daunting? Do you perform reviews in your projects? Please share your experiences, challenges, questions, and comments below.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune
Automation testing in selenium
Mastering Software Testing: A Comprehensive Syllabus
Frequently Asked Questions
What is the primary goal of performing test documentation reviews in the QA process?
The primary goal of performing test documentation reviews is to ensure that all test documents are accurate, complete, and consistent, which helps to identify and mitigate potential risks and defects in the software. This review process also helps to improve the overall quality of the software. By doing so, it increases the reliability and effectiveness of the testing process.
How often should test documentation reviews be performed during the QA process?
Test documentation reviews should be performed regularly, ideally after each major update or iteration of the test documents, to ensure that they remain relevant and effective. This frequency may vary depending on the specific project requirements and the rate of change in the software. Regular reviews help to catch and address defects early on, reducing the risk of downstream problems.
What are the key components that should be included in a test documentation review?
A comprehensive test documentation review should include components such as test plans, test cases, test scripts, and test data, to name a few. It’s essential to review these components for accuracy, completeness, and consistency to ensure that they align with the software requirements and testing objectives. This helps to identify gaps or inconsistencies that could impact the testing process.
Who should be involved in the test documentation review process?
The test documentation review process should involve a team of stakeholders, including QA engineers, test managers, and subject matter experts, to ensure that all aspects of the test documents are thoroughly reviewed. This collaborative approach helps to bring different perspectives and expertise to the review process, increasing the likelihood of identifying and addressing defects or issues. It also promotes knowledge sharing and cross-functional understanding.
What are the benefits of following a structured 6-step approach to performing test documentation reviews?
Following a structured 6-step approach to performing test documentation reviews provides several benefits, including improved test efficiency, reduced risk of defects, and enhanced collaboration among team members. This structured approach also helps to ensure consistency and standardization in the review process, making it easier to identify and address issues. By doing so, it increases the overall quality and reliability of the software.
