Agile Principle #9: Agile testing is not for dummies!
In agile development,
testing is integrated throughout the
lifecycle;
testing the software continuously throughout its development.
Agile development does not have a separate
test phase as such. Developers are much more heavily engaged in testing, writing
automated repeatable unit tests to validate their code.
Apart from being geared towards better quality software, this
is also important to support the principle of
small, iterative, incremental releases.
With automated
repeatable unit tests, testing can be done as part of the build, ensuring that
all features are working correctly each time the build is produced. And builds
should be regular, at least daily, so integration is done as you go too.
The purpose of these principles is to keep the software in releasable
condition throughout the development, so it can be shipped whenever
it's appropriate.
The XPeXtreme
Programming) agile methodology goes further still.
XP recommends
test driven development,
writing tests before writing the software.
But testing shouldn't only be done by developers throughout the development.
There is still a very important role for professional testers, as we all know
"developers can't test for toffee!"
:-)
The role of a tester can change considerably in agile development,
into a role more akin to quality assurance than purely testing. There are
considerable advantages having testers
involved from the outset
This is compounded further by the
lightweight approach to requirements in agile development,
and the emphasis on conversation and collaboration to clarify requirements more
than the traditional approach of specifications and documentation.
Although requirements can be clarified in some detail in agile
development (as long as they are done just-in-time and not all
up-front), it is quite possible for this to result in some ambiguity and/or some
cases where not all team members have the same understanding of the
requirements.
So what does this mean for an agile tester? A common concern
from testers moving to an agile development approach - particularly from those
moving from a much more formal environment - is that they don't know precisely
what they're testing for. They don't have
a detailed spec to test against, so how can they possibly test it?
Even in a more traditional development environment, I always argued that testers
could test that software meets a spec, and yet the product could still
be poor quality, maybe because the requirement was poorly specified or
because it was clearly written but just not a very good idea in the first place!
A spec does not necessarily make the product good!
In agile development, there's a belief that sometimes - maybe
even often - these things are only really evident when the software can be seen
running. By delivering small incremental
releases and by measuring progress only by working software, the acid
test is seeing the software and only then can you really judge for sure whether
or not it's good quality.
Agile testing therefore calls for more judgement from a tester,
the application of more expertise about what's good and what's not, the ability
to be more flexible and having the confidence to work more from your own
knowledge of what good looks like. It's certainly not just a case of following a
test script, making sure the software does what it says in the spec.
And for these reasons,agile testing is not for dummies!