Assigning dedicated testers is a well-entrenched pattern that has driven the behavior of software developers, often in the direction of picking up bad habits. But for big companies such as Facebook and Yahoo, working without testers is business as usual.
Here are useful lessons I've learned over the past two years working without dedicated testers. Your team may need members focused on testing, but these lessons will still help you build better-quality systems.
Quality should be everyone's problem
When I say that software developers have picked up bad habits from having dedicated testers around, this is the chief among them: Somewhere along the way, developers stopped caring whether their code works. "I'll just code it, hand it over to the tester, and they'll tell me whether it works" is a common form of laziness among developers. With the safety net provided by dedicated testers pulled away, developers quickly feel the consequences of their sloth and are forced to take the quality of their work seriously.
I've learned that this actually increases developers' motivation and helps them enjoy their work more. The best testers I've worked with have been those who spent their time ensuring that everyone paid attention to quality. Whether you have dedicated testers or not, the best teams are those with strong ambassadors for quality.
When everyone cares about the work they're doing, they tend to have more fun doing it because it feels more meaningful.
See the big picture
Here's the problem with quality as a concept in software development: Many developers see quality as a measure of whether the system breaks or not. But that's a very narrow view. You can have a perfectly constructed system that's never unstable and never produces errors but doesn't achieve its goal.
Churning out code is easy enough, but it can be a massive waste of time when you don't have a deep understanding of what your system is meant to achieve. Taking a holistic view of what defines success for the product you're building shapes the way you code and helps you make trade-offs (e.g., between fixing technical debt and shipping new features) in a much more balanced way.
Talk to your customer
This is one of the key principles of agile and Extreme Programming, but somehow most teams have reinterpreted it to mean that each role talks to the customer about a small set of specific things. Testers talk to the product owner about quality, developers talk to her about implementation options, and business analysts talk to her about what to build next.
In my team, we have no testers (or business analysts), so we frequently talk through new requirements with the product owners. This has helped us build a really good understanding of what success looks like for our product.
In our team, any testing that gets done is performed by an engineer in concert with the product owner. I've seen firsthand how this leads to products that evolve significantly faster to meet market requirements. Business folk understand technical issues better, and engineers understand the real-world problems they are trying to solve.
Think equality
Somewhere along the way, developers got the impression that they're better or smarter than testers—and the industry as a whole shares this view. Developers consistently get paid more than testers. I've never come across a team lead with a pure testing background.
Being forced to take ownership of the quality of their system shows developers how tough quality assurance really can be. This will not only help you build an appreciation for the work your team members do, but can help you become a better developer as well.
Cut out waste
I've worked on many teams where testers spent weeks writing tests (or executing manual tests) that added no real value. That's not to say that testers inherently waste time, but it's very easy to ignore a bunch of misused time when it's "another team" or "that guy" whose time is being wasted.
When everyone's working together, it becomes apparent much faster that you're spending time on some activities that are not really helping you succeed.
If your team includes dedicated testers, make sure everyone starts working together more closely. I've found that teams whose members talk to one another more frequently (and who perform tasks together) consistently outperform those whose members don't, because they make fewer assumptions about one another and know which tasks really make a difference.
And if you don't have dedicated testers on your team, you're going need to take on the burden of testing. Don't be overwhelmed, though; you'll quickly notice which tasks are helping you produce better quality, and you can drop the rest.
Coders will code
One wonderful discovery has been to see how developers, who feel most comfortable when coding, will find creative ways of using code to ensure quality. Over the past two years I've seen developers build extremely valuable automated alerting to help find issues in production. We've found ourselves implementing simple automated security checks, and I've seen teams reduce their support workload by building self-healing mechanisms into their systems.
DevOps has had a major impact on our industry because we unleashed the power of automation on our infrastructure. At the dawn of agile, we made the same impact on testing by popularizing automated testing. Through automated support and monitoring, I've seen a new wave of quality improvement in our systems using automation.
The evolution of the tester
Take a team of developers who have learned to think like testers and have come up with creative ways of ensuring quality. Now add a "quality engineer" back into the mix—what would that job look like? Does it still have a purpose? I contend that it definitely does, but that the tester's role will evolve from looking after testing and toward being an ambassador for quality on the team.
Break down barriers
DevOps has broken down barriers and forced us to talk about how developers and operations can work together, in much the same way as the initial agile movement broke down barriers between business analysts and developers. For some reason, the conversation about the line between developers and testers seems to have been drawn at automated testing and hasn't gone much further.
In the past two years of working on teams without dedicated testers, I've seen how valuable it is for the whole team to be invested in quality. Whether your team needs dedicated testers or not, you'll be pleasantly surprised at how effective your team can become when all the team members start playing a tester role in their day-to-day work.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
