Dahlia Season Consulting

Originally published June 8, 2016 on cocktailmonkey.blog

With increasing frequency, I work with teams comprised of just software engineers. How do those teams build high quality software without dedicated QA?

In many modern companies, “developer” and “tester” are simply roles that people play. They are different mindsets that individuals adopt for the task at hand. I prefer to think of them as builders and breakers, both absolutely necessary to build great products.

The Builder Mindset, traditionally thought of as a developer or software engineer, is the ability to figure out what to build to satisfy the customer. The builder focuses on the happy paths through the software or the feature being built. They might identify a few error cases, but generally don’t exhaustively root out all possibilities for how the feature will misbehave.

Enter the Breaker Mindset, traditionally thought of as QA. The breaker mindset is the ability to identify how to break your code. What are the edge cases and error conditions? How will customers misuse the feature and inadvertently get into a pickle? How can this code interact with other parts of the system in ways that will negatively impact the system as a whole? Is this code safe or can it be exploited in any way? What will break as we scale or load the system? What will happen if an external system we rely on isn’t available? Will we impact system performance?

Some people may be natural builders or natural breakers. On every team that I coach, I work to ensure that a minimum of half of the team members become extremely skilled at adopting the breaker mindset. Regardless of what the natural mindset, I find that over half of the developers I work with have been able to become master breakers with time and practice.