The Swiss Cheese Model for Quality Engineering
Having the time-honoured ‘Test Pyramid’ phenomenon drive a quality strategy alone isn’t good enough anymore. Here’s a more holistic thought pattern.
Quality is much more than just automated tests. Though quite popular in the software industry, this concept can still be a hard one to sell to engineering teams, leaders, project managers, and others.
Over the years, the role of a ‘Quality’ champion, ‘Quality Assurance specialist,’ ‘Quality Engineer,’ or simply ‘Tester’ — whatever title you choose, has evolved. And it had to; the science and art of what we call ‘Software Engineering’ is the all-burgeoning, ever-evolving space that it needs to keep pace with.
The concept of ‘The Test Pyramid,’ first introduced in a methodical fashion by Mike Cohn in his book ‘Succeeding with Agile: Software Development Using Scrum’ has also evolved to a certain degree. It has been written about, discussed, and debated to the hilt since then. If you’d like to explore the test pyramid further, this post from Martin Fowler sums it up the best.
But, there’s a question as to whether the test pyramid covers all of the aspects around good Quality Engineering concepts comprehensively enough. In my honest and humble opinion, no, it falls short. At least it doesn’t talk about all of these aspects explicitly.
So, let’s explore this further!
There is no denying that having the ‘test pyramid’ thought pattern within the foundations of a good quality strategy will ensure engineering teams can deliver a good quality product. Having thorough unit test coverage, different types of component/service level/integration tests, and a smaller suite of some E2E tests go a long way in helping teams ensure good quality. However, having the test pyramid as the sole driver for all required quality engineering considerations can result in an sub-par quality strategy as some additional concepts can strengthen it further. What could these be, you ask? Let’s step off the beaten path for a second.
Since COVID-19 has affected almost every person on the planet, directly and/or indirectly, and since prevention and safety around COVID-19 safety measures continue to be a part of our lives, we’ll take some inspiration from this. I came across a wonderful model last year around ‘Pandemic Defense’ that helps understand the reasoning behind all the lockdowns, restrictions, and pep talks around developing better habits, all these concepts that we have been exposed to over the last couple of years.
Now, imagine software bugs as malicious germs, an anomaly that affects our daily lives. And let’s think of these layers of cheese as the controls, the ‘quality’ habits, ‘gates’, or ‘helpers’ that engineering teams can put in place to block these malicious ‘bugs’ from reaching the customers.
The principles around needing this defense model also can be applied to software engineering.
- No single layer is perfect; each has holes, and when the holes align, the risk of damage from these bugs increases.
- But several layers combined significantly reduce the overall risk.
- However, it requires all, not just one of these elements.
- One of the first principles of pandemic response is, or ought to be, clear and consistent messaging from trusted sources.
OK. Let’s start identifying some of these ‘layers of cheese’ that constitute this ‘Swiss Cheese of Quality Engineering’ model. And yes, all the components of the testing pyramid will be featured here, marked with *, but there are a few more added in.
In the image above, unit tests, integration tests, and E2E tests still play key roles, but we are also focusing on other best practices around software development and trying to view them all with a ‘quality lens.’
For example, getting analysts, developers, designers, platform engineers, and others to collaborate and write robust user stories using the “three amigos style” story grooming technique can be such a valuable addition to a software development team’s repertoire. It not only creates stories that are more robust and testable, but it also facilitates ‘team bonding,’ something that is a cornerstone for building teams that deliver high-quality software.
How best to use this model?
I’d like to suggest that software development teams get together and workshop this ‘Swiss Cheese Model for Software Engineering’ when drafting ‘quality strategies’, thinking about which slices best suit them, which ones apply to their projects and/or clients, and how they should sequence or program them in such a fashion that these augment each other. The scope and size of each of these slices can be determined based on the client’s needs, customer base, and more, but they should all make it into a quality strategy discussion during workshops, to ensure that the teams are delivering a wholesome, holistic version of quality.
The beauty of it is that what’s suggested above isn’t a comprehensive list. It’ll never be. For example, I started discussing these concepts with some colleagues outside my current team in reference to a different project, and the following cheese slices came up for discussion:
And there’ll be more…
I sincerely hope that this approach doesn’t just become a checklist item, a template, or a mental note when my fellow Quality Engineers are thinking about quality strategies. So, here’s wishing you a positive experience when you workshop the ‘Swiss Cheese Model for Software Engineering’ in your organization!
