It you follow the agile-testing literature, sooner or later, you'll probably come across a discussion
something like this:
Joe Tester: "I need to test a foo object interacting with a bar container in a baz environment. How do I test it?"
Expert #1: "YOU can't be responsible for testing. The whole team needs to figure out how to test it."
Joe Tester: "Right, sure, but I just need some test ideas. What should I do?"
Expert #2: "NO. YOU don't do anything. The WHOLE TEAM has to test it."
Joe Tester: "but I just want to know ..."
Expert #1: "
SELF-ORGANIZING TEAM."
Expert #2: "
WHOLE TEAM."
etc.
What's going on here?
In an sense, the advice above is good, right, and true. By framing the problem as one that belongs entirely to the tester, Joe is putting himself in a position where the team can blame him for being late and, when the application falls down in production, everyone can put the blame sorely on his shoulders.
More than that, by asking for an answer, Joe is also asking for someone to
rescue him. This places the experts in the position of solving the problem; It is asking the other person to do the hard work. (Meanwhile, the "expert" knows very little about the application, besides it's most superficial description).
We might, for example, know it's a web-based shopping-cart app written in Java -- if we are lucky enough to get the type of application that people generally understand.
Sometimes it's a radiation-cloud simulator written in Haskell running on a massively parallel grid. Most of the time, it's somewhere in the middle.
So I can see how the experts are tempted to reply "whole team." I just take a few small issues with it.
The Problems
Yes, we don't want to put ourselves in the position of savior. Sure, I get that. But can't we at least be helpful? I mean, wouldn't it be nice if someone popped up and suggested that when they tested a shopping cart, the big problems they found were A, B, C, ... etc? Or to mention a link to
Quick Attacks, or maybe one of the classic
Shopping Cart Test Taxonomies? Where's the solid, concrete advice? Is it really that hard to say "that sounds a little bit like what we did on (application X), where we ..."
I think there's middle ground between rescuing and yelling "SELF-ORGANIZING TEAM" in all capitals.
Which brings up another problem. By saying "SELF-ORGANIZING TEAM", the expert is implying that testing the application isn't that hard; that there are no specific skills in testing, and a skilled, multi-disciplinary team of smart people should be able to figure out it.
And we keep in being surprised when systems have
bugs, outages, and downtime.
Shocking!
Predictable!
Shockingly Predictable?
I'm not ready to jump on the "no advice but self-organize" bandwagon, but I really, really do see some value in collaboration, and I would like to talk about it.
Collaboration Exampled. Or, um, Examined?
Last week, at a client site, we were testing a story something like this.
For simplicities sake, we'll say it's a office furniture company, with an update to an EDI file that would change an order -- say the language that we are to send the assembly parts in."
"Given an update file comes in through the FTP Process,
If the assembly language is different,
And the output should be sent by physical mail,
Then create an entry to change the physical mail language."
Simple enough, eh?
It's a decent example of Behavior-Driven Development, much like the one
James Bach was talking about last week. In general, I've never been huge fan of the given/when/then syntax, but it's a pretty good example, and it helped drive development.
Then I had to test it.
Here are some of the kinds of questions I wanted to ask the software, to determine if it was fit for purpose:
What about if the file comes through the web?
What if it's a phone order?
What if the output is web portal?
What if the output is email?
What if the update comes after the results have been sent?
What if the update file updates street address, or something else?
...
and on, and on.
In the end, I had twenty-three test ideas, many of which could break down into multiple tests.
So I wrote them up, and send them off to the team to consider.
One of my fellow testers looked at my examples and came up with four new test ideas; two of them failed.
One of the developers took those ideas and automated for his project, which was a different line of business application -- and he found a half-dozen failures.
Let's play that again
So I wrote them up, and send them off to the team to consider.
One of my fellow testers looked at my examples and came up with four new test ideas; two of them failed.
One of the developers took those ideas and automated for his project,
which was a different line of business application -- and he found a
half-dozen failures.
I've worked on teams where none of these things happen.
In teams like that, I would have "passed" the story, the developer would have "passed" his off to QA, the tester likely wouldn't have known about the new test ideas, and the stories would have gone to production with bugs in place.
That is the thing.
When people work together, they have test ideas that play off each other. The testing you get is better testing. The developers use those ideas for feedback, to provide better quality software earlier in the process.
Everybody wins.
No, Virginia, if you ask me for help, I'm not going to just yell "
Whole Team" at you and go away.
But I likely will mention Whole Team sooner or later, because I believe in it, because I've seen it work.
My goal today was to explain why, and what I meant by the term.
More to come ... if you'd like to hear it.