How Smart Testers Get Developers All-In on Testing (and Ship Faster)

When many development teams have dedicated software testers, developers can be tempted to throw untested code at them with the “not my job” mindset. What this leads to are overloaded testers and poor software releases.

You can decide to do it all by yourself, putting in extra hours, or you can learn how smart testers actually get developer 100% invested in testing, reduce their workload and ship faster. It works, take it from me, I’ve tried them.

Here’s how I’ve gotten developers involved in software testing in teams I’ve led.

1. Involve Developers From The User Story

Quality isn’t just the tester’s job; it’s everyone’s Job, and it starts with the user story.

When you get every team member to contribute to the user story, you create a shared sense of ownership which enables developers to create technical specifications that actually satisfy those criteria. When the products meet these requirements, there are fewer bugs and back-and-forth, which means less work for you. Maintaining clean code practices is another way to get a project done with fewer bugs. And by “done”, I mean when the feature is in production, not when it's committed to the development branch. When every team member understands that their job isn’t truly done until the feature is live and functional for the users, it creates a sense of shared responsibility for the entire development process, which, of course, includes testing.

By shifting developers’ mindset from “my job ends when I push my code” to “my job ends when my code makes it to production”, they get more involved, and you’ll end up with quality products with minimal iterative tests and bug fixes.

2. Get Developers to Demo Their Work

I don’t know about you, but I don’t know a single developer who wants to mess up a demo, even if it's a 1-person audience.

Including product demos in your development processes or during your meetings forces the developers to take responsibility for their contributions because they want to look good. This creates a sense of ownership and motivates them to put in that bit of extra work to make sure everything goes smoothly on demo day.

It also gives the team an opportunity to provide early feedback and catch bugs. For instance, if you observe a bug during a demo, that’s one less feature for you to test and a meeting to schedule with the developer. You should be careful not to make this a “finger-pointing” session, though. When you observe a bug, don’t linger on it; simply note the bug and move on. This way, developers don’t see demos as an avenue for scrutiny.

So, if you want to get developers more involved in testing and reduce your workload, push for demos to be included in your development process.

3. Encourage Peer Review Practices

Peer review not only filters out potential bugs but also allows developers to improve their coding practices over time.

When developers adopt the same coding standards and practices, it creates a shared expectation in code quality, resulting in better quality products down the line. It also reduces the amount of time you’ll spend testing and creating bug reports. It is important to note, though, that you’ll have to put some effort into documenting these standards so that developers don’t impose their preferences on their teammates, which could lead to rifts in the team and unnecessarily long reviews. Usually, this task falls under the tech lead, who you would need to communicate with regularly, but more on that later.

By getting developers to take responsibility for their code, you reduce the testing team's workload, leading to a higher-quality product.

4. Integrate CI / CD Into Your Development LifeCycle

If you want to get developers more involved in testing, then continuous integration and delivery is a must.

CI/CD give you the opportunity to create and automate code and quality standards constantly verifying or validating code. That immediate feedback eliminates the need for you to test those features yourself and saves you back-and-forth that might occur with developers when there’s a bug in the system. Bad code won’t get into production as any code that doesn’t pass the defined standards won’t build, so developers know their work isn’t done until all CI/CD pipelines are green, again improving product quality. Just to note, this isn’t a tester vs developer thing. Integrating CI/CD into your project also benefits developers as it gives them early validation that their code meets the quality standards. And I don’t know about every other developer, but for me, there’s a feeling of satisfaction when I see green ticks on all checks. It feels awesome!

When you integrate CI/CD into your developer workflow, you minimize bugs, prevent bad code from getting into production and, overall, deliver quality products.

5. Communicate with the Team Lead

None of the things we’ve discussed so far would work if you don’t communicate your needs and expectations right.

So to get developers to be involved in user stories, to get them to demo their features and do peer reviews, you communicate that with them. My recommendation is that you communicate with the lead developer. It’s easier for you since you have one point of contact, and it’s easier to get the developers to adopt these practices when they see the team lead doing the same. When developers see the tech lead getting more involved with quality procedures, they’re more likely to do the same as they naturally want to impress them.

Ultimately, getting developers on board to support testing efforts boils down to clear communication within the team.

If All Fails

If all of the above fails and no one is cooperating to improve quality standards, you might want to elevate your communication to management.

You could request a more hands-on testing team, but you need to support your request with numbers. For example, you could note the time needed to report bugs to developers and get them fixed and how adding another tester to the team would reduce the time to release. Presenting convincing evidence should be enough to get management on your side.

And if that fails too, just do what you can to create a product you’ll be proud of.