Me – “The team is responsible for Quality!”

Dev Mgr – “Yeah, I hear that, but what will help is to go one level deeper – let’s realistically identify what can and should be done by “developer” and “tester” resources.”

Lots of managers and their employees (and HR) struggle with this concept of team responsibility.

Clearly there will sometimes be tasks on stories that involve a level of coding skill that can only be done by someone with the title of Developer. There also will be some tasks that would be much more efficiently done by someone with years of testing experience. This doesn’t change the fact that when you commit to stories in a sprint, you’re expected to get those stories done. It doesn’t matter who is actually available to do the work.

Let me explain.

In the beginning of each sprint, the delivery team takes “Ready” stories from the backlog and works through them and creates tasks and estimates them. The team should know what their capacity is for that period of time. This means you should have an idea of how much time it will take to code and test and otherwise produce that work. All of it, not just the coding. If people are unavailable that sprint, clearly you should take on less work. If some of the test-related tasks don’t fit within the capacity of the testers you have on your team, you have a choice: either remove some work from the sprint and use the extra time for the programmers to do training and/or help with other projects outside of the team OR have other members of the team take on the remaining testing tasks.
If testing, or any other specialization on the team, is causing a bottleneck, the answer isn’t to shove more work into the bottle! What you do is work together to keep the flow going. If that means programmers doing more testing, fine. If that means testers doing more tasks that traditionally fall to programmers, fine. If that means analysts doing the same, or any other permutation, fine.

If something doesn’t get coded – that’s not a single programmer’s fault. The team should have known about it. If something doesn’t get tested, that’s not a tester’s fault! It’s the team’s fault for not making sure it got done. Blaming isn’t a productive method of getting things done. We succeed as a team and we fail as a team. And when we succeed, we reinforce and build upon the things we’re doing right. When we fail, we recognize the reasons for the failure and work to improve for the next sprint.

Let’s go back to the discussion – assume I said all that stuff above.

Dev Mgr – “Alright – so we come up with tasks together and then assign them to people – that will lock them down and we’ll be able to tell Project Management what resources we have free, or what resources we need to get the work done in this sprint.”

Me – /sigh

Note that making sure you have the capacity isn’t the same thing as assigning tasks to people. Tasks, optimally, should be pulled by people capable of the work only at the point in time that they can start working on them. It isn’t efficient to have a task assigned to someone who’s working on something else while another person could be doing that task. Now you may *know* simply because of the nature of the task that a particular individual has to do it. That’s fine. But be aware that’s risk you’re taking on. If nobody else is capable of that work, then you have to be very sure that particular individual has the capacity in that sprint to do that work. If you have a lot of work like that, it would be advisable to pair that person with someone to work on the tasks together. After a time, then you’ll have two people capable of doing that kind of work and you’ve lessened your risk!

Me – “So you’ve got it now, right? You’ve got a cross-functional team that self-organizes. You don’t need to assign tasks to anyone or wrangle with Project Management over time estimates and the availability of people.”

Dev Mgr – “Resources.”

Me – /sigh

Michael Bolton, along with James Bach created the Rapid Software Testing class from which this session was greatly condensed. I’ve never taken the course, but I’ve read a lot of Michael’s writings and one of my my past employee’s – Eric Jacobson – took the class, so I knew most of the material going in. I’m glad that there were few surprises – showed that maybe I understood what I’ve read! That being said, there were some choice points that I was able to synthesize with my experiences over the past eight years.

You don’t ever have “not enough time to test.”

Testers often complain that they never have enough time to get all the testing done. We should know that it is impossible to get all of the testing done. For example, try using as inputs all the possible values between 0 and 1. Now 1 and 2. And so on. But we certainly have enough time – we have all the time we’re given. And that’s enough to test as much as we can within that time, by definition.

It sounds a bit flip, and I guess it is. I tried that with my management a few years ago when they asked me how long it would take to test something. I responded that we’d test as much as we could given the time allotted. They were never really pleased about me answering in that way. I don’t blame them – it’s frustrating when other people don’t have an answer that you can fool yourself into thinking is real and then turn around and blame those people when that answer turns out wrong. (Read that again, I’m pretty sure it makes sense!)

Nowadays I don’t predict how long it will take to test a release or a feature, I predict how much work a team will complete (and that includes testing) in any given period of time based on past performance, in 2-4 week increments. But that’s another story.

“Bugs prevent you from finding bugs.”

Any tester should know this – the act of examining, reproducing, and writing bugs prevents you from more testing. If there are a lot of bugs, you can’t complete much testing at all! The takeaway from this class is that makes it very important that you test as rapidly as you can to counteract this effect. That’s true. And the approaches and techniques discussed in the class were invaluable – I recommend the class!

But testing faster isn’t the total solution. We also need to stop producing bugs in the first place. The best way I’ve found to do this is Acceptance Test Driven Development (or BDD, or Executable Specifications). Write your story/spec and include examples – examples that can be run to verify functionality and to use as regression. I should be quick to mention these aren’t acceptance tests, but more appropriately “rejection checks.” With these examples, we’re not defining the spec, but rather framing it. They don’t stand alone and are not independent of the story they describe. Take the “Petals on the Rose” dice game. Teams, not knowing the rules, come up with a number of passing tests, and often it leads to an isomorphic version of the specification, if not the actual ruleset. These tests would be a fine set of rejection checks for the

story but the story – the ruleset for the game – still has to be there.

“Testing is not about probing for functional correctness.”

That’s what the above Acceptance Tests are for; they make sure the system does what we, and the customer, expects. And unit testing is for making sure the code works. Testing is looking for problems we don’t expect. We don’t need to learn about expected functionality – we already know about that. Testing is about finding the problems that may lead to loss of customer value. Things we *don’t* expect. If we can anticipate these things and get them included as part of our stories and acceptance tests, fine. But sometimes we need to actually see/touch parts of the working system to discover the presence and possibility of such problems. That’s testing.

And that’s what I synthesized today.