Let´s Test 2014 – day 3

The third day of the conference was also the last day. The day did not start with a keynote speech since there would be a closing keynote at the end of the day. Instead, I jumped into a session with Fiona Charles (@FionaCCharles) named “We can´t know everything – Promoting healthy uncertainty on software projects”.

Image

The session dealt with, as the title implied, uncertainty. How can we relate to it? Should we embrace it? How can we communicate it? In an attempt to answer these interesting and important questions we where divided into small groups and given excercises to think about and discuss.  Some highlights from the discussions from the top of my head:

  • Estimates was something that troubled a lot of people due to the uncertain nature of software projects. Some in the group had worked with a no-estimates approach recently where you just prioritize and do things one at the time. The team is trusted to not overwork or release with bad quality. This approach appealed to me a lot and I would love to not having to spend my time providing uncertain estimates. Although I realize (and so did the group) that this is not feasible in all contexts.
  • Good ways to deal with uncertainty where (among others): communicate with others to ventilate and/or to get help to mitigate , draw a picture with all your dependencies (servers, deliveries from others, etc) to highlight how testing is affected, accept that humans are not perfect and embrace that uncertainty, learn how your brain messes with you (analogy: when wathing a horror movie the most scary part is when you have not seen the monster yet. Once the monster is revealed, it transforms from a scary uncertainty to a known risk).
  • The model of the five orders of ignorance, presented by Eddy Bruin (@eddybruin). It helped me put concretize thoughts I´ve been having like “I don´t know what I don´t know yet”.

All in all a good workshop and like many times before, the major part of the content was created by the participants during the session.

After lunch I chose to attend “Quality leader – the changing role of the software testers” with Anna Royzman (@QA_nna).

Image

The background of this session was that Annas company went “full agile” and therefore she lost her position as QA manager and had to redefine her own role in the company. She presented a skillset needed by this new role much broader than the skillset needed from a classic software tester (if I may use that term). This due to that in the agile context, more testing is performed by the developers. This creates a need for someone who can provide a quality perspective to guide and facillitate the people performing the tests in every team. So this new role needs to both be able to test himself/herself and also to inspire, coach and teach other to do it. Quite a challeging task! Anna also provided an interesting comparison between the agile manifesto and the principles of context driven testing and found a difference between the agile “working software” and the  CDT “the product is a solution”: This difference explains why a tester with the CDT perspective is needed in an agile team: to strive for a satisfied customer, not only working software. This vision about the new roles of software testing reminded of the article from James Bach about test jumpers with the obvious difference that a test jumper jumps between teams, whereas Annas quality lead would work within one team. Anna pointed another difference that test jumper still was more test focused where the quality lead would be more focused on quality overall. I found this session interesting but I think it is hard to tell what the tester of today will transform to. But it is certainly interesting to think about different scenarios and I think that Anna made a lot of good points. My feeling is though that we have not yet found the suitable approach for the testing and quality skillset in the agile context.

The closing keynote was held by Jon Bach in a rare visit abroad (I feel lucky to have caught him while in Europe). He talked about best practices, something that is more or less a swearword in the context driven community since it is always possible to think about a context where a best practise is not the best practice (this is a fun excersize by the way, try to think about a way of working that you like and then find a context in where it would be a bad idea).

Image

Jon had an interesting approach where his keynote was created on a workshop he held earlier in the week where the participants made a list of common best practices and chose their top ten favourites. Jon then showed us numerous examples where these best practices would not be good practice at all. He also told us that he had tried hard to find a general best practice that could not be refuted. but he had not succeeded yet. In other words: there are no best practices that are valid in all contexts. After the presentation there was an open discussion where:

  • the word “practises” where defined
  • it was concluded that the term “best practices” does not exist in every language, but the phenomena is
  • CDT is not based on best practices but personal values such as integrity
  • not even in tic-tac-toe there is a best practice to play in a certain way (sometimes you want to lose)

Jon wrapped up the keynote by identifying the tricky part of delivering an artifact to a community which refutes best practices since that artifact may be misinterpreted as a best practise in itself.

The last thing that happened was that we got to write a letter to ourselves reminding us what we had learned during the conference and what we promised ourself to change when we get back to work (the letter will be delivered in three months from now). I loved this idea since it is way too common to go to a conference, get inspired and then get back to work just to get sucked back into reality forgetting about all the things you wanted to change.

That was the summary of the last day of Let´s Test 2014. A great conference which I hope to come back to next year. My intention is to write a retrospective blog post where I list the good and my ideas on how the conference can improve further. That might take a bit longer though since my family is calling for attention after my three day abscence. Stay tuned 🙂

Advertisements

3 thoughts on “Let´s Test 2014 – day 3”

  1. Thanks for writing about this. A good 3 day series with nuggets that I could read from the other side of the world.

    About the quality leader perspective from Anna, what I understood, it could be in line with the approach we do at Atlassian, that I will present at Lets test Oz. Some blog posts on it here:
    http://blogs.atlassian.com/tag/qa-series/

    Thank you!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s