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.