“Testers are slowing us down. We would be so much faster without them.”
As a developer for my entire career, I’ve seen this exact comment or variations of it happen at many places I’ve worked in. Early in my career, I also echoed the sentiment. Unfortunately, it’s a common occurrence that development teams aren’t entirely in sync with the work done by the QA team, where we perceive testers as an obstacle to progress. As a result, there’s a constant stream of bickering and passive-aggressive arguments flowing through these companies.
Most of these opinions initially stem from organizational pressures to crank out code as quickly as possible so we could deploy as many features as possible. One of my first jobs in a startup had me working often in three-week stretches without taking a day off since we had a “do or die” mentality. It felt like if we took a day off, the company wouldn’t survive long enough to bring its vision to life.
A few years later, the company didn’t survive. I didn’t know any better when I was in my 20s.
The situation didn’t get any better later in my career when I moved to San Francisco. At that time, the lean startup methodology was running rampant throughout the countless startups in the city, peaking when Eric Ries’ book of the same name came out. One of the tenets of lean startups is to fail fast. It’s a good sentiment for fostering innovation since it lets companies throw out dozens of ideas to toss out the bad ones and see what sticks. But developers like myself often took it as a sign to move fast at the expense of quality. In my mind, testers stand in the way of that “fail fast” mindset.
In many organizations, the goals of the QA department vastly differ from those of development. Software development, especially at startups, is all about pumping out new features quicker than competitors. Testing is about maintaining and improving the quality of the end product. Eventually, those two philosophies will clash since it’s extremely difficult to get something done quickly and well (unless you’re willing to spend money to achieve it). And although it’s entirely unfair, businesses will typically side with developers, leaving testers and their objectives in the dust.
How Testers Speed up the Work of Developers
Now that I’m much older and hopefully a little wiser, I can see what both sides bring to the table instead of focusing on my role as a developer. I’ve realized that most organizations fail to know that testing can become the most potent accelerant to developer agility. Testing isn’t something that slows teams down or prevents them from shipping. When done right, it’s a process that will significantly speed up the entire process.
The work that testers do helps make development work faster in plenty of ways. Here are a few fundamental examples I’ve seen throughout my career that might slide by unnoticed by most development teams.
Much better feedback loops
It’s been proven in many studies that detecting bugs earlier in the process is much cheaper compared to addressing them once they’re out in production. A developer can fix a defect caught by their CI service in minutes after they push out their code, but that same defect can take days to address once it’s mixed with dozens of other code commits and is already out in the wild. It’s one of the reasons why so many organizations are placing more emphasis on test automation, hoping to catch issues earlier.
Developers often try to speed up the testing process by leaning heavily on test automation instead of other testing methods. Automation helps catch regressions quicker, but it isn’t a bulletproof solution. Your automated test suite might not yield any clues as to what went wrong, especially with integration and end-to-end testing, where many different pieces of your project come into play. If you’re lucky, automated test failures might give you enough details to know where to fix the problem, but far too often, you’ll get cryptic stack traces that don’t indicate where to check.
Teams that rely on test automation as their primary source of quality assurance are missing out on the valuable feedback humans provide. The exploratory testing done by QA teams often yields better results in both breadth and depth compared to automation. A computer will only do what it’s told and spit out whatever the tool says. But a tester brings critical thinking and can explain exactly where things went wrong. This process may feel slower initially, but its much-improved feedback loop helps developers fix issues quicker and leads to a more efficient development lifecycle.
A safety net for needed code maintenance
Another way that testers help increase development agility is by giving developers a safety net when they need to handle cleanup tasks like refactoring unoptimized code and upgrading existing libraries. These days, it seems like every week, there’s a new update for the tools that developers use to build their applications (or every day if you’re a JavaScript developer). Many of these updates are minor revisions like a security vulnerability patch or internal refactoring that don’t affect existing functionality.
However, it’s not uncommon for a seemingly insignificant update to break an application and not get caught by automated tests. Earlier this year, I upgraded a Ruby on Rails application from version 7.0.4 to 7.0.4.1, a minor hotfix release, to help patch some security vulnerabilities. The automated test suite passed successfully after the upgrade and was pushed to our staging environment. I was just about to deploy to production later that day when a tester on the team noticed her account was constantly logging out. It turns out that the hotfix release introduced a bug in how it handles cookies that affected us. None of the developers reviewing the code spotted it, and we had no automated tests for this particular issue.
This example shows how testers are a valuable safety net for maintenance tasks, no matter how small and insignificant these tasks seem. While the example above wouldn’t have caused significant issues like data loss, it would have been enough of an annoyance to existing customers that led to them potentially abandoning the product. Developers and test automation tend to miss more minor details in this type of work, which is where testers shine, thanks to their exploratory testing and observational skills. Knowing that testers have the development team’s back in case of emergency makes a massive difference in developer productivity.
Keep a finger on the pulse of quality
As mentioned earlier in this article, developers often have pressure from their managers to churn out code as quickly as they can. Besides producing not-so-efficient code, another byproduct of the demands to spit out code quicker is that developers don’t pay much attention to the state of quality in a project. They might have obvious indicators like exceptions in all environments, features not working as expected, or the team’s agility slowing to a crawl. However, those issues are typically lagging indicators that show the results of poor development practices, meaning that it’s likely that these issues will continue unless their actions improve moving forward.
What teams need to improve the health of their systems are leading indicators that can help them predict and guide the health of their projects. Many developers have no clue if the code they’re pushing out will negatively affect the application’s overall quality. Senior developers have enough experience to detect if a modification will create future problems like performance issues or increasing complexity in the codebase but choose to ignore them at the time because of time constraints and other demands on their work. Most teams operate reactively, only dealing with issues when they become obstacles to productivity. What they really need is to work proactively.
Having a good feel for the quality of a system is another area where testers excel. Their expertise in testing creates sharper analytical skills and better attention to detail than a typical software engineer. They’re also much better at identifying risks, especially future obstacles to the application’s health. These combined skills are vital in ensuring the reliability of our products. Instead of waiting for something to blow up, testers are there to give us the heads-up teams need to mitigate problems before they snowball into more significant headaches.
Making Developers Understand How Testers Improve Their Agility
The ways that testers help developers speed up their work and increase their output might be evident to anyone in QA. However, it doesn’t mean that all developers fully understand the importance of the duties that testers do to improve agility. I’ve realized this disconnect is the root cause of many clashes between development and QA teams. To prevent this from happening in your team, here are a few ways that testers can help developers understand the impact of their work beyond reporting bugs.
Highlight the outcome of your work
Something I’ve noticed throughout the years working alongside QA departments is that testers don’t spend too much time highlighting the benefits of their work. Sometimes, it’s because they’re shy. Other times, they feel like they’re bragging or can potentially make others feel inadequate. They might also rely on their managers to present this information. Whatever the case, it’s a missed opportunity for testers to show the entire team how they have specifically helped improve the development process with something they accomplished as an individual contributor.
For example, I once took a few weeks to set up an end-to-end testing framework for an application. When I finished the initial test suite, some of the other developers on my team thought it was a waste of time and that I should have spent that time building new features for the project instead. The automated tests began catching minor issues effectively, and a few weeks later, it detected a nasty bug that could potentially destroy some data for our customers. In the next team meeting, I showed how those tests caught those problems and mentioned that it could have created a minor disaster for developers had it slipped into production. Since that moment, I never received any complaints about spending time improving the team’s testing processes.
A lot of the conflict that surges between development and QA is when developers think that testers aren’t directly contributing to development agility. It’s a misguided attitude, but as a developer myself who has briefly floated these thoughts in my head, we need reminders of the improvements that testing brings to the table. Don’t rely on managers or reporting software to summarize what you do. Take opportunities to show where your testing work has positively impacted the development process whenever you can. When done calmly and objectively, you’re on the way to bridging any gaps between developers and testers.
Use your collaborative tools to your advantage
Most software companies nowadays use collaborative tools like Jira, Trello, and Linear to organize and keep track of the work that goes from planning to development and testing. Unfortunately, the primary use of these tools is to shift things from one department to another without the “collaborative” part coming into play. Even worse, this handoff often happens in a passive-aggressive manner on most teams. We’ve all reassigned or closed a ticket in the system with a dismissive “Works on my machine” or “Can you check it again?” without any attempt to follow up on the resolution of the issue.
As an observer and sometimes participant in this back-and-forth of tickets between QA and development, I have seen this issue derail project schedules because of the lack of collaboration between the involved parties. Developers work on their tickets and move them forward to QA for testing without any context. Testers try their best to do their work with limited information, and when they find any issues, the ticket gets sent back with few details. This dance of shuffling tickets between both directions can eat up entire days of the team’s schedule. Add in scope creep, regressions, or any other unwanted surprises, and suddenly, your project is a month behind its deployment date.
QA should use this as an opportunity to work together closely with development. Instead of using these collaborative systems to pass tickets around, QA should get together with developers and project managers to prioritize issues since not all tickets are equal. Testers can also improve workflows by using the functionality built into these tools, like setting up automation based on labels or comments, which can significantly reduce the back-and-forth of tickets. Combining these and other tactics provides an excellent opportunity to improve communication and demonstrate daily how testers make development work more effective.
Educate as much as possible
Many developers don’t fully grasp what QA means in an organization. Most developers have a superficial understanding of what testers do. At best, they have an idea that it helps the quality of their work even if they don’t know how it happens. Unfortunately, it’s more common that a developer’s concept of QA is that they’re just bug-hunting robots that don’t employ any critical thinking in their daily work. That can’t be farther from the truth, but it’s how many think. Usually, it’s because they don’t know any better.
Early in my career, I was one of these developers. I viewed anyone labeled “tester” as an obstacle to progress, slowing down our attempts to get work out into the world. I ignored any attempts to understand more of what QA does. In my first job as a Ruby on Rails developer, our project placed very little significance on testing, further cementing my views on QA. A few months later, an intern joined the team to help with quality and testing. He ensured the development team understood its importance by sharing information freely and showing examples of how his work helped us move forward faster. Seeing the process first-hand and having it explained to me was a transformative moment that changed my career.
More organizations would greatly benefit if more developers had the opportunity to directly see how testing allows them to work faster and more efficiently. Educating development teams about the impact of QA can take many forms, based on your team structure. Pairing developers with testers for feature work is one of the most powerful ways to share this knowledge. Organizing “lunch and learn” meetings where testers can teach developers about testing topics is also a helpful tactic I’ve seen work well. I strongly believe that testers need to take the lead on this because it’s not something that occurs naturally in the progression of a standard workday. Sometimes, all it takes is just a little teaching to shift someone’s mindset entirely.
Conclusion
Whether you’re an engineer or a tester, I hope this article shows the crucial role that testers and QA play in developer productivity. Many developers can become dismissive of the work done by QA. The reason I wanted to write this article is because the ways that testers help speed up the development cycle aren’t immediately apparent to most. Any organization developing software can benefit from understanding these actions, combining the development focus on features with the testing focus on quality to create a complementary force for building reliable software quickly.
Both development and QA teams need to recognize the value that each side brings to the table. Testers should feel empowered in their role and appreciate that their contributions are vital to the team’s agility and success. They can achieve this by helping foster a culture of teamwork and mutual understanding of the functions provided by testers throughout the software development lifecycle. It’s my hope that it can lead to the creation of a better working environment through collaboration and the efficient creation of high-quality products.
Are You Looking For Someone to Help Bridge the Gap Between Development and QA in Your Organization?
If you currently work at an organization struggling to have developers and testers work together smoothly, you can benefit from some expert guidance. With nearly 20 years of experience working with development and testing teams worldwide, I specialize in bringing together both worlds for a streamlined approach that will boost your company’s productivity.
I offer solutions tailored to your organization’s specific needs. My approach isn’t about implementing tools and processes. It’s about coaching your team through any obstacles and focusing on developing a mindset of shared understanding and collaboration, which is critical for any successful software development project. Without these, you’ll continue running into roadblocks that will sink your business.
Whether tearing down the communication barrier between teams, setting up effective testing strategies, or aligning development and QA priorities, my experience and practical knowledge will help make your teams happier, more effective, and more productive. Reach out and let’s collaborate on making this dream a reality.
