A mature QA process provides clear procedures for managing project risks, the toughest of them being missed deadlines and unhappy customers. However, many teams consider it a complex effort that only takes up valuable time that could be put to better use, for example, more detailed product testing. So, does it mean that the QA process maturity is just a chit-chat? We’ve decided to explain our point of view using a painful real-life example, where establishing a mature QA process was the last resort. Lets see if it worked.
Process-less project: Pains and no gain
The failure to comply with the expectations of the key stakeholders urged the project team to rethink their approach and consider setting up a QA process to have relevant project risk management procedures in place. The project team decided to concentrate on testing (QC) as the key quality goalkeeper. But to evaluate testing in detail and devise an improvement plan, they had to have an external QA audit. This is where our QA consultants stepped in.
External QA audit
Having examined the project’s pitiful state, our specialists decided to go for a tried-and-true approach that would facilitate further process maintenance efforts for the project team. We studied the possible options and decided to use the Test Process Improvement model (TPI), the most user-friendly one, to evaluate the testing process.
The TPI model provides 20 key areas (points of reference) with checkpoints (clear descriptions of features that need to be up and running to rank for a particular maturity level). The team evaluated each key area and ranked it by the maturity level A – D, where A was the lowest maturity level and D the highest.
Each key area falls into fourteen scales of maturity:
- Controlled (Scales 1 – 5)
- Efficient (Scales 6 – 10)
- Advanced (Scales 11 – 13)
Unfortunately, the TPI table brought to light several critical issues:
- Faulty in-team communication. The development and testing teams often missed or ignored the key stakeholders’ project requirements and worked ad-hoc.
- Lack of regression testing. Testing engineers simply tested the features delivered in the iteration, ran regression testing occasionally and without updating the test suite with regard to product changes.
All these issues resulted in growing technical debt and overall quality worsening (regression).
Improving the QA Process Maturity
To improve QA process maturity, our team offered a range of enhancements in problematic areas revealed by the TPI table:
- Ensuring quality communication throughout the project team. We continuously urged the testing team to discuss the project requirements with the BAs and the developers, preview the possible changes and adapt to them. Those communication practices helped improve the testing team’s awareness about the changes that were on the way. Hence, from then on testers wrote better test cases that specifically targeted these changes.
- Improving test coverage and traceability. The testing team’s attitude to this matter was split: the majority of testers rebelled against detailed reporting, and only two testers supported the measure. So we offered to run an experiment: the majority continued to work ad-hoc, and the minority documented their testing efforts and the procedures they followed. And the results were not long in coming. The two newcomers, who joined the testing team during the active phase of the QA process improvement, were able to get down to work after a two-day training session that involved studying the process documents that the two testers had developed describing the work in detail. At this point, detailed reporting ceased to raise complaints and was adopted throughout the testing team, which ensured timely test suite updates and traceability.
So, did the time and efforts we invested in improving the QA process maturity pay off? Absolutely.
Improved QA process: Output
Thanks to the dedicated efforts to increase the QA process maturity, the project team improved:
- Communication within the team that helped improve understanding of quality risks throughout the team
- Testing process and traceability that facilitated reporting and project get-in
Thanks to the improvements introduced, the project team leaped from Ad-hoc (Scale 0) to Controlled (Scales 4-5) maturity level with no plan to freeze. Maturity goes hand in hand with continuous improvements, and that’s the approach the team decided to adopt. After all, the TPI model contains 20 areas to work on, and as the team has already developed a taste for a mature QA process, we hope they will continue to improve it.
About the Author
Boris Shiklo, CTO at ScienceSoft, is responsible for the company’s long-term technological vision and innovation strategies. Under his supervision, the company’s development team has successfully fulfilled complex projects of over 80,000 man-hours in Healthcare, Banking & Finance, Retail, Telecommunications, Public Sector and other domains. Boris Shiklo has a solid background in IT consulting, software development, project management and strategic planning.
https://twitter.com/BShiklo
