Quality Engineering: Real-World Advice for Managing People and Processes

Quality engineering is a practice that harnesses automation to maximize people’s software testing and product quality efforts. To do so, it requires processes that enable people to adopt new technologies and collaborate easily. So how are real-world organizations driving technology adoption and getting more people involved in testing? 

Ask the Quality Engineering Experts

At mabl Experience, quality leaders from SmugMug, Enbridge, and Barracuda covered these topics and more in a roundtable discussion. Read below for highlights from the session, then check out a full recording of their conversation here.

Rethinking the Software Testing Process

Mabl's Testing in DevOps Report found that most software development professionals list slow adoption and a reluctance to change as their biggest DevOps obstacles. We asked the panel how they successfully overcame this reluctance and implemented new, more efficient quality processes. 

Janet Bracewell, Senior Engineering Manager, QA at SmugMug: We came from a totally manual process. Early on, the idea of automation — where you wouldn't see what was happening — was difficult. And the other part of that was the idea that we [the QA team] were always the last stop before the customer. Often, our developers weren't really thoroughly testing their code — they'd hand it to us and say, “find everything.” There was a fair amount of friction between developers and QA, and there was nothing especially speedy in that process.

Jessica Mosley, Senior Quality Analyst, Enbridge: Being part of the Technology and Innovation Lab within Enbridge provides a unique opportunity; we’re kind of like a startup within an already established company, and we’re able to innovate processes and procedures that are currently within the company. We found that we were being seen as some sort of critique on previous processes — but that's never the case. [Our goal] was to make what has already been created a lot more efficient and optimized. 

I understand the hesitation from some companies to not want to jump on the digital bandwagon — they think, “well, we spent all this money on this.” We had to make it clear we weren’t taking away from anything but were innovating on it. 

Building a Culture of Quality with Test Automation

The Testing in DevOps Report also found that full DevOps adoption was closely correlated with a culture of quality, where a wide range of people are engaged in software testing. The panel weighed in on how mabl helped their team expand testing throughout their development pipelines. 

Andrea Wood, VP of Engineering, Barracuda: Mabl gives us the opportunity to continue to have quality influence upstream. Because it's not purely a tool that only QA engineers or automation engineers can be in, it gives exposure to developers and product managers. 

Janet: Part of the problem with being a busy platform is that you have to literally carve time out to learn. Mabl isn’t a difficult platform to learn, but it has intricacies. We put a two-hour block on Wednesdays that we call QA Learning, which we set up for mabl learning time and practice. Additionally, we embed QA on each of our product teams, so there's a voice that keeps reminding them about mabl and automation. And we add it to Jira tickets. 

Jessica: One of the things that I initially started doing was little sessions called “Dangerous with mabl.” We just wanted to demystify what mabl was and what it was not. We were making sure that this was a quality culture — that it doesn't have to be where the testers or QA engineers are doing this alone, that we all have a part to play in this, so why not know how it works from beginning to end, and how the tests are created? These sessions created a great atmosphere for everyone to learn about mabl, and that's been very, very fun.

Maintaining Quality Engineering Momentum

Transformations like DevOps and quality engineering take time, increasing the risk of projects stalling before meaningful improvements are made. We asked the experts how their companies were sustaining change and how their teams were continuing to evolve.  

Andrea: Our mission is to provide a more unified customer experience across our products, so it always starts with the customer. But in providing a unified customer experience, we have to have a lot more consistency around how we develop products, test them, deploy them, and get things out the door. Mabl is part of our strategic initiative to bring some consistency to our CI/CD pipeline and even to the UI layers of these products.

What we found with mabl is that good things resonate. Mabl started with a few Barracuda teams doing a trial and expanded rapidly. I think now 10 or 11 teams are using mabl in various stages. But because it is such a powerful tool and moves the needle towards where we want to be, it's growing within these teams very quickly. Many teams are finding that it is transforming how they think about QA — it is moving a quality influence upstream in their discussions.

At Barracuda, it's still QA engineers or QA automation engineers creating the mabl tests. But there’s a lot more involvement from the team as a whole in what test coverage should be and what test plans should look like.

Making Your Case for Automated Software Testing

Budget issues are frequently cited as a major inhibiting factor to DevOps and quality engineering, so our panel of experts shared how they advocated for their organizations to invest in testing automation. 

Jessica: The real turning point was being able to assess mabl in person-hours equated to money, especially set up and maintenance costs. Leadership wanted to know, “well, how much is this going to  cost?” I showed them how much it would cost them NOT to do it. 

And also, it was very helpful being able to showcase mabl’s features and its ability to get tests up and running quickly. It usually takes people weeks to get things going, but with mabl, you can get a test suite up and running in a couple of days, if that. So the time that it would take and the money they'd be losing in waiting was how I presented it. I proved that they were going to see ROI very quickly.

Janet: I remember the moment in a quarterly planning meeting where we had engineering and product leaders. Part of my slide deck was a graphic that included best guesses on cost, e.g., here’s what it costs when you find a bug in development, and here's what it costs when you find it in integration, here’s what it costs when you find it on production, and here's what it could cost if you have to roll it back and redo it. And I remember the look on the face of our VP of Product — a very visual person — when he finally got it!. So it was easy for him to say, “Whatever you need with mabl” after that point because he saw it was very effective.

Andrea: Speed of delivery is important, and if we can quantify that — if we show them that by getting test automation in place, we’ll be able to deliver features faster, then that's something the business can understand. It’s a clear win. 

Another thing is one of our product QA managers has a spreadsheet that gives visibility to ROI. On the spreadsheet, you can see previously (when we did it manually), it took five hours. Now with mabl, it takes 45 minutes. You can start to see the value not just in the test creation but also when the tests are running. The company now knows how valuable mabl is. There's no friction now to adding more workspaces, which is good.

Adopting Quality Engineering, Together

The journey to quality engineering takes time, patience, and team-wide effort, but with collaboration, test automation, and data, software development organizations can sustain momentum to deliver meaningful improvements to product quality and the customer experience. 

Start your quality engineering journey by signing up for our 14-day free trial.