Contemporary Quality Engineering
Quality engineering enables visualisation of the state of quality anytime in the delivery lifecycle of a system or service. It does so in terms of its business outcome. Anne-Marie Charrett (working definition)
Services not Products
The complexity and the distributed nature of our systems today means we are moving towards a network of services instead of an identified product. Instead of only thinking product quality, think ’emergent quality’. Emergent quality means focusing on the quality of the ecosystem. By doing so, it improves the quality of a system or service. By ecosystem I mean, the pipeline, process, people, provisions (tools) and principles involved in developing a service or system.
Business Outcomes not Feature Done
Nature abhors a vacuum. If we don’t visualise and inform our stakeholders of the state of quality, they will inject their own interpretation of quality into that space and it will be imposed upon you.
The finance director will do so in terms of money, the sales director in terms of revenue. Quality Engineering requires we understand and visualise quality in terms of business outcomes not only our ability to deliver a feature.
New Quality Attributes
Quality Engineering requires we better understand what quality is before we begin to think about how we can make it visible. What is quality for your organisation?
For many organisations, speed has become a quality attribute. It’s no longer “the large eating the small, it’s the fast eating the slow”. I wonder how many in the quality business are thinking about how to visualise and make this information transparent to business?
In the context of contemporary deployment practices, there’s a shift from attempting to delivery perfect software to being able to recover from production failure more rapidly. Observability of systems is a key factor in enabling this.
Quality is as always shifting, and morphing into something new. How are we in the quality space responding to that?
And Software Testing?
Software Testing provides visibility on the state of quality, it does nothing to fix it. Software Testing is dependent on code being developed. It inherently comes later in the deployment lifecycle. Quality Engineering encourages lateral thinking on how we can know the state of quality of a system or service. Instead of looking to software testing to provide all the answers, it politely asks the question:
“If you were unable to perform software testing, how would you know the state of quality of your system?”
Visibility from the start
By looking to a diversity of approaches to knowing the state of quality we can begin to see the state of quality consistently from the beginning, throughout and after deployment.
Whole team approach
This is not a one person approach, it requires the whole team to be present and involved in understanding and knowing quality. It truly reflects the concept that the whole team be responsible for quality. Think of quality engineering in the context of a team and ask the team to respond to that. What would they consider as a threat to quality?
Other posts on quality engineering
Anne-Marie Charrett
Anne-Marie Charrett
Anne-Marie CharrettAnne-Marie Charrett
Comments ()