Fast feedback

It's all about questions & answers

question-answer.PNG

Shorten the time between them

Testing is questioning a product. A product can be questioned at any stage in its development: a built solution, the requirements, the design & even the idea in the stakeholders head!

Striving to shorten the time between asking the question & getting a response will have tremendous benefits on your development pipeline.

Think of driving a car on a motorway - when answering the question "Am I in a lane?" there are several means that we get the answer; the white lines for immediate feedback, the rumble strips to snap us out of our distraction or finally the crash barrier is the final answer...

Examples of shortening feedback loops in testing include:

  • Question the requirements to drive out mistakes & ambiguities before code is written
  • Test the built solution on a local machine / dev environment before taking the time to promote it to a test environment
  • Automated test suites ask many questions about the known expectations & provide the answers very quickly

Outside of testing, you can use this idea to help optimise flow in your development process

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:

http://www.duncannisbet.co.uk/less-than-three-there-there-should-never-be

https://dojo.ministryoftesting.com/dojo/lessons/testers-be-more-salmon-duncan-nisbet

https://en.wikipedia.org/wiki/Shift_left_testing

 

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.