Generally QA comes in to picture after development is complete. Then QA team works on testing the implemented features and finds bugs on developed application. This helps to increase quality on the application developed. However – is it best approach? Does it bring down the cost. The answer would be no. Then what methods, process QA can follow to bring best Quality.
If the same bug is found during requirement phase, it could have drastically minimized cost and added lots of value. Experience shows that proactive testing techniques could prevent many mistakes from happening during development in the first place and minimize time required for TC creation and execution, since QA specialist is already familiar with all the requirements and possible hidden issues. Few example of process changes that could help to switch to proactive testing from reactive approach:
Acquiring business knowledge is most important aspect whole team including QA should learn.
Thorough review of requirements/ US
Check any potential miss that might impact old feature (which already implemented)
Create and review TCs before development starts
Validate requirement coverage
Understanding the project is key to efficient development: team will work faster with documentation and could communicate more efficiently with PO. Also, sometimes business requirements do not contain information obvious to PO, but that is open to interpretation by dev/qa teams. Having knowledge transfer sessions with PO or field experts, involving team transforming business requirements to technical requirements will give benefits in long-term. Test should know in-out about product to bring maximum quality. Product Functional understanding is key to Test team success.
Review is a great way to get fresh opinion on the problem or a solution and will help to catch mistakes on the early stage. There could be multiple stages of review (QA manager –> team -> product owner) or just the one with the whole team/part of tem (depending on team size and distribution of responsibilities), but this will allow to get everyone on the same page and inform developers on what QA expects to be developed.
Reviewing requirements thoroughly give opportunity to the tester to find potential issues / gaps based on his/her prior knowledge on the product. And the issues found at this stage will save significant cost, and there by add lot of value.
As mentioned before, some information can be lost during translation of business requirements into technical requirements or some clarifications may be required for QA team. There are 3 usual ways to request clarifications: email chains, long meetings or tracking in documentation/workflow management tool. Last approach in most cases is the most effective. Product Owner and developers may come from different fields and that way speak in different languages. Preparing issues for discussion in task tracking tool will allow both parties to prepare and run efficient meeting.
Adding new functionality always brings a risk of breaking something, even in project with high unit test coverage. Prediction of such issues is hard, but not impossible:
Team should understand functionality of the project and dependencies between modules
If project is a part of infrastructure/business process, team should understand impact any change can have on other application (e.g. changes of request/response format, changes of data export format, database changes if it shared by multiple applications etc)
Documenting all integration links and typical issues into short checklist could also decrease number of regression defects
Test team can spend good amount of time to make sure coverage, which will have tremendous impact for development team and also test team to uncover potential issues. Test team should also include coverage from non-functional aspects for ex – browsers to include, devices to include, operating systems to include, screen sizes to include etc. Also considering API testing, backend testing, middle ware testing etc helps bring significant quality in to the product.
Creating the defects in defect management tool helps the team to track and prioritize to fix the issues. Triaging defects will also helps not skip severity defects. Also managing the defects in a tool helps measure different aspect of the work delivered like volume, velocity, quality, health etc.
There is no “magic pill” that makes any QA process 100% efficient, all guidelines require adjustments to the project specifics, team dynamics and PO involvement in development process. Agile following of these guidelines could be more beneficial than intention to establish process at all costs.