Testers Taking Too Long?

We had a question on the Michigan Agile Enthusist's list - the team was doing Scrum, four devs and a tester, and the testing was taking too long. In some cases, it would take the tester six hours to create the (manual) documentation but only three to run the (manual) tests.

Some people suggested it be a "whole team" and share responsibilities. Others suggested it be a "whole team" with no specialties at all. This is my answer:

Pre-Note: It is a whole team effort, and the devs can certainly help test.

However, if you would prefer to keep *some* amount of specialty, I have a few ideas. (Essentially, I am suggesting a little of both approaches)

//---Begin my ideas
Let's apply the theory of constraints to find how to increase the throughput of our tester.

We'll find the bottleneck - what is taking the most time in the process. Then we isolate it, elevate it, increase it's throughput, throw out what is not adding value, and go on to the next thing.

First off, the amount of time spent documenting is just bizarre. I suspect if you ask 'how much of this documentation adds value to you personally, the tester-guy?" it might be a lot less than the "the process" or "what I was told to do" implies. Cut it down.

Second, there is a good bit of evidence from cognitive psychology that high-manually-scripted, repetitive testing both covers less lines of code(1) and also is more prone to inattentive blindness(2, 3) than more exploratory testing, or testing with a more loosely-scripted charter.

So we can go faster by having less documentation and a more loosely-defined charter for testing.

Now let's find the next bottleneck. Commonly, it's one of two things:

(1) The Tester is spending a lot of time in meetings or supporting other projects, or some other activity that does not add value to the project. Eliminate it!

(2) The Tester is spending a lot of time trying to figure out what made a bug trip, documenting the defect explaining it to people, reporting on the status of the defect, re-testing, etc.

The easiest way to eliminate time spent on #2 is to have the devs deliver better quality code to QA in the first place.

I've worked in shops where the code was extremely good quality before it got to test, and test could move along at a good clip. I've worked in shops where that was not the case.

Guess what? In those shops, testers spent a lot of time on #2.

How to increase the quality before it gets to test? I would suggest TDD, and, if it's still buggy before it gets to test, you gotta ask "what's up with that?" and fix it.

My overall suggestions for test strategy -

(A) On the Dev Side, Test Driven Development (TDD)
(B) On the test side, some amount of high bang for the buck automation. Do automation as an investment where the ROI is clear.(4)
(C) PERHAPS, an as-small-as-possible manual test suite
(D) Warmed over with exploratory testing

Of course, I write, speak, and consult on these topics, but I am focusing my professional energies on Socialtext right now. On the east side of the state, for TDD and dev-facing tests, I would recommend Ron and Chet, possibly the Menlo guys. For exploratory and other forms of testing, some of the best testers on the planet are in Indianapolis, and Louise Tamres is local to the Southfield area.

Regards,


--matt heusser
xndev.blogspot.com
(1) - Ref -"James Bach Minefield Analogy"
(2) - Ref Cem Kaner, Black Box Software Testing Video Series
(3) - http://www.youtube.com/watch?v=mAnKvo-fPs0
(4) - See some of Brian Marick's recent work for some of the serious ROI issues companies are having with 100% acceptance-test-automation.