How to get top-level buy-in for a true quality engineering approach

man explaining quality engineering to colleagues

Ten10 Principal Consultant Ben Neuss shares how you can mediate defects and emphasise the importance of quality engineering to senior business leaders

Change is hard in the modern tech landscape. When your organisation is moving at pace, juggling different methodologies, tech teams and suppliers that are already up and running, changing your approach can be difficult.

Quality engineering can help you deliver quality software faster, more efficiently, and more frequently – but how can you get senior business leaders to buy into the approach and make it a priority in your organisation?

Hear from Ben Neuss, Principal Consultant at Ten10, as he explains how you can define and measure ‘quality’, when it should be built into the software development lifecycle, and how you can get your business to commit to quality as an over-arching objective so it becomes business as usual.

Let’s start with: what does the word ‘quality’ mean? How do you measure it and how do you deliver it?

That’s an interesting one, isn’t it? Because I think often it tends to mean different things to different people. You can go very basic and look at the dictionary and you’ll get a sort of definition that says ‘a degree of excellence or superiority in kind’ which is fairly wishy-washy, frankly. We then go on to ISTQB. They define quality as ‘the degree to which a work product satisfies stated and implied needs of its stakeholders’.

You can look at ISO 9001 which is the quality standard. They say quality can be identified as ‘fitness for use, customer satisfaction, doing things right for the first time or zero defects’. When you look at all of those, there’s a common theme which is fitness for use to a satisfactory level. I guess, the question then is: how do you define the satisfactory level? You need something that’s more tangible and measurable, and the American Society for Quality helps there because they describe software quality as ‘a field of study and practice that describes desirable attributes of software products’. And then it helpfully goes on to define a number of different quality attributes like functional suitability, performance, compatibility, usability, reliability, security, maintainability, and portability. And that’s more helpful to us, isn’t it? Because that allows us to segregate it out and give it more meaning and then start to measure it.

When should quality actually be built into a software development lifecycle?

Some of us like myself are old enough to remember the purely waterfall days, where whole programs and projects ran along a linear build-test-fix approach. Thankfully, today I think we’ve moved along from that and even projects and programs that would deem themselves to be largely waterfall do try to factor in some degree of quality engineering throughout the SDLC rather than just relying on the testing chunk at the end.

Why is that important? We’re all probably familiar with the typical charts that map the relative cost of fixing defects against the time they’re detected. Essentially, the fixed cost rises exponentially the later on we record defects in the development cycle. That’s not a contentious point. I think there are lots of real-world case studies that demonstrate that to be the case. So largely, the more we can shift left (which is the kind of buzzword these days in terms of doing quality activity early doors) then the more time and effort and cost it saves us ultimately in the long run.

So, it all comes down to just get everything right as early as possible and you should be fine.

In an ideal world, absolutely.

How can people force quality down as an overarching objective so that becomes business as usual?

I think that can be difficult sometimes and I think a lot of it is a cultural way of thinking. In our world within Ten10, a lot of us are testing out on different client sites and I think we need to challenge ourselves a little bit to think about ourselves more as quality engineers (which I’m sure we do) rather than the traditional tester brand that we have.

I think that the challenge there is to try and adhere to a mantra around the whole defect prevention over detection – we should feel happier in ourselves if we’re, rather than raising defects towards the end and logging them and that’s what gives us satisfaction, we should almost be more pleased with ourselves if we’ve managed to deflect a defect even happening in the first place by highlighting erroneous requirements or problems with acceptance criteria.

There’s a lot we can do by pulling ourselves out of the tester box, integrating ourselves more with the wider business, understanding the products and programmes, talking to product owners, business analysts, understanding the market and customer expectations, and focussing on the early-level definition phase of projects and programs rather than just thinking that we fit in towards the end to tick boxes and test and raise bugs.

You raised a topic in there that I want to ask you about very quickly because I think a lot of quality engineering can naturally stick to defect detection and defect resolution but you mentioned defect deflection. Is that difficult to monitor and quantify? Because a lot of the time when we talk about quality engineering that can be quite a good benefit but it can be tough to show how that has impacted the business – when it’s a preventative measure and you’ve deflected it before it even gives you an issue. Is that tough to make visible?

It can be measured but not in the traditional sense, I guess so. If you imagine we’re testers on-site and we’re involved in spring planning sessions where we’re reviewing user stories and acceptance criteria for the coming sprint, it’s our job to ensure that the user stories and the acceptance criteria are concise, that they meet the invest criteria, that they’re fully testable and that we haven’t missed any as well. And I think what you can do is record wherever your inputs have logged a change. So it’s not like logging a defect in the traditional sense but if you can record that you made this change to this acceptance criteria, you came up with a new user story that your business analyst or product owner had overlooked etc. You can refer back to that in the future and say ‘these actions that we took early doors prevented raising a whole pile of defects later down the line’.

Knowing everything you’ve just said about quality engineering, how can someone get their senior leadership team to buy into quality engineering and truly make it a priority in their business?

This is a tricky one and I think unfortunately when projects and programs are under a lot of pressure to cut costs, quality assurance activity and testing etc. can often be the first thing that gets the chop. I think it is therefore incumbent on us to push back against the notion that a sub-par product or service is acceptable as long as we’re saving some money. It’s not, but how do we get that message across? First off, I think we have to try and dispel the myth that quality assurance is some form of overhead because the truth is that, in fact, it’ll probably end up paying for itself over time. Potentially many times over.

We’ve already spoken a little bit about mediating defects – if we can prevent them early doors rather than detecting them later, that’s an obvious saving. But there are other arguments that you can put forward as well in support of proper quality engineering. Some of it sounds like common sense but you’d be surprised when people get caught up in the heat of trying to deliver, they sometimes overlook these things. The most obvious one is reducing the risk of serious failures, as per recent things in the news with certain banks falling over due to software failures. They can literally be crippling. If they don’t fall over completely they can lead to regulatory fines, you suffer reputational damage, and you’re going to lose out on revenue from not just existing customers but potential future ones as well.

Another couple of things: enhancing your brand. Having a quality focus does ensure that your brand is then synonymous with a high level of quality. That gives you a bit of an edge over the competition, potentially. It’s not enough to just want to have a quality end product, we have to explain that quality management and quality engineering [are] actually essential to ensuring that outcome. And something else worth highlighting is supporting new business. Nowadays, reputation is quite big in the world of online reviews and social media. You can argue that having a quality product and brand is more important now than it ever has been, especially when it comes to attracting new business. The last thing we need obviously is a host of negative reviews and feedback discouraging potential customers from joining up and pushing them towards the competition.

So those are a few things. There’s probably more but it’s about getting in front of the key people on the program, having a chat, and repeating the mantras so the message goes in.

Work with our expert Quality & Test Consultants

Our Quality and Test Leadership is designed to help our clients by providing proven processes, templates and tools to enable current and future software change with confidence. Learn more about how we can help your business achieve its goals and grow a culture of quality excellence.