I often talk about agile development and agile engineering practices. I talk about Test Driven Design and ponder the possibility of writing bug free programs. I make a case that for the most part, bugs can be kept out of customer’s hands by a good agile development team.
But What About The Role Of Testers?
After saying all this, the questions start:
“Are you saying that testers are going to be out of a job?”,
"With all these unit tests being written by developers, what will be left for testers
to do?”
or (more insidiously) “So I’ll be able to fire all my testers?”
My short answer is, “No, lots of stuff, and No.”
My not quite as short answer is, “In an agile world, the roles that testers play will change, and it will require significant mindset changes from everyone in the development cycle to fully benefit from these role changes”
But first a little background…
When I started out as a developer, I literally worked in a guy’s kitchen writing handicapping software for football and basketball. I was young, enthusiastic and my skills were barely enough to keep me in front of his change requests.
When he would ask for changes, I would make those changes and bugs would start to appear in other places in the code. In my world, bug reports came with sad disappointment. It was as if my boss knew that I was a better coder, than my code made me appear to be. It became very important for me to find bugs before he did, and so I started learning how to do testing. As I got better at checking my code, fewer bugs escaped me and I got fewer disappointed looks.
While I never got to the point where bugs did not (occasionally) slip by both him and me, they got to be a rare occurrence. We eventually went on to win awards in Las Vegas for that product.
A few years later…
I was working in a different shop and went in to see our lead tester about a requirements issue. (Ted was both our lead tester, and a functional product owner.)
“Hey Ted” I said as I walked in, “I’ve got a question for you.”
“You are just the person I wanted to see,” he said, “I found a bug in your module”
“Cool, show me.”
He then proceeded to use my module to crash the application.
I smiled and said, “Awesome. Thanks, I’ll go fix that.”
And then Ted said something to me that I still cherish, 16 years later, “And that’s why we like finding your bugs, first, it’s rare when one bad gets by you, and second, you are always so happy to see them.”
I said, “I’m just glad you found it and not a customer.”
His response was, “Not everyone looks at it the way you. One of our guys feels like
we are picking on him personally when we find one of his bugs.”
I didn’t know what to say to that.
At that point I was still young and believed that if you were a good enough developer, testers were a luxury . A luxury to be cherished and enjoyed, but still a luxury.
What a load of conceit.
The Heart of a Developer
The problem was that I had to become a decent tester. What I didn’t know then was that I wasn’t a great tester and that I would probably never be a great tester.
This mindset was summed up for me a few years later when I had the privilege of working with some great testers. Someone at that shop put it this way.
“A great tester, has the heart of a developer…”
The person who told me this paused and let me think about the implications of that statement. But he didn’t wait too long before delivering the punch line
“…in a jar on their desk.”
In a grossly oversimplified light: developers create, testers destroy.
A Partnership Made Where?
You would think that this create and destroy dichotomy would prevent developers and testers from working together in a partnership. And if testing and development are kept from each other they don’t become partners, they become competitors. Not always, but often enough for it to be an anti-pattern that emerges in a shop that is heavily silo’ed.
Factors that cause friction in a silo’ed situation
- Silos that have different managers and non-aligned incentives
- Pay testers based on # of bugs found
- Pay developers based on # of features released to market
- An attitude that developers create value and testers hinder productivity
- Managers battling for turf
- Unclear company mission
- A gotcha mentality (when a bug is found by a customer, whoever can shift the blame to the other department fastest, wins)
- Quality gates and processes, put in place because of past company quality failures
- Testers acting as the last bastion of quality when they believe developers are willing to use the end-customers as a testing department.
This is a natural pattern that will need to change. Testers have gotten used to being the last bastion of quality and will sometimes fight to the death that the product can't be released tomorrow, until the spelling mistake on a button is fixed, while at the same time insisting that they (the testing department) must have 2 weeks to test and certify the product after the change of spelling has been implemented.
As A Tester, What Do I Get Out Of Working In An Agile Shop?
There are no promises, but here are some possibilities.
- New builds that install properly every time
- Having your test plan roughed out, before the developers start writing code.
- People saying nice things about the testing department, like, “Our testers found a design bug that could have cost us $50,000 if we had had to fix out in the field”
- Never having to do another repetitive, brain dead testing run
- Being able to focus on the fun stuff: stress testing, load testing, (or even better) having the developers delighted when you bring back a flock of bugs from an exploratory destructive testing binge.
- Being asked to accompany the account manager on a trip to the client site in order to assist in requirements gathering.
Of course, if you read that list and start thinking the following…
- But what if I like repetitive brain dead testing runs?
- But what if I don’t enjoy what you call the fun stuff?
- But what if I don’t want to go to client site?
Well, I said that going agile was going to require changes to everyone’s mindsets, that includes testing.
Some Mindset Changes That Are Helpful
Testers need be able to do more that test, they need to be able to teach how they do what they do.
- QA people who just do process also need to be able to test.
- Developers need to understand that QA only uncovers the bugs created by developers
- Other employees have to stop assuming that the test department is just a developer training ground.
- Other employees have to stop assuming that the test department is filled with failed developers.
A quick note for those of you who think this list is silly: I invite you to buy a cup of coffee for a tester with more than 5 years of testing experience and ask them to tell you stories related to things on this list. There’s a prize for the best story left in the comments below.
A Brave New World, and its Consequences
Moving a team into an agile style of development requires a change in mindset and work practices from all involved, but QA folks should find an increased importance and a change in the perceived attitude to their role from their colleagues.
- Developers who don’t already, will need to learn to ask themselves the question, “how is someone going to break my code?” (Testers can teach developers to think a little bit more like a user.)
- Testers can get involved in the design process and have their test plans roughed out before development begins. This can lead to better designs because in many waterfall shops, the first time QA sees the program is after the project has entered the “test-phase.” At this point it is too late to do anything about possible design flaws.
- Testers will also have to learn to be partners in the development process. I have seen testers who didn't want to help developers. The reason was they needed to find bugs to justify their position, and how can they do that if the developers kill all the bugs before it gets to them?
- QA managers will sometimes fight an agile adoption because they believe that it will threaten their job. This can be a valid fear in certain organizations.
The bottom line is that testing in the agile world will be different but testers will still be needed. Testers will find themselves with more recognition and more responsibility.
And my short answer is still, “No, lots of stuff, and No”
Comments