You are trying to break the software, testing each and every corner case to find bugs to add to your bucket. Once development is complete and your build is deployed, you start testing to find potential issues. After you find bugs you try to add enough information on the defect report to show that the issue you found is actually a bug. And then you compete with fellow test engineers to find bugs first before they find the same bug. The test engineer who finds the bugs first thinks he/she wins.
Well, is that only area where testing can be done? Can you also think of finding bugs differently? If so, which areas can you think of or consider for finding bugs? How does that approach look like? Will it make any changes / cause impact to your defect tracking? How will it benefit?
Well, after gaining experience in the quality field, my perception towards quality has changed. Quality is a broad term, so you can apply it broadly throughout the software development life cycle.
So you need not just focus on finding bugs during the QA phase. In fact, you can contribute testing at various stages of the application life cycle.
Follow this approach to verify the different areas in a product.
- Validate requirements
- Validate design aspect/ architecture
- Validate the coverage
- Validate the developed code
- Validate in different environments
- Validate production operation
1. Validate Requirements
A test team should know each and every function of the product that they test, simply because they don’t just focus on specific component like developers. They get familiar with the product so well with their repeated regression testing , functional testing, etc. So, for instance, a QA team can validate the requirements before development starts to find potential issues in requirements, such as some feature that doesn’t make sense because of a missing dependency. This saves development time. Discovering issues before actual development saves money and adds tremendous value. Hence, the QA team should engage in validating requirements and work closely with the product owner/ business analyst.
2. Validate design aspect/ architecture
Follow the documentation on design, go through the mapping design documents. Validate the actual architecture or design is as documented to find out potential problems.
3. Validate the coverage
Validate that all the requirements have 100% code coverage. There are many tools that facilitate these. This will help to ensure enough coverage is implemented, and if not implemented, which features are missing from the coverage.
4. Validate the developed code
After finding issues/ bugs in the first three stages discussed above, you can focus on this part of the software cycle to find potential defects. Here both manual and automated approaches can take place. Here you can go beyond by testing data/ back end/ middleware/ front end, and can validate all layers and have quality achieved at full stack level. Here you should also touch different platforms, for example, browsers, screen sizes, devices and the like.
5. Validate in different environments
Validation in different environments helps to find environment-related issues. Generally there are different environments involved. The number of environments and naming conventions of environments differ from organization to organization. In general, there are development, QA, pre-production (or staging) and production environments. It is important to perform some level of testing in each environment. Many times there are configuration-related issues, deploymen- related issues, data refresh-related issues and others. Often, development environments can be ignored, but environments post-development must be considered.
6. Validate production operation
Generally, QA teams perform smoke test / basic validation test automation on production environments. We can adapt where QA contributes in production operation testing for a successful software product release. This is a very important piece and any miss will carry a heavy cost for the product/ team. Validations in this stage can be such things as checking configuration changes, check for integrations with correct service endpoints, database schema change validations and more.
