Improving Quality with "Developer Testing Masters"
I believe that software development has gotten to the point where we need more specialization in testing. We need a new type of tester. One that will bridge the gap between development and QA. A champion that will leverage and maximize the developer testing effort. Let’s tentatively call this position Developer Testing Master (as in Build Master and Web Master) – feel free to suggest better names.The responsibilities for a Developer Testing Master (DTM) would include:
Help to set-up a software development environment that enables continuous integration and testing.Alberto goes on to describe the required qualifications for a DTM: "demonstrated passion for, and experience in, developer testing" as well as "leadership ability to evangelize, motivate, and train developers in the art and science of unit testing."
Analyze the existing code base and recommend and/or implement re-designs and refactorings to make the code base testable.
Extend and customize xUnit framework to standardize and simplify unit test writing for the other developers.
Create and deliver basic unit testing training material to educate all developers in the art and science of unit testing.
Work with the team to decide on [and track] developer testing metrics and objectives.
In the comments following Alberto's article, a common refrain is that the Developer Testing Master would simply be doing work that the development team itself should already be doing. Perhaps. But experienced agile practitioners know the difficulties of test-infecting a development team, as well as the difficulties of achieving a harmonious integration of developers and testers.
On most agile teams, however, the real gap exists at a higher level - customer acceptance testing. To this end, the Developer Testing Master could help realize acceptance test automation, using tools such as Fit or Watir or even WinRunner.
Not sure what to think
User acceptance test automation wouldn't make much sense for 2 reasons: 1) The customer needs to get hands-on experience test driving the application to make sure it does what they need it to do and 2) test automation needs to be re-run many times in order to justify the cost.
Hopefully, UAT is not re-run at all, let alone many times - that would be a sign that the app was way off-course during development.