The Blueprint: Quality Engineering Core Principles

In this post Slalom Build’s Quality Engineering capability will introduce our Quality Engineering Core Principles. These principles are used to clarify and communicate our point of view on ensuring quality in software development. Now that we’ve established them as a core part of our delivery methodology, we’d like to share them broadly. We hope you find them informative and hope they inspire conversations on the challenge of delivering modern software with quality.

Note: We’re hiring Quality Engineers right now! If you’re interested in joining our team, check out our most current listings here: https://jobs.slalombuild.com/#/?capabilities=Quality%20Engineering

Why core principles?

At the highest level, Slalom Build defines and communicates our quality approach through our Quality Engineering Core Principles. These four principles communicate our opinions on and preferred methods for achieving quality. We believe adherence to these principles, out of all the competing philosophies, helps us deliver higher quality software with more predictable results.

There are many, widely divergent views on how to best ensure quality when developing modern software. From dedicated teams of test specialists to self-organizing agile pods without assigned roles, from tests-before-code to offshore automation-as-a-service, development organizations must choose from a range of approaches when deciding how to best structure teams, sequence tasks, and assign responsibilities to ensure software quality. Many of these approaches are incompatible, and it is critical for any organization to decide, explicitly, which they will adopt.

While the core principles encapsulate our strong beliefs, they are not prescriptive. The particular demands of each project, technology stack, domain, and team require customization to appropriately address the unique challenges of the situation. Thus, the core principles describe preferences but give flexibility for practitioners to implement processes and approaches as necessary. Our principles are guiding stars, not commandments.

We defined these core principles to capture our point of view, but realizing them requires collaboration from the whole team. Quality is impacted by all aspects of software development, so we cannot define or execute a quality strategy without involvement from all other roles — Software Engineers, Program Managers, DevOps Engineers, Business Analysts, etc. A quality approach is a team approach, not something unilaterally conceived and executed by Quality Engineers. For each of these groups to effectively implement practices that ensure quality, we need a shared understanding of what quality means to us.

1. Whole Team Ownership

We believe in whole team ownership of quality. Successful, high-quality software delivery requires full involvement from the whole team; responsibility for quality cannot be delegated to a single role or person. Every individual on a software team must feel accountable for the quality of the deliverable, understand how they contribute to that quality, and actively and enthusiastically execute those responsibilities.

Organizations that delegate or centralize responsibility for quality to a “Quality Assurance” role and ask QA to guarantee or certify product code before release actually cripple their ability to deliver with quality. At best, this delegation is an innocent but misguided strategy to achieve some guarantee of quality. At worst, it’s a deliberate attempt by organization leadership to dodge accountability by using Quality Assurance as a scapegoat when issues arise. We do not believe that siloed ownership of quality is ever an effective strategy in modern software development.

Teams that embody the whole team ownership philosophy behave differently, and it’s incredibly powerful to see these teams in action. There is no “it’s not my job,” no throwing-code-over-the-wall, no sub-optimization of “my” specific task, or questions of “why didn’t QA find this???”, there is only a deep and continuous collaboration between all members of a team, driving towards a common goal. Teams that behave this way create a force for quality far stronger and more pervasive than any one role or person ever could. This whole team ownership culture is something we strive for in every development effort.

2. Empowering Teams

