Monday, September 8, 2008

Downstream testing...

No, no, no.... and no.

The word "downstream" and "test" should not be near each other in a sentence.

Kevin Rutherford had an interesting post about how better testers allowed the developers to become lazy. As humorous as this was (and I can definitely see it happening), I started to think about what he was saying. Especially as he asked: "What did you do to harness the skills of your great testers so that they constructively support your great coders?"

I got to thinking about the flaw and whether or not it was obvious to him. Even if it was obvious to him, maybe it wasn't to readers of his post. So I had to comment.

Tests need to be run before the story is accepted, reviewed, and closed. If you work in an environment where a testing team runs manual scripts to do testing, then this is included. If this means that your story isn't closed for a while, then so be it. If this is painful to you, then work as a team to shorten that time frame and remove the waterfall.

Paul Richie had some similar thoughts (thanks for the reference Paul).

1 comment:

  1. Follow-up note: Kevin R. has since clarified that he was against the downstream concept and commenting on the counter-intuitive result of how better testing approaches have led to lower quality from development in three different experiences he has had.