Establishing a QA Process Supersedes Selecting the Right Automated Tool

Member Submitted

merely being a brief checking point within the SDLC. True gatekeepers have much more power within the company to control the release of software. They are influential and the politics are in their favor. This is the ideal situation for a QA Analyst.

The second step is to hire people with similar beliefs related to the strategy. These people would ideally have the same knowledge of testing and be familiar with the methodology designed by the QA manager.

The third step is to establish what metrics will be used to measure individual and group performance. In this step, communication is important. It is important to communicate to the team and to the necessary stakeholders what the metrics are that will measure individual and group performance. Some common metrics are the number of defects found, defect density ratios, and the number of defects found in production versus the number found in the QA environment. There are many other metrics out there.

The fourth step is to give project estimates as needed. Providing project estimates makes good business sense as it sets expectations about when deliverables are due.

The next step is to establish risk mitigation strategies. The purpose of testing is to minimize the risk the software will provide if implemented. One of the prevalent methods used to reduce risk is to do a software risk analysis. In the article entitled, "Measuring the Risk Factor," one of the methods of software risk analysis is discussed. In that article, the argument is made that four indicators should be considered when doing a risk analysis. These are complexity, severity, expected impact of failure, and likelihood of failure.

The sixth step is to gather the right tools and resources. Selection of tools should not come earlier than this. All other features should be in place before a discussion of the right tools can take place. When considering the purchase of tools, it is important to think about what the tool will be used for and how it will be used. A decision should be made with these considerations in mind.

Finally, it is important to communicate to all stakeholders what the QA approach will be going forward and set the expectations with all the stakeholders about what the QA team can accomplish given that everything is in place.

This article has argued that a repeatable QA process should come before the selection and implementation of automated tools. There are drawbacks to using automated tools in client/server environments and one should consider carefully the potential use of the tool. Many tasks should come before selecting a tool as it is not the cure for a weak QA process. The selection of a tool should come much later in the development of the team and the team's process and especially after the consideration of risk.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!