How to Perform Test Documentation Reviews in 6 Simple Steps – QA Process

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.

Perform Test Documentation Reviews

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?

Software Testing Document Reviews


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

Test Document Reviews

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.

Test documents review process

We will now discuss each step in the “How” section – in other words, the process to perform it.

(Most of us testers don’t like the word processor, isn’t it? For us, it either means a lot more work or some high-level managerial task that we have to do even if we don’t want to – for the sake of some compliance that we have no idea about. But, trust me, when you come up with a process that works and is simple enough for us to understand why we have to do it, it can be fun! Just play along with me.)

The process for peer reviews and supervisory reviews is the same according to me because a supervisor is also a peer despite the higher designation.

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)

Test case review document sample

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.

About Author: This is a post by Swati Seela – an expert at Manual and Automation Testing with over 9 years of industry experience. She is also an instructor for our Software Testing Training Course.

If you want to learn Software Testing from the experts, check the schedule for our upcoming batch and more about this course on this page.

Recommended Reading

26 thoughts on “How to Perform Test Documentation Reviews in 6 Simple Steps – QA Process”

  1. nice share.

    documentation is always the most ignored part in STLC. If done and maintained properly this can be a good resource to track each and every step in the progress of software release.

  2. this document is very useful for me.thank you so much for posting this document.

  3. Nice steps….

  4. do you have any review templates that we need to use for this process?

    • I think, there is no particular template is available, you can use and modify based on your workflow..

      For example,
      PRTI process is there in most of organisations.. like, personal (Peer) review and Team Inspection.
      Author, Moderator, recorder and Inspector.
      Below is some example..

      PRTI (Personal Review and Team Inspection)
      • Once Author created the test cases, he/she needs to review those test cases
      • If he observed any issues/modifications, then he/she needs to be modified all those and updated in sheet which was we are following as “PRTI Metrix sheet”.
      • Author will inform to moderator who is going to conduct the review session.
      • Then moderator will setup a meeting for review along with test cases and Inspectors
      • Recorder, documenting the defects found during the inspection process and the
      Participants and Roles
      i. Author – The person who is responsible for creating test case that is being inspected
      ii. Moderator – The person who is responsible for planning the inspection and coordinating it and he ensures that the review process is followed, and that the other reviewers perform their responsibilities throughout the review process.
      iii. Recorder – The person who is responsible for documenting the defects found during the inspection process.
      iv. Inspectors – The persons who all there in team review meeting and identifies defects/ issues in the work product

      Matrix is nothing but a document, it has Summary, ID, defects during Personal/team inspection (how many and what are those minor/major) and etc.

  5. I Thank You for providing this wonderful article and the website for the QA people like us.

    Thanks Again.

  6. This is nice. Can you send some more examples for Test Documentation Review samples

  7. This post is helpful. Keep posting such article which leads to a successful career for others.

  8. This is fantastic – so good to know that I am doing the right thing.

  9. Thanks for your Article,
    It is simple enough,

    But we may follow approaches of Static Analysis Techniques For Reviews,
    I think Companies may learn them and customize the best way they can work with.

    Best Regards,

  10. Anyone Please tell me any tool available in market for Review comment tracking. If it is Excel macro also,kindly let me know.


  11. Hi,

    your each and every post are useful.

    Our company raising question that why we write so much test case and test cases are derived from design spec.
    when ever Client review them Client always ask this look similar that you have mentioned in design spec.

    now our company asking us why we require this testcase, instead of investing writing testcase why can’t we directly start Testing.

    Can you help me?

    Thanks again.

    • As a QA peoples, always think is 360 degree perspective.
      * If we are testing a product without test cases, we may missed some important functionalities/data/test
      * If we don’t have a test cases, then we ensure the product quality and how others will identify what you are
      tested and what you observed.
      * Test cases is useful to cover maximum test scenarios and it should be more while you are using 1st time.
      * Testing team should do review and refinement in periodic basis, during that time if you found duplicate,
      unwanted or not required test cases you can delete those test cases in to your test cycles if it was not
      * During peer review and team inspection we got to much scenarios.

  12. Extra sheet with test cases – We do review and then write test cases ?

    So, i think the statement needs to be changed?

  13. do you have any review templates that we need to use for this process?

  14. This is really Nice Article.

    @ Rushabh.
    I need to answer your question with 2 segregation –

    1. As you and your team is working on a project and If your customer/clients (PO) does not feel any importance of Test Case for him. You should really not write Test Cases as your are his resource and he don’t like to waste time.

    2. If you want to know the benefits of Test Cases –

    a. The SRS and Design docs are not having the low level explanation of any feature/function, If we write Test case we can cover all most all the Part to be get Tested (Functionality, Integration, UI, UAT..) Which will increase your Test Execution coverage and allow you to test more effectively.

    b. While Executing Testing (Test Running) if you have a Test Steps with there Expected results, it is very easy and confidence to verify the behavior of system (BUG= Actual result is not equal to Expected Result)

    c. According you ISTQB the measure of Quality there is one point – No. of test case run (or somewhat it called test Coverage) – So test case is needed.

    d. The RTM (Requirement Trace-ability Matrix) always need Test Cases so that Team should get know how much part of Requirement is covered in Test Cases.

    I would like to here feedback if anyone can add something to my comment.

  15. Hi All,
    All the information you have shared is very useful
    Can you Please explain me how we can have the Documentation in an Agile version where the requirements are constantly getting changed.

    Thanks in Advance,

  16. This information is really awesome.
    Thanks a lot!

  17. Nice and informative article. Each point is clearly mentioned and described… nice piece

  18. If you have to define the Test Document in simple words, What it would be?

    I mean interview point of view how to answer this question?

  19. Please explain me how we can have the Documentation in an Agile version where the requirements are constantly getting changed.

  20. Hi as one of my personal development plan I have to write 1.Document QA processes, for the next testers joining the company infuture
    2. have to team up with developers in writting the steps on testing the tickets we have in our sprint.

    Could you pease assist where one can start?

    We make use of scrum

  21. Thank you for providing the knowledge avout test documentation… it will help to make a proper software testing documentation…

  22. Attractive Layout and useful content

  23. I have found a similar topic: Software Testing Reviews are key for a test manager, but knowing the art of managing test reviews is key to reducing the cost of quality through these tools. Knowing how to manage informal and formal testing reviews helps the Test Manager across projects and products.

  24. Add Initial Offer Review Task in Seller config for SAA-Reosale test cases


Leave a Comment