How To Perform Test Documentation Reviews In Software Testing?

Hello testers, hope you all are doing well. In the previous article, we have seen “Attributes And Types Of Security Testing – Basic Fundamentals“. In today’s post, I am shedding some light on How to perform test documentation reviews in Software testing. 

Documentation is considered an important part of the testing process as there is plenty of data associated with testing like test case creation, which is reviewed, approved, and distributed. If all the relevant data is documented properly it would prove to be a valuable asset as it helps in tracking and monitoring the progress of testing and help save an enormous amount of time. It is also known as static testing.

Static testing is the type of testing that is done manually or using a set of tools without executing the code. Informal Reviews, Inspections, Walkthroughs, Technical Reviews, Static Code Analysis are some of the static testing techniques. The main advantage of performing static testing is to find the defects early in the software lifecycle which in turn reduces the cost of fixing those defects when identified later in the SDLC and improves the quality of the software being developed. It is done during the requirement review phase and design phase. The idea practice is to start testing right from the Requirements phase.

The static defect can be raised when there is an ambiguity in requirements or when there is are requirement gap and can be assigned to the System Analyst. The static defect can also be raised on the High Level and Low-Level design documents during the Design phase and these defects are assigned to the Lead Developer who is responsible for preparing the design documents.

How Static Testing Can Be Implemented In Projects?

1. Involve at least 1 person in the team with business knowledge to review the Requirement and design of the project during the requirement gathering phase.
2. The review process is made effective by the use of calibrated checklists
3. Review the BRD and HLD documents without any assumptions and raise all the defects to Document author to maintain the quality of the master documents.
4. Initiate a discussion with the BA, architect, and designer to walk through the requirement and design to understand the requirements and identify gaps if any.
5. Receive the requirement and design document from the document author during the review phase
6. Assign two reviewers a novice (primary reviewer) and expert (peer reviewer) of that particular business unit.
   • Novice could come up with open questions – maintain standard and completeness of the requirement or design.
   • Expert could come up with business/design questions to maintain quality and correctness of requirements or design.

7. Consolidate all the queries to a standard static pack and share it with BA /Architect for author comments.
8. Schedule a meeting with BA and Architect to discuss on the open queries.

Test Documentation Technical reviews:

Technical review is often headed by a moderator which encompasses peers and technical experts. It is regarded as pre-meeting preparation. It is well-documented and is framed to identify defects. It does not usually consist of any management. This method relies upon discussions to make verdicts and evaluate replacements and check if the project is working in terms of requirements.

Informal Reviews:

This method is often regarded as an inexpensive method to gain some benefit. An informal review is rarely documented. This strategy can be used n number of times to get the desired result. It can start with 2 people and then proceed to a wider one with more team members.

Walkthrough:

This is often managed by the author to make the team members apprehend about the project especially in terms of requirement changes and help to gather more details. It might also focus on business scenarios. This can be of great help to those people who are not from a software background.

Inspection:

Inspection is regarded as the most Test Documentation formal reviews method which is often managed by a moderator who is well trained and in this method, every single document is strictly checked with respect to the checklist. This helps to identify bugs and to document them.

Software Testing Best Practices:

1. Make use of macros to export defects from Word to excel.
2. Make use of macros to prepare the QC Defect template from the Static test pack.
3. Formulate BRD and HLD Checklist to accomplish review efficiently.
4. Refine Review process by adopting the Fagan Inspection Principle.
5. Formulate the Agile User Story Checklist by adopting INVEST Principle.

Tracking of Static testing Defects in Quality Center:

1. When there is an issue, risk, or gap then the tester needs to raise the defect in the quality center as decision type and assign it to the 5requirement analyst.
2. The requirement analyst works on that defect and decides it as an issue, risk, or gap and changes the defect type to the corresponding type.
3. If it is a gap then he will add the new requirement to the existing requirements and then the development team will work on that new requirement and the tester will continue with his testing.
4. If it is issue then arrange a meeting with the analyst, developer, and tester to track it closely.
5. If it is a risk then keep that posted to the corresponding stakeholder and track it to close.

Advantages of Adopting Static Testing:

1. Improve QA Business Knowledge by identifying current functionality prior to top new code delivery
2. Increase QA understanding of new business requests
3. Decrease Requirement Gap defects found in test phases
4. Identify gaps/defects during requirements assessment, ensuring the resolution to issues is less expensive to resolve.

How To Identify Defects Using Static Testing?

1. QA team should go through all documents like MCS, IFS, SRS,  SD, TSD, artifacts  and mapping sheet.  If any of the above-listed documents is not available that itself can be considered as a defect.
2. Version checking –  verify version  number remains the same for all  documents in the service
3. Operation overview in SRS needs to match that of IFS.
4. Verify whether the Xpath, data type, length, and cardinality of the request and response attributes are matching with the IFS.
5. Verify whether error codes are available for all the negative functionality
6. Check whether the names of service, mediation, and back-end components in-service component dependency diagram are valid.

Typical Defects Found In Static Analysis:

1. Unreachable (dead) code
2. Undeclared variables
3. Variables that are never used
4. Parameter type mismatches
5. Uncalled functions
6. Array bound violations
7. Syntax violations of code and software models
8. The inconsistent interface between modules and components
9. Programming standards violations
10. Security vulnerabilities

Conclusion:

Perform test documentation reviews is a skill of a good QA engineer. Today we learn how to implement static testing in projects, how to identify defects using static testing, how to track static testing defects in Quality Center, and many more key points.

If you want to share more points as per your experience which you think that should have been included in the above topic then feel free to add in the comments below. If you are looking for more such testing concepts updates then you can subscribe to our FREE email subscription to get the latest updates on the testing.

Sign up just providing your email address below:

Enter your email address:

 

Check the email in your inbox for confirmation to get the latest updates Software Testing for free.

 
Happy Testing!!!