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!

Duncs

 

BIMA_Badges_Member.png

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).

Self (receiver)

  • Our understanding of a definition or Acronym (e.g. TDD, BDD, DevOps) differs from sender
  • Missed translations from languages other than our own
  • Interpretations from a message we mis-heard / mis-read 
  • Our relationship with the sender skews our interpretation of the message they're sending
  • We're having a bad day which leads us to jump to conclusions & incorrect interpretations 

Others (senders)

  • Senders understanding of a definition or Acronym (e.g. TDD, BDD, DevOps) differs from ours
  • Different translations of our language
  • Senders relationship with us skews the message they're sending
  • Sender is having a bad day which results in a different message being sent to the one that was intended

Context (situation)

  • A stressful encounter prevents us from thinking clearly (e.g. blame game in meetings)
  • Noisy environments leading to obscured messages being received
  • Cocktail party effect prevents us from attending to the current interaction
  • Rushed exchanges

Recovery

  1. Check back on the intake you received & see if you make the same interpretation again
  2. Check back with the sender on the interpretation you've made based on the intake to see if that's what they meant
  3. Think of 3 interpretations you think the sender could have meant
  4. Goldilocks - play back 3 interpretations; best meaning, worst meaning & a feasible meaning 

You can find out more about the Interaction Model here:

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.

 

We need Testers but we can't justify them

Maybe your company is just starting out & you haven't got capacity or funding for someone to fulfill the role of a Tester.

Or maybe you are the company, a one man band fulfilling all roles.

Either way, you've recognised the need for deep testing of your product but you don't know how to achieve it on the limited funding & resources available to you.

Well, guess what. It is possible for people who do not consider themselves as "Testers" to poke & probe the software in order to discover & gather information about the software to help you make those key decisions about your product.

Testing is moving away from the sole responsibility of those with a title of Tester towards the whole team carrying out testing activities.

Yes, Testers are fantastic at coordinating & enabling others to do the testing, but until you have them you'll need to manage without.

I can help you & your company discover how your product may behave in the hands of your customers so that you can make the necessary changes in order to delight them or bring in those sought after new customers!