We believe in the role of a Quality Engineer, and this role is to empower teams by bringing a focus to quality. Quality Engineers bring expertise in test automation, quality assurance, agile processes, and CI/CD, among other things. If this seems like a lot, it’s because it is! Everything can impact quality, so a Quality Engineer must understand all aspects of software delivery and their relationship to quality. Quality Engineers use this expertise to champion, evangelize, influence, and advocate for quality, but they do not own it (core principle #1!).

Quality Engineers are a core part of every agile development team. They are not a separate team that sits outside or alongside. They are embedded in the team and collaborate as equals in the development effort. Look into one of these development teams and you will see Quality Engineers building automation frameworks, pairing with developers on story implementation, providing feedback on story ACs and testability, and talking with users to better understand use cases. The Quality Engineer has a demanding role that requires engineering expertise, strong communication skills, user empathy, and a “creatively destructive” mindset.

In modern software delivery, there are quality approaches that remove quality roles entirely and expect developers to own code from idea to production. These approaches work for particular organizations in particular circumstances, and it’s not our opinion that they are wrong or misguided. However, finding developers who are also experts in Quality Engineering is challenging. Allowing team members to specialize in Quality Engineering naturally leads to stronger, more effective teams. There are also approaches that outsource quality to external teams or organizations. We emphatically oppose all flavors of these strategies (see core principle #3). A dedicated Quality Engineer, operating as an integral part of every development team achieves the best outcomes within our method of modern, agile software development.

3. Value of Proximity

We believe in the benefit of close proximity between development and test activities. Success in software development requires effective collaboration between every person on the team; however, we specifically call out the need for close proximity between development and test activities because many common delivery approaches separate development from testing. This separation hinders a team’s ability to deliver with quality.

Proximity is not necessarily physical proximity; it simply means development and test activities are done at (virtually) the same time by members of the same, small team who collaborate in real-time with no barriers (process, technological, or other) inhibiting their interaction. It means that Developers and Quality Engineers are co-creators of a deliverable, not parts of an assembly line. It means that quality is built in as software is developed, not something verified later, before a release or at the end of the sprint. Quality activities are part of and inseparable from development.

What does this look like in practice? It looks like Quality Engineers participating in code reviews and merge requests. It looks like Developers writing tests (all types of tests!) as part of story development, often alongside or in collaboration with a Quality Engineer. It looks like Quality Engineers reviewing architecture plans for testability, and talking through edge cases and possible adverse impacts with Developers and Product Owners during user story refinement. All these activities serve to mix quality into development, bringing dev and test activities into close proximity.

While we advocate for close proximity, the particular roles and responsibilities and the day-to-day behavior of members of a team is something that should be left to the discretion of the team itself. There are many ways of creating close proximity. Is TDD mandatory? Should pairing on a story be encouraged or required? Who, exactly, writes each type of test, and when? Each team is empowered to answer these questions and create an approach that works for them.

Any approach that reduces the proximity of development and test activities decreases the efficiency and effectiveness of both and negatively impacts a team’s ability to deliver with quality. We continually critique our existing processes and seek improvements that support close proximity between development and test.

4. Automation is Critical

Automation is critical for high quality, high velocity delivery. The exponential explosion in the complexity of software and the move to iterative and incremental deployment processes makes it impossible to maintain velocity with slow, manual testing. Automation is necessary to ensure that validation keeps pace with development. Under-investment in test automation in iterative delivery will inevitably lead to a Regression Death Spiral.

While some organizations do prioritize test automation, many of these organizations still fail to reap the benefits of higher productivity. Just writing the code to automate tests does not necessarily lead to any benefit. Dogmatically requiring a team to have X number or Y percent of all tests automated, without adequate planning and forethought leads to bloated, slow automation suites that are often ignored and seldom provide value.

Healthy test automation must be treated as a type of software engineering and leverage the same rigorous processes (design reviews, code reviews, linting, etc) as production development. Quality Engineers collaborate with the team to define and continually evolve an automation strategy tailored to the specifics of the software architecture and technology stack. Understanding this challenge and driving automation approaches that positively impact velocity is a key area of expertise that Quality Engineers bring to development teams.

Conclusion

Together, these four core principles define our point of view on how to achieve quality in software development. This is not the only way to approach quality — there are many successful software companies that think differently, and that’s fine. These principles work for us and our development model, derived and refined over years of software delivery with hundreds of clients. None of them represent original thinking — all are derived from or influenced by companies or individuals who’ve shared their own opinions on quality. They are not perfect, exhaustive, nor set in stone, but are starting points for longer, deeper conversations about the complex challenge of ensuring quality in modern software delivery. We strive to realize them in every delivery effort, but our understanding is always growing, and our industry is always changing. What works today might not work tomorrow, but evolving our approach for the next challenge is half the fun.

Each core principle deserves significantly more attention than can be provided here. However, we hope the above introduction gives you an idea of who we are and what we stand for, and how we prefer to approach the complex challenge of delivering modern software with quality. Eventually, we hope to publish a more detailed and thorough description of each core principle.

And don’t forget to take a look at our current QE openings. We’re looking to hire great people at all experience levels. https://jobs.slalombuild.com/#/?capabilities=Quality%20Engineering