Who Owns Software Quality?
A common misconception
As someone who has worked in both waterfall and agile environments, a common misconception that I’ve seen time and time again goes something like this:
The Software Developer is responsible for writing the code.
The Quality Engineer is responsible for writing the tests, executing the tests, making sure the new code fits in with the existing code, making sure the new code doesn’t break any additional workflow, making sure the code will work in multiple environments under different types of load, and making sure that the new code doesn’t introduce any security threats.
Team impact
Invariably, when code breaks in production, we’ve looked at the Quality Engineer and said, “Well, why didn’t you test that case?”
Unfortunately, this leads to a very unhealthy team mindset and an even unhealthier mental space for the Quality Engineer. I admit… as a QE, I used to have this mindset. I blamed myself for every single production issue that occurred. I was constantly pulling out my hair and biting my nails, and I was never at ease. I lived in fear of being fired because clearly all these defects should have been caught… by me!
Right?
Not exactly.
Our solution
In a healthy agile team environment, the whole team is responsible for the quality of the application, and therefore the code. So, it is not the responsibility of merely one person, but rather, it is a team effort to verify that any new code changes will work well in a variety of environments. This leads to a shift in the way the team has to think, starting at the very beginning of the process.
The first step of a new feature should be product discovery work and design/UX. Our product owner strives to understand the workflow and the requests coming in, so that our acceptance criteria can be clear and well understood by the team. In turn, the team helps the product owner clarify how the feature should behave by raising questions and additional use cases that may have not been considered at the time the user story was written. This usually involves the product owner taking questions back to stakeholders for clarification. Hopefully, by the time we get to planning, we have a user story that can be actioned on and is clear to every team member.
Then, the story moves into development. Typically, before any code is written, the developer and the tester meet and talk about what verification looks like for a given story. At that time, any known concerns are put on the table (for example, this change is impacted by time zones, so we’ll really want to focus our testing there!). This initial discussion opens a channel for communication about the progress of the user story and any challenges that will be encountered during development and testing. In parallel, the developer writes code and the tester designs tests, both automated and manual, to verify the feature is working well and won’t cause any additional issues.
Next step? Dev review! The developer will submit a pull request so that other developers can look at this code and assess it. This shouldn’t just be a check for naming conventions! The reviewer should pull and run the code, run through a couple of happy path scenarios, and make sure that the feature that was built is usable and working. This also gets a second set of eyes on the feature upfront to bring up any detailed questions about usability or performance.
Finally, we’re ready for the tester to have a look. You might think that the tester is always a dedicated member of the quality team, right? Nope! In fact, it is extremely useful for developers to learn how to test the system. Any developer should be able to pick up the testing of a user story; though I do recommend consulting with the dedicated quality member to help identify any specific use cases that have been known to cause issues in the past. Learning how to use the system from a user perspective is a great skill to have, and will actually enhance future development. This doesn’t mean the tester will never work on verifying stories. As a quality engineer, I often work with my team on verifying stories — this can be anything from me tackling testing on my own, to setting up an exploratory testing session, to pair testing with the developer who wrote the code, so that we can identify any weak spots both from functional as well as usability levels.
One last thing to mention — after your code has been tested, it’s tempting to drop it in production and forget about it. But! Teams that support quality test their work in production whenever possible, and watch error logs for a while following deployments to make sure that nothing nefarious is going on.
The whole team owns quality
In short, in a truly agile world, quality is owned by the team — not the tester. Everyone is responsible for excellent, usable products.
Interested in learning more about Vivid Seats?
We love sharing how we work together at Vivid Seats, and hope it can help others achieve success. Additionally, we are actively hiring for several roles on our engineering team. If you’re interested in learning more about open positions, check out our careers page at vividseats.com/careers for more information.
