top of page
  • Cotopaxi Lyon

Beyond the Code: Why Developers Shouldn't QA Their Own Work




Before we dive into this potentially contentious topic, we want to clarify two points.


  • First, this post isn't meant to throw shade at software developers. Your skills and talent are amazing, and we want to help ensure that your focus remains on your core strengths.

  • Second, while we believe developers shouldn't be responsible for end-to-end testing, they should absolutely be writing and running unit tests, and in many situations, integration tests.


With that clarified, we're going to say it: Developers shouldn't have to QA their own work.


Over the years, we’ve worked with numerous development teams and with various team setups. We've discovered that joining a development team as dedicated QA can take a weight off developers' shoulders and foster a partnership that delivers high-quality products.


Developers have expressed relief and appreciation when dedicated, trained QA are testing their work. This partnership allows both parties to focus on their strengths, combining creativity and analytical thinking.


The Benefits of a Second Set of Eyes


We've all experienced overlooking something in our work only to have someone else notice it glaringly. This could be while writing a blog post, cleaning the house, tuning up your mountain bike, or, in this case, writing functional, seamless code.

This is where QA comes into play, providing fresh eyes and testing expertise that developers may not possess.


Although that’s the most obvious benefit, there are several others worth mentioning:


  • Overcoming limited perspective: Developers may work on specific areas of the product, leading to a narrow understanding of the application. This can result in missed bugs or alternative use scenarios that the developer may not have considered.


  • Managing time constraints: Developers often feel pressed for time, and adding testing to their workload can lead to stress and missed issues.


  • Reducing context switching: Switching between writing code and testing can decrease creativity, increase cognitive load, and slow development speeds.

Is Dedicated QA the Right Thing to Do?


In most situations we’d say absolutely, but, it’s important to note that QA needs to be implemented with intentionality. Without it, your team could adopt some unwanted behaviors:


  • Silo thinking and "us vs. them" mentality: As sometimes happens, developers and QA have a contentious relationship that seems to find fault with the other, instead of working in partnership.


  • Throw-it-over-the-wall development: In knowing that QA is there to test the code, some developers may fail to slow down and do their due diligence to ensure their code works before passing off a finished product to QA.


The Importance of Organizational Culture


As surprising as it may sound coming from us, organizational culture is the most significant factor in determining QA success. Some organizations are successful at having developers also handle testing by providing them with the necessary time and resources. Others find that having dedicated QA can lead to antagonistic thinking, which often stems from a culture that does not support teams or prioritize communication and teamwork.


Organizations that foster a culture of collaboration, teamwork, and mutual respect experience the most success with dedicated QA. Just like you wouldn’t hire a framer to do finish carpentry on your house, we recommend not asking developers to do it all. Organizations need to ensure that they give their teams the support and resources they need. This includes ensuring that QA and development roles remain separate. The best products that we have worked on come from teams that have developers and QA, two roles that when partnering create great results.

Comentarios


bottom of page