Someone wrote this question on the
Agile-Testing list yesterday:
Hey All,
OK, so for those of you that have successfully worked as agile testers, or been on a team that made the shift, I need your help.
I've got a team with an agile tester; he's great. Very smart, very driven, good sense of humor. We hired him this summer into a team that's been around for awhile with a couple mature production apps.
The main issue is, we're in scrummerfall; testing is still last, and it's not uncommon for several programmers to deploy to QA within a day or two and thus the team's work bottlenecks. This also has a tendency to happen near the end of a sprint, or when a release is being prepared.
How do I "test-infect" the thinking of the programmers, and how do I "develop-infect" the tester? I'd like to even more away from such role labels as in my mind they tend to reinforce this arbitrary break down.
I've been reading up on this, though while it's clear this is a cultural shift, finding actionable approaches has been elusive.
Some in progress items that might be of interest:
- the team as a whole has asked for some leadership here from me, and tasked me with bringing ideas to them in the next couple weeks
- the tester does not yet have a functioning local environment to really dig into the automated tests, or be able to write them. Remedying this has been pushed out many, many times and is now coming back into a high-priority scope.
- we are, among other things, attempting to practice BDD, though again while the concept is clear, actual implementation is more elusive
- we have a new product owner as well and we've been spending more time on user stories up front to have them be a more concise slice of work. We have not yet gotten the tester involved in these early conversations, although we have identified it as valuable and something to do.
I would very much appreciate any thoughts and experiences on this, and thanks in advance for taking the time!!!
I thought this was a reasonably-framed question. The author gave the specifics of the situation, the who, what, where, why, how -- and why -- along with some of his attempts at solution, to blend roles, do BDD, etc. I thought I had enough information for a real reply.
This is what I wrote:
Hello Kevin -
I think we agree on substance, there are just a few rhetorical things in your message that give me a little pause.
Or, perhaps, alternatively, I might be looking to solve the same problems, but in a different way.
Granted, I only know what you wrote. I think you did a good job describing the system forces, and I am willing to problem solve here, even without a perfect picture of the situation. That said ...
If the team feels like scrummerfall, I would consider two things - (1) Reducing work in progress inventory to move toward one-piece flow, and (2) Requiring QA be involved in defining 'done' for the story before the testers start writing code. As a manager, I might consider that the developers /demonstrate/ done, preferably in an automated way -- but, realistically, I might defer that a bit,
maybe give them some build automation stories.
If you make those small system changes, it might encourage the proper behavior, where 'encouraging' pairing of dev and qa and blurring of roles might struggle.
But that's just me talkin'. Do you have any questions?
regards,
--heusser
Giving advice over the internet in bite-sized nuggets is really hard.
My question for this audience: What do you think of my advice, and why?
(Also, knowing me, you probably noticed other things I did, like entirely ignoring the discussion of BDD. What/why do you think of that? :-)
More to come.