In an Agile world unit tests and integration tests, in our case driven
by BDD declared stories, are a fundamental part of a development
team’s output. It could be argued that this is the most important
element as these both prove the software works and document what it is
supposed to do.
their tests cover sufficient scenarios so as to ensure the software
delivers when used in anger. The traditional approach is to have a dedicated test team that checks
the code in isolation as developers ‘can’t be trusted’ to do it
themselves. Personally I think this is balderdash. The test-team-as-gatekeeper approach encourages a lack of
responsibility in the development team. They can produce what they
like, safe in the knowledge that the test team will pick it up. And,
if they don’t, well they’re mainly to blame rather than the
developers. After all, they’re not testers. Far better to have developers engaged all the way to delivery and beyond. Pair programming, peer reviews and giving rapid iterations for the
customer to critique and break all ensure the coverage is complete.
But there is nothing like actually engaging with the user to really
bring home the importance of the feature being worked on or to bring
in to stark relief the usability assumptions they’ve made. So, death to test teams. There is no place for them in an agile world.