Solve Problems Without Code

Solve Problems Without Code

Several organisations have spoken to me about how they can accommodate cross-device / platform testing within the short, iterative cycles of Agile development methodology.

Our conversations start with the usual request for automation frameworks, parallelisation of automated tests, 3rd party device labs but after I've spent some time discussing the overall deployment pipeline we discover other options are available to us.

Options that don't involve writing code...

Proud sponsors of NWEWT!

Testagility's reason for being & passion is to help people test better & have fun whilst doing it. We provide several means of making this happen, one of which is co-sponsoring the North West Exploratory Workshop on Testing (NWEWT)  


NWEWT is a weekend-long peer conference of 15 - 20 attendees which enables facilitated deep discussions on software testing related topics. 

This year the topic was "innovation in testing".

As well as some fantastic insights from the speakers & discussions themselves, there were also some great points around the conference format & attendees which were uncovered in the retro at the end of the weekend.

You can read the write up on the Association for Software Testing website who are the other sponsor for the event.



We're now a proud BIMA Member!

We've recently joined the British Interactive Media Association (BIMA)

This is a fantastic opportunity for us to contribute to an already thriving community which closely aligns to our ways of thinking.

Specific areas of interest for us include the communities, think tanks, creating change & of course developing our network.

We're really looking forward to helping the community, both here in the North West & further afield!




Check your interpretation

Check your interpretation

At Testagility, we're big fans of Virginia Satir, in particular her Interaction model & how it helps us improve our communication.

The model suggests ways interactions can go astray & ideas for getting them back on track. Check out this great resource for more details on the model.

During the interaction, we can check back with the sender what they sent in order to try & prevent the interaction off track.

This post came about after a conversation I had with a client focusing on the different ways we receivers can misinterpret a message (in the Meaning stage).

It's all about questions & answers


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:


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.