I’m heading off for a long vacation today, so this is likely my last post of the year. It’s been a crazy year, and I thought I’d end it with something that a lot of my recent posts have been leading to (e.g. this post on tearing down the walls).
Some of you will hate this. I’m not sure if it’s because you’re afraid of your job, or because it’s so far out of your world that it doesn’t make sense. For you, let me tell you about the audience who will read this and say, “ho-hum – tell me something I don’t already know”.
Testing as we know it, is changing – and the changes are big (for some folks, at least). Testing as an activity will always exist. But I see test as a role going away – and it can’t disappear fast enough.
Test Is Dead (or is it)?
A few years ago, my friend James Whittaker angered testers world-wide with his talks on Test is Dead. James premise was that for a whole lot of software out there, it’s more cost-efficient to get data and issues from customers actually using the product than from a test team pounding on the product. Unfortunately, way too many testers failed to see the context and big picture of the main point and screamed loud and wide about how quality would suffer without testing.
But James was far more correct than people give him credit for.
Hiring testers to pound quality into a product after it’s been developed is a waste of money. The more I think about it, the more I realize that Test Teams are an artifact of older, predictive (staged / waterfall-ish) software development models. The notion that one team (or part of a team) is responsible for writing code, and another part of the team is responsible for making sure it works as expected seems wasteful to me (even after spending the majority of my career doing just this).
Test teams are dying. You may disagree, but I encourage you to take a critical look at whether you believe a non-integrated test team is the most cost efficient way to evaluate a product. Yes, I know there are companies formed entirely around evaluating already-developed products – but I believe that the days of testing-quality-in (the equivalent of the people who clean up after animals in a parade) are ending (or ending, at least, for the quality software products of the future).
Testing is NOT Dead
Before you skewer me with your protests (and some of you will, despite my best efforts to explain), let me reiterate. Testing is not going away. The testing activity will thrive and improve and evolve. It’s just time to think about getting rid of the old ways of thinking about who does the testing and where it happens.
Plain and simple, we (the software industry) have been wasting money for years letting testers play safety-net for lazy developers. It’s much more cost effective and efficient for developers to write unit tests and some or all functional level tests – and maybe more. Other developers on the team (many of them former testers) should focus entirely on “ilities” such as reliability, performance, security, etc. as well as evaluating end-to-end scenarios (epics) spanning multiple features. (related paper from me here – it’s a few years old, but I think it foreshadowed this change nicely).
There are other activities – like data collection and analysis (feel free to insert the buzzword “Data Science” here if you wish) and other tasks we need software teams to do – but we don’t need separate teams for those tasks. We need people to do those things, but those specialists can work anywhere. Why is it that I’ve seen just as many performance or reliability teams reporting to development managers as I have seen reporting to test managers? Some of my colleagues talk about the need for testers to “transition” to data science or other roles. In reality, it may be a transition, or it may be different people. It doesn’t matter (what remains true, is that we will have an increasing need for people who can analyze data). I think one of the only reasons we don’t talk about having a specific “Data Science Team” is that we already have enough disciplines in software engineering, so we default to shoving them into the best suited discipline for analysis roles.
Whole Team Approach?
We need integrated teams – not separate teams. We need teams of generalizing specialists to make great software. The disciplines and teams get in the way of efficient creation of quality software. Some say that the programmer/test relationship provides checks and balances – but I see no reason why those discussions and positive conflicts can’t happen on a team where everyone works tightly together.
I’ve seen a few mentions of the “whole team approach” to software creation, but that term (to me) doesn’t adequately describe how great teams (can) work. In a team full of generalists, everybody can do everything, but nobody does anything particularly well. That doesn’t work if you’re trying to make quality software. In a team of generalizing specialists, everyone does something (or a few things) really well – but the team members are adaptable when necessary. Teams need specialists in design, user interface, performance, reliability, deployment, internal infrastructure, data analysis, and scads of other areas. Teams also need people who specialize in testing – specialties that include end-to-end evaluation and risk analysis, as well as coaching developers writing unit and functional tests.
But the separate team for test is dead. It’s a waste, and we need to stop thinking about putting our specialists on separate teams.
Testing is a Specialty
I’m looking at a twitter feed full of comments from testers worrying about what this means to their careers. A good tester, as part of a team of generalizing specialists is worth every bit of salary and value as any other specialist on the team. Test “specialists” who can’t provide this level of value, however, probably should worry about their career. Test may be dead, but good testing will live and be valued for a long, long time. But we need to stop thinking that we need test teams to pound quality into a product, and figure out how to fully integrate great test minds into great software teams.
There’s a subtlety here that goes beyond semantics. Jobs (most of them, at least) aren’t at stake here. The great testers of today will be great test specialists on software teams tomorrow. It doesn’t’ matter if they code or not, as long as they provide value and contribute. I’ll repeat that, because I can almost guarantee a comment about how stupid I am for proposing a world where testers need to code. Test specialists won’t (necessarily) need to code. Many of the “test automators” today will write features, as well as functional tests (using their mad automation skillz) – and they’ll coach the programmers on how to do the same – leveraging the specialties of each other.
A glance through any testing community will show dozens of definitions of what testing is, and what testers do. It’s too much. It doesn’t matter. We need to stop building organizations where one team writes code and another team tests it. Testing needs to happen all of the time, and at the same time as development. For this to happen, we need to get testers out of their test teams, and fully integrated into software teams.
A Better Future
Today, testing articles, posts, and tweets are filled with whining (or mere complaints) about the sorry plight of testing, the lack of testing respect, the difficult of measuring testing, and other worries of the testing community I’ve been hearing for the past 20 years.
But a new world where testing is merely a specialty within the software team eliminates these worries. There’s no more us versus them. We have a team, and we each supply different specialties that contribute to the team’s success.
Preemptive post script
I’m leaving (on a jet plane), and I half-rushed this post out. I half (or full) rush most of my posts, but this one is important. I’ll try to respond to comments (and hate mail) when I land, but I expect I’ll have follow ups and re-writes coming. I’m positive there will be much speculation on what I didn’t mention, so I’ll deal with that soon as well.
More will come.