Why quality engineering?

Having worked in the software engineering space for 20 years and for much of that as a Software Tester, I've always had one question driving me forward, How can we build better software?

For a lot of that time, I believed that if we could catch as many of the issues in our systems before they got to our users, we could deliver high-quality software. Unfortunately, this only worked if you had an army of testers, and the pace at which the system changed could be measured in months and years.

But we now live in a world where software can be changed in days, hours and even minutes. We need a way for software teams to test as fast as the software can be modified. The solution appeared to be test automation, specifically User Interface (UI) automation. If we automate our testing, we can likely catch more issues quicker.

At first, UI automation helped, and the need to have more testers diminished. But the speed at which the software changed also meant the UI tests needed to change at the same pace, and the more UI tests you had, the bigger this problem became. It looked like to keep up, you needed an army of automation testers.

We were left with three choices. We either slow the pace of delivery so the testers and automation engineers can keep up, add more automators or rethink how we deliver software. The first two options were not a choice for most teams, so rethinking how we deliver software is the only viable way forward.

I should have seen in both our approaches to delivering that testing for issues either manually or via automated UI tests were both versions of the same idea. That being inspecting for quality by finding the problems after the software was built. But what if we did as William Edward Deeming said back in 1986, and instead of inspecting for quality, we engineered quality into the system?

Over the last seven years, this is what I've been trying to do. This newsletter is my attempt at sharing what I've learned along that journey and how more of us can build quality into our systems rather than inspecting for quality, which I call quality engineering.

Quality engineering is more than testing earlier in the software life cycle. It's about looking at all the facets of software engineering. From delivering the product to the processes we use to build it and the people involved. It's about taking a holistic approach to quality and understanding how quality is created, maintained and lost throughout the software life cycle. It is then, using this insight, we build quality at the source.

I aim to post every two weeks, with each issue containing short summaries of my views on how quality engineers can help build, maintain or lose quality focused on what I believe are the three core areas of quality engineering. These are the people, the processes and the products.

So if you’re interested in seeing how this journey develops or want to improve your skills as a quality engineer, sign-up below to receive regular updates.