I’m not quite sure why, but once again I’m writing about test roles. I don’t know of another job in the world where discussions like these are common. On the other hand, I don’t know of a job in the world where people are so passionate about what they do (and don’t do) as part of their role. I’ll chalk it up to the continued growth of the role and see if I can convince myself to finish this and post it before I stop myself.
Here’s the short version for those already bored with the topic. Roles that testers play on teams vary. They vary a lot. You can’t compare them. That’s ok, and (IMO) part of the growth of the role. I find it disturbing and detrimental when testers not only assume that their version of testing is “the way”, or that some roles (or people in those roles) do not qualify as testing.
And now for the longer version… The recent test is dead meme (which interestingly, won’t die) brought to light (in semi-dramatic fashion) that in some situations, some traditional “test” roles don’t exist anymore. It wasn’t originally phrased that way, but if you looked under the covers, that’s all that was there. I’m still surprised that so many people got stuck on the three-word catch phrase and couldn’t see the value in the statement. But if they did, I suppose I may not be spitting out this blog post.
Last year, I had a surprisingly popular post about My Job as a Tester. I’ve changed roles since then, and I’ve been thinking about an update, but for a variety of reasons, I’m just not ready yet. The biggest reason is that although I’ve been on the team for five months now, my role is still evolving. Once it settles into a bit of a groove (and as other factors resolve), I’m sure I’ll post a recap.
Recently, I’ve been working a lot on pieces of implementation of test infrastructure for my team. Although I’m still heavily involved in testing strategy and test “stuff”, the goal of most of my current work is to enable good testing. Since I sometimes describe my role as an improver of tests, testers, and testing, I’m still on target with my own vision.
While reflecting recently on what I’ve been doing vs. what [anyone else] does as a tester (and catching up on reading, I pondered the fact that what I’m doing now isn’t really testing as “traditionally” defined (whatever that means). However, what I do is making testing better – but am I more of a “productivity engineer” than a tester? Brent Jensen has this description:
A tester’s job is to accelerate the achievement of shippable quality
By that definition, I suppose I’m right on the money. But I know there are people (who will likely tell me I’m damaging the craft, or that I’m mean to them) who don’t call what I do testing – I’m cool with that. I still like my job and my business card still says “Tester”.
By far, my favorite favorite thing to do as a tester is design tests. I love the challenge of crafting a suite of tests that enable team members to make well-informed decisions about product quality (at least that’s the plan). Testers in this role may be part of a whole-team approach where they have a test/quality focus, but have shared team goals. Or, there may still be “devs” and “testers”, but the wall between the two is minimal, and everyone works together (most of the time, at least) to make sure the product achieves both shipping and quality goals. Brent’s definition works pretty well for this role too.
Design overlaps execution. The Think-Design-Execute loop is tight in good testing – this is true whether it’s entirely, partially, or non-automated (or inversely, entirely, partially, or non-manual).
Which leads me to two test roles that, while they definitely exist, I could say they’re dead to me. But they’re not really dead – I know that. What they are is more…irrelevant. Given what I do, where I do it, and a smattering of other context indicators, two test roles are off of my radar.
The first is the test-automation only role. I think the role of taking manual test scripts written by one person and then automating those steps is a bad practice. I know some people like to do this stuff, but I think it’s a waste of time. What you end up with are tests that either should have been automated in the first place, or tests that should not be automated. Fortunately, while I acknowledge that these roles exist, I’m happy to work in a world where these roles do not exist.
For lack of a better term, I’ll call the final role “waterfall-tester” – even though I know this role exists at some (fr)agile shops as well. This is the when-I’m-done-writing-it-you-can-test-it role. Test outsourcing is the most common manifestation of this role, but it exists anywhere where testers only provide value at the end of the cycle. I know great fantastic testers who love this role, and I’ve been in this role myself in the distant past. Today, however, I don’t want to think about testing something where my contribution hasn’t been part of the end-result from the earliest stages. Again, while I fully acknowledge that testers live in this role, I’m happy that it isn’t part of my testing world.
In the end, I’m not exactly sure what this means to anyone but me. As I’ve mentioned (and tweeted) before:
Which really says, that in nearly a thousand words, I’ve (once again) told you nothing new.
Thanks for what you said about the “testing is dead” think,, I’m weary of the presenters who use that just to get attention.
Jeff Patton made a good point yesterday at his Mile High Agile keynote. Sports teams don’t have “roles”, they have “positions”. And a person in a particular position will not stop and say “That isn’t my job” if, for example, he is a place kicker but is the last person between the opposing team’s ball carrier and the goal line. I think “position” applies better to software teams than “role”.
Thanks for sharing that. In sports, there may even be more than one way to play a particular position depending on the players skill, so that metaphor works well in my head.
Good post. I agree that hopefully these two roles will be a thing of the past.
It would be interesting to try to define and map all the possible (within reasonable limits) different tester roles. It would require a lot of work, and probably not be worth it, but it would be interesting.
I like the sports team “positions” analogy. It’s quite congruent with my Eurostar ’06 (I think?) Keynote & several sports analogies I’ve made since.
Here’s the thing that I’m strongly pondering these days. Why is it that Software is one of few (i.e. I can’t think of another) industry where “testing” is done by “testers”. Everywhere else, there are only “developers/engineers” during R&D, Beta/User Experience Testers during “productization” and QA *if* there is manufacturing/production.
Are we really *that* different??
Great question Scott – personally, we’re not as different as we like to think we are. Try replacing the word “tester” in the next rant you hear with “person’, and chances are it will still be valid.
If you compare the testing budget for a project in the software industry with the testing budget for a project in other industries and see that testing is a much larget part of the project budget in the software industry than other industries then that could be one justification for having a specific tester role, I guess.
I think that having a specific tester role is not the important part, but to acknowledge the specific skillset required to do good testing. If this skillset is something an engineer, developer or tester has, I think is less important.
Defining that skillset I think is very interesting. Once you have that skillset mapped out, you could use that information to look at what parts of the skillset is interesting depending on specific assignments, so that you get the right person for the right job.
I could however understand someone arguing the importance of the tester role because of the need to highlight the skillset needed to do good testing so that managers don’t hire people with no relevant experience for testing assignments, but I do not share this view.
/Johan
Now that he’s back at Microsoft, you should be having this discussion with your co-worker, James Whittaker — the lightning rod for many with the way he presents the “Testing is Dead” topic.
His talk here (http://www.ustream.tv/recorded/18274418) could lead pointy-haired bosses to believe that testers agree with comments that disparage their own role, like: “It doesn’t matter who does the testing as long as it gets done” or “When I ask someone at Google what they do and they reply ‘I’m a tester’, this is problem employee” or “The minute you start associating yourself more with your role than with the product, your company should fire you immediately.”
I am not the only one who thinks that statements like these about the role of testers actually damages testers in serving the roles you talk about above.
I hope it drives more people to do more ‘counterpoint’ keynotes and blogs (like you’ve just written) about the role of testers.
If that winds up keeping the “Testing is Dead” topic alive enough to kill it properly — with cogent counter-argument instead of just wishing it would go away — then I’ve served my role as an advocate for the role of testers.
Thanks for replying Jon. JW is a good friend of mine, so we’ve talked about this before (although we usually find something more interesting to talk about). In fact, probably because I’ve talked to James as much as I have, I was always able to consume the message of this talk in an abstract form. I’ve always taken the message as a Testing in Production message – but a talk on TiP doesn’t have the bravado or buzz of a talk on the Death of Testing. If you’re shipping a web service, you want to take advantage of the value you get from frequent iterations. Between staged roll-outs and testing monitors (not to mention craftsmanship and due diligence from developers), it’s quite feasible to ship a successful web service without the traditional test role.
That hardly means test is dead, but is some test dead? In this situation? One could even say that someone who specialized in writing live site monitoring is in a test role – in production, your monitors are often your tests. And I’m sure you know that this certainly isn’t the first time someone has made controversial statements at a test conference on in a blog in order to create a bit of a buzz. Frankly, I’m happy anyone at a test conference talked about something other than the exact same topics that have been on conference agendas for the last decade. I was excited to see the topic of your recent keynote at STPCon, and hope a spirit of debate and new ideas will catch on in future conferences.
But there’s probably even more to this. One technique I use when someone says something I think is wrong, stupid, or even damaging, is to do a bit of root cause analysis on the statement – in other words, I ask myself why they made the statement. In this case, I knew the background (or at least had an educated guess), but the answers are out there now. In the closing pages of the recently released google testing book, James talks about the change in roles at Google – how test roles are now development roles. In his recent blog post on why he left google, he talks about the changes Larry made. I’ve never asked James this directly, but it’s not difficult to hypothesize that the test role was dying at google, and that as a leader in the company, James had two choices: fight back, or jump on the bandwagon. I would suspect that the publicity he got over test is dead was a good move for him. Honestly, if I were Larry, I’d probably do the same thing (at least about what to do with testers). For a pure services company with the monitoring and rollback systems they have in place, it makes complete sense to me. (Note – I don’t know for sure, but I would suspect that the android team still has something resembling testers, but if they don’t, that would explain a lot too).
I’ll probably always be a tester – but what I do will change. To me, saying test is dead doesn’t damage the craft – instead I hope that it inspires critical thinking in those who can see beyond the words and into the meaning. Perhaps those that can’t get beyond that weren’t good testers in the first place…I don’t know. What I do know is that test roles are evolving.
As I ponder how test is changing – and how it needs to continue to evolve, I often wonder if James left off the punchline.
Test Is Dead. Long Live Test.