Gone are the days when quality was relegated to the prod3 stages of a product engineering effort. For the right reasons, quality is now well inter-twined through the varied stages of product engineering right from requirements gathering to prod3 delivery. The Agile mode of operations has also necessitated such a tight coupling between software quality and the rest of the disciplines in a product development effort. While this is a given, the question to consider is whether quality begins and ends with a code product engineering effort. Quality has an important role to play even outside a core engineering effort be it at the product feasibility stage, sustenance stage, professional services stage etc. In all of these stages, the quality engineer is playing a very versatile role – he is evaluating to see whether the product to be developed can be a quality one to be delivered in the market place, how to accommodate quality in quick fixes or patches that are being taken on post-delivery or what are those special custom requirements of clients and how to accommodate quality in delivering such specific requirements. All disciplines within a product engineering team need agility in working under these varied requirements, but a tester plays a special role – a role where he is more active in understanding the field, a role where he is not just defining but also prioritizing what kind of test coverage is needed, a role where past customer issues are being looked at in addressing current scenarios at hand, a role where close association with the build engineer is important to help them troubleshoot issues and take on tier 1 support etc.
In addition to the above, a solid practice to adopt here would be to take in experiences from all of these quality efforts and document them as needed, so they serve as inputs in an ongoing quality milestone within a product engineering effort. A quality engineer has a very big responsibility in thinking beyond just a core engineering effort in being able to meet and exceed end user expectations. Often we wonder, how to fully address such a big responsibility and the first and easiest thing for the tester to do would be to look just outside of the core engineering effort/milestone. And for this, looking at the quality output from a feasibility, past maintenance and professional services phases would be the best places to start off. This not just promotes better team collaboration and earlier involvement of quality but more importantly helps the quality engineer connect the dots in being able to fully meet end user expectations.