I apologize in advance for yet another exploration of what testers do. More and more, I feel that Brent is right, and Test is a 4 Letter Word, but I feel we (whatever we want to call ourselves) can advance through discussion of our roles and responsibilities.
A few weeks ago, I was talking to a colleague about team responsibilities. As an exercise, he was trying to come up with a two word action that described what a discipline was responsible for – the action that you can count on. For development, we agreed quickly on ‘quality code’. There’s certainly more that a developer does, but given the two word action requirement, I can live with our conclusion.
The interesting conversation occurred when we discussed test. My initial answer was ‘provide information’ – is accurate – but not the right answer (for me, at least). I love and hate the notion of tester as information provider. We do generate data (and ideally actionable data) as a side effect of our testing, but that description makes it appear as if test has no power or responsibility for decision making – which I also find wrong. We are not gatekeepers of quality or safety nets, and we’re probably not going to block a release, but I think that testers need to do much more than passively provide information.
My colleague countered with a phrase completely on the opposite end. He proposed ‘sign off’ – that the responsibility of test was to ‘sign off’ on the product (and in order to sign off, we’d generate information, make decisions, etc.) As you can imagine, I didn’t like this description. I’m not against test weighing in on the sign off decision (or any other decision), but I dislike the idea of sign off being the primary responsibility. (Note – Catherine Powell has a nice article on the Decision Safety Net on her blog)
I don’t have a great answer yet for the responsibility of test. I like the idea of the role of test as an accelerant of quality – most of what I do has the end result of improving efficiency of and effectiveness of test and development work. ‘Accelerate Quality’ almost works for me, but I can’t say it’s the two word action that a tester should be responsible for. I’ll figure something out, but I’m open for ideas if you have them
I don’t have a time machine, but I think one positive note from this thought exercise is that I don’t think many (experienced) testers would list the primary action of a tester as ‘write tests’ or ‘find bugs’. At least not too many…
This was an interesting post, as it parallels a framework I’ve used to help describe what I believe the test team’s role is….
(for background info, I’m a Test Manager, and have been at Microsoft for 16+ years)
In the traditional model Microsoft follows for engineering, there are three key participants – Development, Program Management, and Testing.
In thinking through one word I’d use to summarize the role for each group, it would go something like this –
* Program Management – “VALUE”. They help determine the value for the feature, the project/product, etc. What value should the customer get from the work….
* Development – “QUALITY”. (Lots of people disagree with me on this by the way, as they assume Quality is for Testing.) The Developers have the single biggest impact to the products quality…. from the first line of “main(xxx…) onwards there can be great quality written in from the start or forced in through the bug find/fix/regress cycle. Many products/apps/services have been written and deployed at high quality without formal Test/QA teams because the coders/developers were responsible for quality.
* Testing – “RISK”. Testers help point out risks to QUALITY, to the VALUE, to the SCHEDULE. And because I believe test orgs are impacted most by poor processes, they are there to point out risks to the teams processes as well.
Testers use an aresenal of tools in their quest to root out Risks across Quality/Value/Schedule and Process (Q/V/S/P), and when engineering teams work to listen, learn and improve when these risks are pointed out, I believe you end up with better quality, with better end user value.
Removing risks across Q/V/S/P takes talent across many different dimensions, which is why it takes a balanced team of testers to help drive the issues.
Defining the role of Testing is hard – because what is done by the test teams varies so much. For me, I’m content knowing that we’re really Software Engineering Risk Managers.
Thanks for posting Daryl – I didnt know you read my blog and appreciate the insightful comment. I think I’m going to steal your ideas and use them in my next conversation with my colleague.
Be the conscience of the development organization
way more than two words :}
Shades of Brian Eno!
Daryl’s comment resonates with me. For a two-word action, I’d say “Surface risk” (where “surface” in this case is a verb). In order to make sure the right people are aware of the risk, testers must use their powers. If they do this well, they have a big impact on the decision making process.
That reasonates with me as well. I *really* like Daryl’s simplification of the roles. It reminded me of my very 1st post. Based on it, my 2 worder: “Mitigate Risk”
http://testastic.wordpress.com/2011/09/19/37/
I recently read somewhere on the blog-o-sphere someone refer to their team as a ‘Quality Assistance’ team; wish I remembered who it was so I could give them credit. At first I thought it was more than a bit cheesy, but it’s stuck with me, especially as I’m in the midst of implementing some agile testing methods that encourage all stake holders to use their varying skills and experience to test the application.
I believe that was Jon Bach’s team at Ebay – I like the title, but the action it describes is too vague. I know of a company where testers are known as “productivity engineers” – I may like that more.
When I was last in the testing organization here, I tried to get the name changed from Quality Assurance to Quality Evaluation. I think they took the QE acronym and ended up with Quality Engineering.
For a two word description, why not “assure quality”. After all, the business and the team should define what “quality” is required and means. The specifics of what is required in order to assure will very much depend on your organization’s people, culture, roles, and processes. Our test team works with internal and external stakeholders to write test plans/cases (acceptance criteria) that meet the goals of the release or feature. We then write automated tests that “assure” these acceptance criteria are met from one build to another. Thus we don’t build up a large technical debt. Not increasing technical debt, for us, is part of the quality definition.
I didn’t like “quality assurance” because our group didn’t have a voice into a Go/No Go decision. Therefore, we couldn’t assure anything other than what we did with regards to testing and writing up the bugs that we encountered.
What a challenge 🙂 – my suggestions would be:
Testers add “What If” – Management and customers “Go NoGo”,
Testers “Provide information” – similar to Brent’s “data scientist”
The two-word combo would be context related though “methinks
“Risk Resolvers”
I agree with Daryl’s comments that testers identify risks, not just with testing but much wider than that. Maybe from seeing code fail on a daily basis we’re pretty negative and see the worst – as a tester what could go wrong on a project and they’ll probably spring into life for a few hours.
But we’re not just about risk, running scripts and raising defects. From my experience we’re also the problem solvers. I couldn’t count the number of times I’ve been asked in my testing roles to try and resolve issues and problems, and not just during the test phase or around testing problems.
Testers can define what the end user wants as they understand their needs and the system limitations. They could probably code as quite a few have a technical brain. We have to project manage to fit all those tests into such a short period of time. We can support end users, write and train people, etc etc etc.
And after writing that, maybe I’m changing my mind. If we had 4 words it would be “Not just a tester”.
“Several roles”, “multiple hats”, “underpinning projects”, “quite valuable”, “life savers”,”not definable!”…
Hi,
This was a thought-provoking article. If I were to define the role of a test engineer in two words, I would say “Customer Focus”. The role of the tester is beyond just checking if the product meets to requirements specification. They need to focus on value to customers.
The testers should look at the big picture of how the customers use their product rather than focusing merely on the domain requirements.
Problem Hunter?
Problem Solver
I like the idea that Google has implemented in which test exists in a separete and horizontal organization called “Engineering Productivity”. (That is what I have read anyway)
I think however, as mentioned above, that risk is central to what a tester does.
“Productivity Support” and “Risk Illuminator” maybe 🙂
You (plural) cheerfully agreed that the purpose of the SW developer is “quality code”. Our real purpose is “business value” (vague enough to be meaningless), but we achieve this through “customer value”. Whether the code is good is neither here nor there in the short term, so long as the customer’s business (or life) benefits. However, poor code constrains a company’s ability to deliver ongoing customer value – hence your “quality code” – but the developers’ focus must be on sustained value. If I was allowed a third word, I would say “sustained customer value”, but I’ll settle for “sustained value”. Quality code is secondary: just one tool among many for delivering ongoing customer satisfaction.
So where does test fit? Just like development, not “business value” (too vague), but “sustained customer value”. Test contributes to this by flushing out risk, as described by many previous commenters, and in particular by flushing out the areas that SW development, project management, and even the customer didn’t know that they didn’t know. All engineering, be it electronic engineering, SW engineering, or test engineering, is an exercise in learning. Test engineering’s role is to learn about the customer’s real needs, and to “illuminate risk” where that is not what we are delivering. I particularly like Eric Ries’s principle, “validated learning”, for test engineering.
Full disclosure: I am a SW engineer, not a test engineer.