Contemporary Quality Engineering

Whole Team Approach to Quality

Not a new concept, but is fundamental to any discussion on quality in contemporary organisations. Quality 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?

Consider reading these blog posts for more information: 

Threats to Quality

How to run a quality workshop

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. 

Visibility from the start

Below are three different approaches to quality.

State of Quality - Waterfall Style

In the first diagram is the traditional waterfall type approach to quality. We don’t knwo the state of quality until testing is performed. This software testing is typically performed post development and if its end to end testing (which tends to focus on business value) this happens right before depoloyment.

State of Quality - Build Quality in

In the second diagram we see a shift away from this strategy. The concept of build quality in is applied. We now have a much better idea of what quality is from the start. However, we still tend to drop off our conversation on quality once depoloyment is made.

State of Quality - Consistent Quality At Pace

The final diagram takes a holistic approach to quality. It aims to make quality visibile from the start and throughout delivery and also in the production. At any point in time, we the state of quality is available to us. This requires a new approach to quality that doesn’t only rely on software testing.

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. Product is of course, still essential, and needs proper attention but can no longer look to product quality in isolation. 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 outcomes (what our business wants) involved in developing a service or system. 

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”. We need to be able to respond quickly to market demand and outside influencers, be these technical or business related. Our role in the quality engineering space is to make valuable information available to decision makers to enable them to respond to these demands. 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. Is your quality engineering strategy able to respond in a flexible and responsive manner?

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 and in the main comes after development (The exception here is TDD - Test Driven Development). If we rely on software testing as the sole means to knowing the state of quality, this means we often find out the state of quality later. When we work in a devop continuous delivery approach this works against us. The feedback loop is too long for us to be able to quickly respond. Quality Engineering takes a different perspective. Rather than being depending only on software testing, we diversify our strategy. We focus on multiple ways to improve quality. For example, instead of looking to software testing to provide all the answers, it asks the question: 

“If you were unable to perform software testing, how would you know the state of quality of your system?

For further information on quality engineering and how it can help your organisation get in touch with one of our team on 1300 291 191

}