Review plays an important role in all the phases of SDLC cycle. It helps in minimizing the issues/defects in a particular phase and even in a subsequent phases.
Reviews as per phases of SDLC:
1. Functional Specification Document: This document is created by business analysts after understanding the requirements from the customer. The solution architects, development and testing teams reviews the document. If there are any issues then the defects are logged and those defects are called as static defects. The business analysts need to address these issues and also resolve the queries raised by architects, development and testing teams.
2. High Level Design and Low Level Design documents: The technical architects are responsible for these documents which should undergo review by Business Analysts and development team. High Level Design document is required by test team as well to understand the application’s architecture. Test team may give review comments and queries, which the technical architect has to address.
3. Code review: The basic code review checklist should have guidelines as mentioned below:
- Is the code easily understandable?
- Are coding standards followed?
- Is the code duplicated?
- Is debugging the code easy while finding the root cause?
- Is the function or class too big? If yes, then is the function or class having too many responsibilities?
The checklist:
a. Code formatting: To improve readability, check the code formatting like alignments (left margin), code block starting point and end point and make sure they are easily identifiable, naming conventions are followed, and the removal of the commented code takes place.
b. Architecture: The code should follow the defined architecture.
c. Non-functional requirements:
- Reusability: Consider reusable functions, services and components
- Security: Authentication, authorization and data validations
- Scalability: Check if it can handle large user base/data
- Reliability: Exception handling
d. Best practices: Avoid multiple if/else blocks, use framework features instead of writing custom code
4. Testing
The main test artefacts:
- Test plan
- Test case
- Requirement traceability matrix
- Test execution and defects
- Test completion report
The checklist:
Test Plan: Check if all the sections in the document are complete with detailed information. Mainly In-scope, out-of-scope, entry-exit criteria, defect management, team details, test design and execution strategy, co-ordination forum, document history, links to other test artifacts etc..
Test Case: Check if test case objective is met. Check all the columns of the test case are complete and logical. Test case naming convention is followed. Check if the test case is not too lengthy covering many functionalities in one.
Requirement traceability matrix: This matrix is used to ensure that test coverage is complete by mapping requirements to test case(s). Check if all the requirements as per functional document are listed in the matrix and all the requirements have test case(s) mapped.
Test execution and defects: Check is the actual results are updated against each step in the test case. Check if defects are logged against the failed steps and mapped to the step and test case. The defect has turnaround time. Check if the defects are addressed on time and resolved.
Test completion report: Post completions execution phase, the completion report is created. Check if all the details of execution like execution output for each cycle are mentioned, defects chart is put with severity and priority. The known issues if any are mentioned with a closing note.
Remember reviewing is not just limited to manual testing teams but also important for automation teams. It increases the quality of the software products and finding the defects and requirement gaps at the early stages of development becomes easy. Most importantly, it reduces the amount of rework required and there by increases the efficiency.