The third part of the “Is TDD Dead?” hangout series with Martin Fowler, Kent Beck and DHH centered around “Feedback and QA” - the nuances of feedback and the role of the QA. After the 1st part, Fabio Pereira published his thoughts “Mockists Are Dead. Long Live Classicists", followed by my analysis of Part 2 Test-Induced Design Damage. Fallacy or Reality? Here are a few takeaways from Part 3.
Kent started with a great rant about the tradeoffs inherent in testing.
There are various tradeoffs in his opinion about Testing. In an ideal world, you have instant feedback about programming decisions to determine is it ready to go live or not. That is IDEAL. That kind of feedback is impossible at the moment. So the question is: How far off the ideal do we need to back off?
Kent also shared an example that around ½ of Facebook’s hackathons have never shipped / gone live. So how much effort do you need to put in testing to find out that the idea was not worth pursuing?
Martin opined that the goal of testing is to validate multiple things you are looking for feedback on. The most important being if the software is doing something useful for the users of the software. The other category could be, say, if the HTML is rendering properly.
Martin listed these feedback categories that are crucial for the team to know:
David felt that TDD has become so successful that many teams removed QAs from the teams. TDD made programmers over-confident about the quality of the software that they came up with. Are more tests better tests? Are faster tests better tests? Where is the value from the automated tests? What about the overheads and balance that needs to be maintained?
Some programmers still believe quality is their responsibility. They consider quality to be automated tests. This is a shallow understanding of what quality is. Tests may be green, but they may not find actual problems. 100% test coverage does not mean there are no defects in the code.
Martin was optimistic that times they are a-changing. Earlier the role of the QA was confined to test scripts. Automation has changed that by embedding QA and testing in the deployment pipeline. QA at Thoughtworks, for instance, is a collaborative role and function - not the dysfunctional, throwing things over the wall, finger-pointing one, as in the “dark ages”.
Kent advised that perhaps we should put a few red pixels in the green tests bar to remind the team not to be too arrogant about what that “green tests” mean. As soon as you think you are not making mistakes anymore, that means you are making mistakes, and you stop growing as an engineer. Another way to “stay grounded” is to rotate being on-call for production issues. It helps provide a real-time feedback loop and point out all those gaps in your test suite.
Here are my thoughts from this session:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.