Eric Knorr of InfoWorld recently wrote an article about how testing was the key to how to be agile without falling on your face.
While I agree that IT organizations are squeezed and that quality is often given short end of the stick, I don't think Eric's solution of "optimize the efficiency of your testing tools, environments, and methodologies" is necessarily the right way to think about the problem.
Most organizations think of quality as a role (the role of the tester) - and as a result most testing tools are just that: specialized tools designed with the needs of the professional tester in mind. The problem is, with modern applications, quality doesn't start and the tester and doesn't end at the tester. Quality is a responsibility not a role - a responsibility of everyone involved from development through production. This is one of the reasons that developers really like our free Actional Diagnostics tool (used to be called Mindreef SOAPscope) - it's designed from the perspective of the needs of developers, but it focuses on improving quality. For example, we found in formal ROI analysis that deploying our products in the hands of developers reduced the number of production issues by 25%.
So, rather than focusing on how to make testers more efficient (which will only get you so far), it's better to focus on tools and SOA infrastructure to help developers and architects avoid defects before they are created. But these aren't testing tools because developers don't use traditional testing tools. If you have 10 defects, avoiding just one of these development (something which is eminently doable) is as beneficial as improving testing productivity by 10% (something which is probably a lot harder).
On the other end of the spectrum, with today's interconnected applications the number of defects which will show up in production is significantly higher than traditional applications, and you'd likely have to increase your testing by a factor of 10x to get to the same production-defect-rate as a traditional silo'd application. Alternately, a 10% reduction in the time-and-cost of resolving issues in production easily pays off as much as a 10% improvement in testing efficiency. And, achieving a 10% reduction in this is definitely achievable... Now imagine you could reduce the time-and-cost of resolving issues in product by 85%...
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.Learn More
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.