4. Quality everywhere

In the previous articles, we talked a lot about the increased technical demands on the Quality Assurance engineer when transitioning to a modern agile setting. These technical considerations are quite effective at paving the road, gaining access to all relevant forums. To reach the goal of becoming a first-class citizen, however, quality needs to be everywhere. This takes a lot of hard work and persistence. Team composition is also particularly important. Decent quality levels can only be achieved if the responsibility is shared.

These basic but powerful guidelines can be of help along the way.

Team ownership

When designing a solution, involving all relevant software development team “guilds” will strengthen the sense of ownership. This will also promote a deeper and more widespread understanding of the product vision, the very foundation that all requirements should build upon. This, in turn, allows for valuable re-iteration of requirement interpretation from all team members when implementing a feature. Significantly minimizing vision divergence.

Unquestionable psychological safety

A team allowed to work in an environment where feedback is handled with respect will, mid-and long term, benefit from it and so will the product. To be able to leverage feedback when improving, this respect must be bidirectional. The act of making a mistake should not be considered malicious by default, but the impact of the mistake must be respected too. In terms of direct cost as well as possible long-term issues related to mindset.

Treat warnings as errors

In addition to being a classic compiler setting that will directly increase the quality in a product, it can also act as an analogy when looking at all aspects of the design and development process. By leaving no stone unturned, the product may not be faultless, but most potential issues will at least be known. This can be applied on many levels:

• Spend time on naming. It is the hardest, but one of the most important parts of software development. When spending the time to figure out the most semantically correct naming of a variable, process step or article, we force a deeper understanding.
• When reading an article, do not skip sections that do not make sense at first glance.
• When, while implementing a feature, soliciting the assistance of internet forums, avoid being content with a solution that works. Strive to find out why it worked in your application.
• When inspecting test execution results, accept nothing less than a 100% pass rate. Perfunctory acceptance of failures does not only indicate that not all test cases are important, it also quite effectively hides anomalies. The issues hiding behind a 3% failure rate one day can altogether cover different parts of the functionality than the same failure rate level another day.

Embracing the artisanship

Make sure that the team is made up of the right people with the right skillsets at the appropriate phases of the process. Then trust their artisanship. Avoid putting too much emphasis on absolute metrics. E.g.:

• Quantifying system test coverage on complex solutions is hard. Focus on sharing quality responsibility through transparency instead.
• Counting reported and fixed bugs is, at best, misleading. A quality-driven approach should aim to catch all issues at an early stage when development and testing are tightly coupled. Therefore, communicating issues through bug reports is highly inefficient.

Learn more in the next article "Quality Osmosis"