Quality is Everyone’s Job: How to Get Your Dev Team to Embrace Automation

In an attempt to maximize efficiency, many organizations are asking Developers to contribute more to the testing effort, blurring the lines of responsibility between “Development” and “QA”.  After all, nobody knows the code better than the Developer who wrote it. Although it’s difficult to dispute that fact, software testing requires a certain level of expertise and one cannot assume that a skilled Developer will necessarily equate to a skilled tester. 

You may find that many Developers are resistant to this way of working. These Developers may believe their job is to “write code” while it is someone else’s job to test it. Some Developers may also believe their code does not need testing. In some companies, it may not be uncommon to have unwitting customers do the testing in Production. Facebook and Etsy have popularized this way of working, having the advantage of being the leaders in their space while investing in canary release processes, automation, and monitoring. But what works for them might not make sense for all organizations.

Quality is Everyone’s Job

It’s a challenge for organizations to enforce the notion that “Quality is Everyone’s Job” especially if that has not historically been part of the Engineering culture. So how do we change that line of thinking? Being concerned only about “the code” is shortsighted and requires Leadership to enforce “Big Picture Thinking” to help improve the quality of the products. If there are some Managers and Leaders who are resistant to this philosophy, then it will be difficult to enforce.   

The “shift left” testing movement is concerned with pushing testing toward the early stages of software development. By testing early and often, teams can reduce the number of bugs, minimize the number of surprises, and increase the quality of features, leading to more satisfied customers.

Beware the technically brilliant, but short-sighted, Developers who are only in the Software Engineering field because they enjoy writing new code, refactoring someone else’s “shitty code” and building their resume by working with the latest frameworks. They have little interest in the business and improving customer satisfaction. But because of their strong technical skills, they are valued in their current role and can find a new job on a whim. They may be difficult, if not impossible, to convert to this new way of thinking.  

Dev vs QA Teams?  

It’s not uncommon for companies to have separate QA and Development teams in which QA is not considered part of Engineering. In these environments, you may find that QA is typically not as respected as Development. Their salaries are lower and their skills are not as valued.  As such, they may be considered easier to replace or outsource.   

Ask any seasoned QA veteran about the “good old days” and I am sure they will be happy to share stories about having new features dropped on their lap with little business context and no access to the code.  In this model, QA is often not invited to participate throughout the Planning and Development cycles.  Instead, they may be considered a nuisance and afterthought. They may be asked to “sign off” on a feature without having any real input as it is being built. This can limit the effectiveness of testing and lead to frustration for all parties involved.

Team Roles and Responsibilities

As Software Development has evolved, so have roles and responsibilities. In some well-functioning organizations, QA members are embedded in Scrum teams, understand what is being built, collaborate with Product and Development, offer valuable feedback, build test cases, and have some authority to enforce the Definition of Done. If QA is not satisfied with the level of Quality, they can delay new code from being released. 

Some companies employ “Whole Company Support”, also known as “All Hands Support”.  In this model, people from other departments work alongside the “Support Team” to solve customer issues. This is a great way to knock down walls between groups, build empathy with customers, improve product knowledge, and increase “Big Picture Thinking.”  

Rotating Developers into a Support role for a few days during onboarding and regular intervals pays dividends. I have found that this is one of the best ways of increasing “Big Picture Thinking”.  It builds well-rounded teams that have business context and an understanding of their products and customers. However, you may find that some Engineering Managers are hesitant to “waste their team’s time” doing Support. This negative attitude towards Big Picture Thinking can be a roadblock to progress and must be dealt with at a Leadership level.     

Support professionals will likely tell you that they field many of the same questions every day.  Instead of making excuses for the shortcomings of the product, Developers have the ability to open up their laptops, FIX the problems, and bask in the accolades of customers and the Support team. This is immediately gratifying, empowering, and eye-opening. 

Having an intimate understanding of how real customers use your company’s products can help shape Development and Testing efforts. No longer will Developers only be concerned about “the code”; they will now have a better understanding of how their code affects real people and the usability of the product. Make support part of the process, not something to avoid. 

(For more information on “Whole Company Support”, please see this article on LinkedIn.)

For those Developers who are really only interested in the more technical aspects of Software Engineering, all is not lost. Perhaps their role can be expanded to help create automated testing frameworks, automated tests, instrumentation, Continuous Integration and Continuous Deployment. They can work at the intersection of Development, DevOps, and QA building systems to improve reliability and speed up delivery.

Where does this leave QA?

In a structure where Developers take on more responsibility for testing, QA may take on more of a “Quality Advocate” role in which they oversee the testing but are no longer solely responsible for it. They should be involved throughout the Development cycle, from ideation to requirements gathering to testing, release, support, and maintenance. This will allow QA to better understand what is being built as well as allow them opportunities to offer their input and expertise. 

With time and training, QA often becomes product experts and can use this knowledge to become “system testers” where they test the product as a whole.  

QA should also be responsible for organizing UAT (User Acceptance Testing) sessions, gathering user feedback, and distilling that feedback into reports for the Product and Development teams.  These UAT sessions will help validate what the team has built and QA can play a key role in being the liaison between Customers, Support, Product, and Developers.    

More technical members of QA may have the title of QE, Quality Engineers, or SDETs (Software Development Engineer in Test). They can use their skillset to contribute to test automation. If Developers have taken over this responsibility, QE can oversee these efforts while working across multiple Scrum teams, contributing to a System Testing, big-picture mindset.  

The plain truth is that the more technical members of the team usually get more respect. In the software industry, constant change is certain. Roles are ever evolving and companies are trying to find ways to improve efficiency by squeezing more out of their people. I have found the most effective members of QA enjoy being product experts while constantly learning and pushing themselves to blur the boundaries between QA, Support, Product, and DevOps. Being able to play such a varied role will help ensure that QA is highly visible and considered a core part of the Engineering organization.