Play it again, Potsdam – Agile Testing Days so far…

Play it again, Potsdam – Agile Testing Days so far…

In an effort to blog about this more quickly that in the past, I’m doing semi-live blogging each evening, summing up the days events… they may need editing later, but they represent my thoughts of the days talks.

Where words fail, music speaks… was the first keynote of the conference by Huib Schoots & Alex Schladebeck.

The sight of a violin, trombone and two music stands on the stage was unusual to say the least, as we kicked off Agile testing days 2015. However, it’s not surprising since the speakers were Huib and Alex, both very lively characters!

They suggested that learning & playing music is a very individual thing, social and complex and that these are similar traits to that can be related to testing. They explained that music can be played note for note from sheet music, which is fine, but the real art comes in when you can play around the music. This can only happen once you’ve learnt the fundamentals as they bootstrap everything else.

Without knowing scales and arpeggios, it becomes really difficult to improvise away from the script.

The same applies to testing. Testing from a script, a test case, is fine, but repeating the same thing over again is unlikely to find any additional defects. However, by knowing the fundamentals of software testing, you can improvise, test around the scripted path to explore surrounding areas, but still within the context of the script. This improvisation is best done when based on context and experience of the tester.

During this talk, both Huib and Alex demonstrated the concepts by playing their respective instruments which was both fun and interesting. For example, you can hear when music ends on a bad cadence, ie it sounds like it’s ending, but continues a bit more. They compared this to the situation where testing is nearly complete and then you find more issues which causes testing to run on.

They also talked about the style in which you play depends on the context of where you’re playing. For example, playing solo, or in a small group will allow you to play more freely, whereas in an orchestra it is very prescriptive with no room for deviation. Apply this to testing and you have the environment in which you are testing. The message was to identify the context in which you are testing, and adapt your style and actions accordingly.

The takeaways were simple

  • Learn your team’s tune
  • Finish your sprints on a good cadence
  • Recognise your role and context
  • Practice, learn & apply patterns and be adaptive

A Happy Marriage between context driven and agile. Ilari Henrik Aegerter used to work for eBay, and shared his experiences of context driven testing in an Agile environment. I’ve not really understood the context driven testing vs agile testing debate so thought this would be an interesting talk to attend to try and get some further clarification on what the differences are. I don’t think it really helped me with that, but it was an interesting talk nonetheless.

I agreed with (and have been an advocate of) many of the statements Ilari made at the start. Things like “TDD is not testing, it’s a design technique”, and just because your automation is green, doesn’t mean everything is ok and developers prejudice against testers has partially been formed by them working with testers who claim to be great because they have certifications etc, when they don’t actually know how to test properly.
I shouldn’t really be surprised we agree on all this stuff as he is heavily involved in the AST and whose BBST material I’ve read and digested.

In explaining context driven testing, Ilari showed the agile manifesto which we are all familar with, but then showed his context driven testing manifesto that he and his colleagues created at ebay. There was more to this manifesto, but he was sure to highlight several that were mappable back to the agile manifesto. To be honest, it was all mostly common sense, but it’s good to write this stuff down.

on the topic of requirements, Ilari suggested that in the agile world, and especially in the context driven testing world, requirements are called oracles. These oracles (from the BBST material) can be any source of information including a person’s knowledge.

It was a good talk, and reinforced many of my views on testing within an Agile environment. I’m not sure there was anything new for me, but it is always good to hear practical stories of how teams have done it, rather than hypothetical nonsense!
Testers are dying. Controversial title for the after-lunch keynote, and one the speakers, Karen Greaves & Sam Laing, were quick to dispel! They had renamed the talk to something which better reflected the topic which was “Keeping up with demand”. They went on to explain that as development teams were growing, it wasn’t that testing was dying out, but it was that recruiting testers is really hard, therefore testing could not keep up with the increasing demand on it.

The talk basically revolved around a change model concept, not unlike ADKAR (Awareness, desire, Knowledge, Action, Reinforcement). They used the change model to increase the testing activity within teams to not only include the testers.

Their model consisted of:

  • Building awareness – increase awareness of the issues caused by not enough testing capacity
  • Punishment / consequences – make the consequences of this visible
  • Personal responsibility – encourage people to take responsibility, rolling testing into normal activities, rather than making it a standalone activity
  • Remove barriers – Make things easier. Possibly adopt a zero defect policy, with no bug tracking system.
  • Visible impact – use positive metrics to encourage behaviour change
  • Start a movement – share experiences/successes to encourage others to follow suit.

it was an interesting talk, and reinforced the importance for the whole team to be responsible for quality. I’ve found change models to be very useful to identify at what stage your team or organisation is regarding a particular change, and going through such a model can result in changes being adopted by the team on their own terms, rather than it being a dictatorial/top down decree!

Conversations not just the talks. As always, the conversations/discussions had before, between and after the talks are, in my opinion, where I now get the majority of benefit from attending these events. The talks are good, but the nuggets of information that apply to your context are more likely to be found when talking to people. From discussion on where Agile often goes wrong with Matt Heusser and Ray Oei, to hearing how Janet Gregory used to work with software/hardware and the different development approaches for those. I’m hoping for some more great discussions tonight, but for now, that’s it!

Leave a Reply

Your email address will not be published. Required fields are marked *