1) Another day, another story that goes like this. Organization is training developers in testing. Sounds like a pretty good idea at first, although most developers are already pretty good at the kind of testing that developers need to do, especially when they collaborate.
2) Turns out that developers are being trained in higher-level integration and system testing—the kind of deep testing that requires more domain knowledge and a substantial shift from the developer mindset. Hmm. Why are they getting this training? Because the testers were canned.
3) And why were the testers canned? Because they had been told "We have to do more automated testing! We have to automate all the testing!" Which means that the testers were being asked to do programming. And, though this may be a surprise, the testers weren't great at that.
4) Part of the problem was that, at best, the testers got shallow training in programming. Another part is that nobody really knew (or knows) what "automate everything" means. And another part is that programming turns out to be time-consuming and tricky. Who knew?!
5) The result was a bunch of automated checking that was shallow, brittle, didn't find many bugs, and that didn't keep pace with development. So... get rid of the testers. Get the programmers to do the testing, since the programmers are already good at programming.
6) The story is that testing was slowing down development. Let's expand that out: evaluating the product by learning about it through exploration and experimentation was slowing down development. Now let's rephrase: learning about what we're building was slowing down development.
7) One more interpretation: writing programs to learn about the programs we're writing was slowing down development. It seems to me that while writing programs might be helpful for some learning purposes, it's a highly imperfect and incomplete way to learn about a product
8) The testers probably didn't have the skills to compose, edit, narrate, and justify the story of their work. It's also probable that, even to the testers, testing was all about developing and following scripted procedures and checking output, rather than investigating risk.
9) When testing is reduced to demonstrating, by rote, that the product CAN work, it's easy to believe that testing is simply a programming task. Create programs to do really fast typing and really fast comparison of desired and actual results. Simple! No testers required!
10) Mind you, all a programmer does is type instructions from business people into a computer, right? So, a modest proposal: teach the business people to program, and then we won't need programmers OR testers. Simple! No technologists required! Yet managers never suggest this.
11) Why not? Perhaps it's because managers are aware the programming is HARD. And those same managers aren't aware that investigating deeply hidden, subtle, rare, emergent problems in complex systems is also hard. Testers must take responsibility for making that clear.
12) That requires two things: doing excellent testing, and describing excellent testing. That won't happen when we reduce testing to test cases; when we talk of "manual" testing and "automated" testing; when we forget that we're here to find problems that matter to people.
