It’s an open question. I don’t have a precise answer. For years we’ve been told that “you have to do testing”. But really what value does testing give you beyond someone saying “its broken”, or “50% of it is broken” for the statistically minded among my readers.
If I have a tester on one of my teams, I want them to be quality focused, not necessarily test result focused. So what does a tester do, day-to-day to improve quality. Surely some of the work involves:
- Making sure that test cases can be traced back to requirements.
- Making sure that tests are passing, or progressing towards a pass state.
But perhaps the more interesting work is what you do once you get that information:
- What classes of test failures are the most common? Bad data, bad code, bad specifications?
- What automated repeatable processes can be added to a project to improve quality at a lower cost?
Finally – is the tester the ultimate arbiter of DONE in an agile team? Do we even have a role of tester in an agile team, and if we don’t, how do we focus development team members on quality enough to spend the time doing stuff that isn’t just about writing code? How do you encourage developers to fix broken windows, and keep them fixed.