STOP TREATING TESTING AS AN AFTERTHOUGHT

Business Critical Software Needs Empowered and Ongoing Quality Assurance

Both technology and business executives continue to consider software testing as an afterthought. Executives, and the organization in general, treat it as a low part of the value chain.

Some organizations have put in place quality assurance (QA) services to imply a broader perspective than pure testing (one that includes the monitoring and continuous improvement of processes and projects). However in reality even these organizations apply lip-service to the importance of QA, and it is treated with the same (typically low) level of importance. Well-qualified QA engineers find their role minimized, and spend their days “just” testing.

Today, the complexity of software challenges even companies which have technology running through their DNA. To give a sense of this complexity, Microsoft revealed their development environment, Visual Studio 2012, had over 50 million lines of code. It was reported that the initially disastrous healthcare.gov website had 500 million lines of code (a lot of experts question this number and consider it to be much too high, but regardless of the actual number- the point is, it was hugely complex, and an initial disaster).

Effective QA helps manage this increasing complexity. In my experience, the organizations which have a track-record of successful software development prioritize and value both the discipline of QA as well as the engineers themselves. They take a more sophisticated perspective, and empower QA engineers to apply their skills and capabilities throughout the software development lifecycle. Such a view incorporates:

• Metrics. Metrics are critical to evaluate the productivity, efficiency and quality of software development over time. Metrics provide you with data you can use to make decisions, and judge results.
• Security and risk management, including architectural risks. QA should play an active role in identifying the risks and threats to your organization. Poorly developed software may represent one of the biggest risks to your organization.
• Scalability and performance. Users today have less patience than ever with badly performing software. Proactive QA ensures your software meets these rising expectations.
• Process assurance. QA engineers are well positioned to help ensure your organization adheres to agreed upon best practices, as well as compliance with regulations and standards.
• Documentation management. Documentation management has long been a core component of QA. It is a critical aspect in standardizing processes – essential for handling increased complexity.
• Continuous integration. Daily (at least) integration of code into a shared repository, and receiving immediate, automated feedback, is a key part of improving software quality. This needs to involve your QA team, who are perfectly positioned to modify automatic test cases.
• Agile QA practices. QA should not be something that happens after the product is developed as happened in the Waterfall model or in poorly implemented Agile development. QA engineers need to be involved from the very early stages of the project – even during the product ideation phase and through each iteration. This needs to happen in close collaboration and communication with the development team, as well as the Product Owner. It’s a pity to see how many organizations miss out on the value that good QA engineers can add to the process.

As an example, when applying these practices with one of our largest clients, we saw the number of issues coming back to development decreased significantly. The major benefits were:

1. Avoided “re-working” issues. The throughput (velocity) and quality of the product both went up.
2. Improved user satisfaction. The product had better usability and quality. At the same time it also included more functionality in a shorter period of time due to the improved velocity.

Bringing all these elements together maximizes the potential for QA engineers to have a major impact on the quality of your software, and in turn the business impact this software will have.

Do you agree with this assessment? What other responsibilities should QA take? I look forward to your comments.

If you’re interested in finding out more, check out Belatrix′s whitepapers which contain a wealth of information both on Agile QA and other topics.