It’s absolutely amazing how waterfall quality assurane easily turns into “us and them” blame game. Software quality shouldn’t be “quality assurance” as much “quality engineering”, because quality essentially is about removing variance from the process of releasing code. It’s all about automation of each stage of development, verification and delivery. Therefore both: software engineers and quality engineers should engage early in the process of removing manual, variable activities concerning how code is tested, integrated and released. To some extent you cannot be a good developer without good understanding quality engineering and you cannot become good developer without good understanding of software engineering. Here comes a revolutionary thought: how do you decrease number of failed quality problems? Actually it’s not about keeping the number of quality tests low. It’s about increasing the number of tests and lowering the number of failed proportion. Product with 2 quality problems discovered in 1000 tests can represent a much better release than a product with zero bugs out of 10 tests. It comes as shocking statement to many quality assurance people and if proved correct would overthrow many quality managers constantly pushing for zero defects per product at all costs. Personally I believe that quality is all about testing pretty much everything that yields itself to measuring, not only what has been requested in business requirements. Having more than few faulty products for QA and Dev is important in understanding what quality is too. Microsoft Office and Google Docs are currently two most popular office packages available to milions of users worldwide. Quality of both products is imperative. Office 2010 is in its second beta out there for a limited time, targetting limited user base and Microsoft quality engineers to define what quality of that particular release means. Even assuming the most optimistic scenario: that is the first ever build which has passed through Redmond’s gateways and even assuming it’s the last one, it would mean there are three releases of 2010 version and only one will eventually become upgraded to RC status and maybe even RTM. That makes 2/3 fail, amounting to 75%. Microsoft is pursuing beta programs even for Service Packs, however compared to other quality champions, it’s still behind the curve, even though the actual number of releases going through QA runs in hundreds. Google kept over seventy of releases of Gmail 1.0 in beta stage for over three years, making the failure rate standing at almost 99% mark. Google Documents however had been through over 500 release cycles bringing the “failure” rate well over 99%, yet both Microsoft and Google are speeding up their release cycles significantly. With both products aiming at ever higher quality standards, time of release cycle emerges as the key factor. Release doesn’t always mean release to market, however both companies keep achieve at least 75%+ failed releases in order to gain perspective, learn what quality really is and push their final products out to the markets really smoothly at a great confidence level. Very often it’s important that high quality products have not only been through many cycles of quality checking, but also that they’re thoroughly tested in the field too. Modern quality assurance not only recognises importance of incremental quality engineering, but also beta programmes.
Incremental quality programmes assume early engagement of quality and development teams, quality process being incrememented through parallel implementations and keeping multiple branches of code, running different releases side by side.
Keep dependencies low, separate client facing environments. Quality architecture Separate development teams as application grow. Small group of developers with narrow focus will know every bit of their systems, is much more likely to enhance products with long term in mind looking for quality opportunities and future proof architectures.