Agile Testing

Testing gets squeezed at the end of the development cycle

It's not news that testing at the end of the development cycle is susceptible to being not only delayed, but also squeezed due to the fact that the deadline can't be shifted...

But how can you prevent that squeezing from happening?

You need to start thinking about shifting testing left; work out how you can start adding value earlier in the development cycle before the test phase even begins.

For example, question the requirements (or Acceptance Criteria) before any code is written to identify gaps in them or where they are just incorrect or ambiguous.

With this approach, you start to discover that testing is far more than testing a delivered system against predefined requirements.

Once the scales have been lifted from your eyes, you'll find it hard to go back!


Further research:


Testing in an Agile development team

An organisation's decision to shift towards a more agile & lean software development often leaves Testers wondering where they fit; promises of all the testing being automated, the whole team owning quality & light documentation appear to take away everything that Testers hold close to their heart.

The shortened delivery cycle means that Testers cannot be afforded the time they once used to have for planning, executing & reporting their testing.

So how do Testers fit in this fast paced delivery cycle?

For me, the answer is for the Tester to get out of their test phase & start looking at how they can deliver value throughout the entire lifecycle from requirements gathering to live site monitoring.

If testing is questioning a product to discover information, the Tester should be able to start questioning that product at any stage of it's lifecycle; in the business stakeholder's head, the documents, the code and the working system itself.

This idea made me think about how salmon have to make their journey upstream in order to breed (admittedly this metaphor fails down after the salmon have done their thing...).

The sooner we can question the product to squash assumption, the less chance those assumptions have of bedding in to the software.

You can find out more about testing in an Agile context via Duncan's blog, or attending this 1 day "Be More Salmon" workshop run by Duncan.