Can you also think of finding bugs differ­ently? 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 develo­pment 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 applic­ation life cycle.

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 develo­pers. 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 requir­ements before develo­pment starts to find potential issues in requir­ements, such as some feature that doesn’t make sense because of a missing depend­ency. This saves develo­pment time. Discov­ering issues before actual develo­pment saves money and adds tremendous value. Hence, the QA team should engage in validating requir­ements and work closely with the product owner/ business analyst.

Follow the docume­ntation on design, go through the mapping design documents. Validate the actual archit­ecture or design is as documented to find out potential problems.

Validate that all the requir­ements have 100% code coverage. There are many tools that facilitate these. This will help to ensure enough coverage is implem­ented, and if not implem­ented, which features are missing from the coverage.

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/ middle­ware/ 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.

1. Validate requir­ements
2 .Validate design aspect/ archit­ecture
3. Validate the coverage
4. Validate the developed code
5. Validate in different enviro­nments
6. Validate production operation

Validation in different enviro­nments helps to find enviro­nme­nt-­related issues. Generally there are different enviro­nments involved. The number of enviro­nments and naming conven­tions of enviro­nments differ from organi­zation to organi­zation. In general, there are develo­pment, QA, pre-pr­odu­ction (or staging) and production enviro­nments. It is important to perform some level of testing in each enviro­nment. Many times there are config­ura­tio­n-r­elated issues, deploymen- related issues, data refres­h-r­elated issues and others. Often, develo­pment enviro­nments can be ignored, but enviro­nments post-d­eve­lopment must be consid­ered.

Generally, QA teams perform smoke test / basic validation test automation on production enviro­nments. We can adapt where QA contri­butes 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. Valida­tions in this stage can be such things as checking config­uration changes, check for integr­ations with correct service endpoints, database schema change valida­tions and more.