Hello testers hope you all are doing well. In previous article we have seen about “Attributes And Types Of Security Testing – Basic Fundamentals“. In today’s post I am shredding some light on How to perform test documentation reviews in Software testing.
Documentation is considered as an important part in testing process as there is plenty of data associated with testing like test case creation, which are 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 enormous amount of time. It is also known as static testing.
Static testing is that 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 improve 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.
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. 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 the preparing the design documents.
How Static Testing Can Be Implemented In Projects?
- Involve at least 1 person in team with business knowledge to review the Requirement and design of the project during the requirement gathering phase.
- Review process is made effective by the use of calibrated checklists
- 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.
- Initiate a discussion with the BA, architect and designer to walkthrough the requirement and design to understand the requirements and identify gaps if any.
- Receive the requirement and design document from the document author during review phase
- 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 maintain quality and correctness of requirement or design.
- Consolidate all the queries to a standard static pack and share it with BA /Architect for author comments.
- Schedule a meeting with BA and Architect to discuss on the open queries.
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 consists of any management. This method relies upon discussions to make verdicts and evaluate replacements and check if the project is working in terms with requirements.
This method is often regarded as an inexpensive method to gain some benefit. 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.
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 software background.
Inspection is regarded as the most formal review 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.
- Make use of macros to export defects from Word to excel.
- Make use of macros to prepare QC Defect template from Static test pack.
- Formulate BRD and HLD Checklist to accomplish review efficiently.
- Refine Review process by adopting Fagan Inspection Principle.
- Formulate Agile User Story Checklist by adopting INVEST Principle.
Tracking of Static testing Defects in Quality Center:
- When there is an issue, risk or gap then tester needs to raise the defect in quality center as decision type and assign it to requirement analyst.
- The requirement analyst works on that defect and decide it as issue, risk or gap and change the defect type to corresponding type.
- If it is a gap then he will add the new requirement to the existing requirements and then development team will work on that new requirement and tester will continue with his testing.
- If it is issue then arrange a meeting with analyst, developer and tester to track it close.
- If it is risk then keep that posted to corresponding stakeholder and track it to close.
Advantages of Adopting Static Testing:
- Improve QA Business Knowledge by identifying current functionality prior top new code delivery
- Increase QA understanding of new business requests
- Decrease Requirement Gap defects found in test phases
- Identify gaps/defects during requirements assessment, ensuring resolution to issues are less expensive to resolve.
How To Identify Defects Using Static Testing?
- QA team should go through all documents like MCS, IFS, SRS, SD, TSD ,artifacts and mapping sheet . If any of the above listed document is not available that itself can be considered as a defect.
- Version checking – verify version number remains same for all documents in the service
- Operation overview in SRS need to match that of IFS.
- Verify whether the Xpath, data type, length and cardinality of the request and response attributes are matching with the IFS.
- Verify whether error codes are available for all the negative functionality
- Check whether the names of service, mediation and back-end components in service component dependency diagram are valid.
Typical Defects Found In Static Analysis:
- Unreachable (dead) code
- Undeclared variables
- Variables that are never used
- Parameter type mismatches
- Uncalled functions
- Array bound violations
- Syntax violations of code and software models
- Inconsistent interface between modules and components
- Programming standards violations
- Security vulnerabilities
Perform testing documentation review is a skill of 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 comments below. If you are exprofgrsing testing concepts then you can subscribe our FREE email subscription to get latest updates on the testing.
Sign up just providing your email address below: