ZestinIT Testing Process
We follow Iterative V model for Testing; Iterative test process consists of many iteration and every iteration consists of phases.
Every iteration has one release and all phases of V model are executed in one iteration. This leads to better quality release as changes done in one iteration are tested and complete system is tested again for any break point that crept in because of implementation in current iteration. In every iteration, percentage activity of phase is decided based on specification change scope
We divide our approach into white box, black box and test automation.
1. Requirement Gathering: The first step in our QA methodology is requirement gathering and understanding how client is going to use the deliverable. We prepare SQR/use cases/wireframes/Complexity Diagrams so that we have an agreement on the requirements of the project. We use UML to capture critical flows part of core engine of system All algorithms and cases are captured using UML/flow diagrams for better understanding.
2. QA Planning: After requirement collection, the test plan of the project is prepared. A complete testing environment containing all hardware and software requirements is made. Test Plan consist of plan and strategy defined for different component of system. Test suits are made to categorize test cases. The test cases are made upon the functional requirement of the project and the use cases. To trace and check the coverage project traceability matrix is maintained.
3. Strategies and Stages: In an independent QA project, we work with our customers to identify the strategies and stages of QA where ZestinIT will be involved.
A. White box Strategy: White box strategy has a lot of advantages as it requires testers to understand the code and logic, and enables them to identify correct set of input data. It allows code optimization and removal of dead code. It includes:
- Unit Testing: The developer carries out unit testing in order to check if the particular module of code is working fine. The Unit Testing is very primary level of testing and is executed by development group for each new module or functionality.
- Static and dynamic Analysis: Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analysing the output.
- Statement Coverage: In this type of testing the code is executed in such a manner that every statement of the application is executed at least once. It helps in assuring that all the statements execute without any side effect.
- Branch Coverage: No software application can be written in a continuous mode of coding, at some point we need to branch out the code in order to perform a particular functionality. Branch coverage testing helps in validating of all the branches in the code and making sure that no branching leads to abnormal behaviour of the application.
- Security Testing: Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application. This type of testing needs sophisticated testing techniques.
- Mutation Testing: A kind of testing in which, the application is tested for the code that was modified after fixing a particular bug/defect. It also helps in finding out which code and which strategy of coding can help in developing the functionality effectively.
The code once developed is tested by developer (unit testing) and is released to the QA. Unit test framework is integrated with code and unit test cases are checked for complete code coverage by mapping in traceability matrix. Unit testing is most important part of engine base solutions; this help in testing the system on completely and recursively, approach also automate API testing.
The QA performs functional and integration testing using black-box method. Testing team also develops scripts for the automated testing. System testing is done at the end of all intermediate releases to ensure that the application is working fine as an entire application.
B. Blackbox Strategy: Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.
QA process is well synchronized with configuration management tools using branching and labeling in process.
There are review processes in between. Code review/Design review is done by the project manager / lead depending upon the team structure. There are checklist for both design and code review. We have 36 parameters in code review checklist and around 26 parameters in our design review checklist document. Based on these parameters, the team lead/project manager understands the quality of the project. Check lists are maintained for all steps so that process is tracked properly.
In addition, we maintain matrix like logic variance, code standard variance, review effectiveness, in process defect density and delivered defect density to monitor quality assurance of the project.
The QA tools that we use are as follows:
