Continuing the software craftsmanship week, today I will take a closer look on the ethics of being a software craftsman. Nearly two years ago, Robert Martin held a keynote talk on Craftsmanship and Ethics. Let’s revisit some points he mentions from the tester perspective.
QA should find nothing.
When I heard this for the first time, I was amazed. This is a such a strong claim from the perspective of a tester. I won’t argue about what testing is, finding defects, or validating the product. But from a testers perspective he might basically be saying, “QA’s work should be meaningless”. But I don’t think that is what Uncle Bob was trying to say. Instead his focus relies on the the programmer. The programmer should write the program in such a well manner, that QA is unlikely to find any defect. Of course, this does not preserve human bias from taking in. In fact, as a tester I like this attitude, since it gives me the challenge to dig deeper than just running over the first NullPointerException in the code. The only meaningful response to this is, “… and we’ll be proud of it, but still look harder for problems”. Every defect we can find before the customer is able to find it, is time well spent on testing. This holds for the act of programming as well as the act of testing.
100% code coverage
Though code coverage may be meaningless in some circumstances, using full coverage as a goal for the implementation. This helps testers a lot, as they can rely upon some good code. Subtle bugs in the most basic functions are not existent. Thereby testers can focus on the critical problems in the underlying code. Since less time is wasted with trivial problems that the programmer could have found before giving the code to the tester, work gets optimized.
Manual Test Scripts are Immoral
Uncle Bob focuses here on vague, but thorough descriptions of tasks that could possibly be automated. For testers, having the need to start up a full system with manual steps, this may be the worst distractor, that I have ever noticed. Instead, a single command should be able to build the system, thoroughly, reliably, in any environment. Testers and programmers working together on this may be able to get this finished. “Copy this file there” and “adapt that path there” descriptions are long, error-prone, since they are never even close to complete, and take just too much precious time to be left in this suboptimal state. Therefore, automate everything that can be automated.
Good job, Markus, I’m liking this series, and I like the points that you mention.
The “QA should find nothing” mantra is one I used to hear with disdain, and boy did we get into some tussles whenever I came back with an issue (I won’t name names, but suffice it to say it has been an issue at various points in my career). I like the “… and we’ll be proud of it, but still look harder for problems” reply. It seems many testers would benefit from organizations that took this attitude (And had their developers embrace the same ethic, too).
–MKL
That is exactly my take at it. As testers we could be pissed off when hearing about such a mantra, but we should be thankful. This is exactly what Elisabeth Hendrickson talks about, when she mentions that test conference where Kent Beck told in the early days of XP, that with XP testers are no longer needed. She took the challenge from Kent, and showed him that testers can contribute meaningfully to the mantras of XP. Others showed the same, and this is exactly the take we should use on it. It’s great that we get wonderful code that is working, but there might be portions which are not subtle to everyone, so better have a tester take a look at it. If there is no problem found, that’s a great job the programmers did. If there is one, we’ll be thankful that we caught it in house rather than in the fields.