The opening keynote was delivered by Andrea Tomasini, Agile testing is nonsense, because agile is testing. On the face of it, this was a somewhat contentious title given the audience, but the sentiment was intriguing.
Testing is an approach, an attitude to apply to a situation, any situation, and not necessarily done by testers. So I kind of agree here, Testing is a mindset, and Testers are not the only ones to have it!
Andrea talked about the trap that most of us have fallen into at some point which is assuming that we know what the customer wants. What we should really be doing is talking more to our customers, creating a vision with them, with the stakeholders. This I do agree with. Getting in early, being the question askers, finding out what the customer _really_ wants will ultimately save time, effort and ultimately money because there will be more chance of making the right thing!
I took some other notes from this session but to be honest the session was somewhat intense. A few pauses here and there would have been nice, but it was relentless with too much information to take in. I was left wondering what the actual message of the presentation was…
Following the keynote and a much needed coffee it was time for Do or do not, there is no try by Jamie Wong and Ioulia Anastasiadou from Huddle. They explained how as a team they had realised they had problems with their user stories, resulting in delayed released, scope creep and too many assumptions.
One of the changes they made was to add more detail to the story card including a checkbox to record whether the story has been reviewed. This made the process more visible to the team, and ensured that reviews happened. I liked this idea, particularly the review of the story, not just the tasks. I’m also a great believer in making whatever process you have visible to everyone. This then encourages/shames people into actually doing it!
They didn’t stop there. The story card change didn’t solve all of the problems, so they iterated. Trying specification by example, getting stakeholders to review the story an wording stories in the given/when/then format. All of these changes led to better understanding of stories.
Do not stop changing the process, no matter how small the change, and JDI (Just Do It). We have a slightly cruder and more forceful variation of this JFDI, and is a term that I frequently use rather than procrastinating.
Anand Ramdeo presented the session Misleading Validations: Be Aware of Green and many of the opening statements he made totally resonated with my experiences. With the move toward continuous integration, faster releases, agile, automation, more emphasis is being placed on what has been tested, rather than what hasn’t been tested. Too much emphasis is placed on everything being ‘green’. All this does is prove that the software behaves as expected. In fact it’s not even that, it proves that the tests that ran last time, still run and still pass. The danger of confirmation bias is huge here. Don’t rely on ‘green’ as confirmation that the build is good and can be released. You need both the checking and the discovering parts of the testing, and it’s the discovering part is what’s missing.
With my consensus talk looming, I skipped Mary Gorman’s keynote after lunch to put the finishing touches to my presentation, but I am rather gutted because it sounded like it was a really good one (from looking at the twitter stream!)
So then it was time. Consensus talks 1 and I was the last of the four to speak. It seemed like a good idea at the time to go last, but in retrospect I had to nervously wait for 45 mins until it was my turn! It was really cool being up on the main stage, mic’d up with a fairly large audience. My talk Blurring the Lines was a cut down version of one I did at Agile Cambridge back in September, but it seemed to go well. I had some good questions at the end, and even had one of the Prezi developers approach me at the end to compliment my Prezi slides!
It was a relief to get the talk out of the way, so I could relax and enjoy the rest of the conference, but I now want to do more, and will try again for a full session next year!
|New badge for 2013!|
Following the consensus talks and due to the way the afternoons were structured with full afternoon workshops, I had the option of attending the TestLab, or one of the Dojo’s. Having loved the TestLab last year it was a no brainer! So off I toddle to say hi to James Lyndsay and Bart Knaack and see what cool stuff they have for us to test!
It was nice to see the lego robot back, but I didn’t do this one again. Instead I paired up and did a challenge using a visual programming language called Scratch. What I tried to do was write some BDD style scenarios for the tasks, then code it up. This actually led to an interesting behaviour that took us a while to resolve. It was a cool process to go through and I’m well impressed with the programming system. Would certainly be great for kids to learn the basic programming constructs.
The final keynote for the day was The Science Behind High-Performance Teams with Peter Saddington. This was a very entertaining presentation, and was a very different experience to the opening keynote earlier today.
One of the interesting statements that Peter made was that one of the best examples of a small high performing team is actually marriage! However, even this fails 50% of the time! A high performing team is one where the manager (and the team as a whole) understands the members of that team. Everyone has their own way of working, their own quirks, what drives them. To understand this enables the team to optimise around this information.
One of the important points that Peter pointed out was that as emotion increases (due to conflict, argument, unrest etc), understanding of the problem/team decreases. As these behaviours are understood, the accuracy of predictable patterns increase which in turn increases productivity.
The second of the important points was the work should be fun! Do you have fun at work? It’s important to enjoy what you’re doing, and this usually comes from having a purpose, autonomy in your role and mastery of your skills.
The third and final point was that of multitasking. Peter called several people up onto stage including my colleague Emma Armstrong, and a delegate I met last year, Mary from Paddy Power. He then proceeded to do a game with them to demonstrate that context switching is bad. “Multi-tasking makes you stupider” was a quote that resonated with me. Give someone one task to do, and they will more than likely knock it out of the park. Give the same person two, three, four tasks to do, and productivity exponentially drops off.
Sessions over, and it was time to get ready for the Most Influential Agile Testing Professional Person (MIATPP) award night, and like last year Díaz & Hilterscheid did not disappoint! The theme was Halloween… so makeup and liquid latex later…
… and I came in second place for fancy dress!
That, together with the band, the mentalist, sitting with Dan and Paul from NAP, and hitting the dancefloor with Matt Heusser, Lisa Crispin, Janet Gregory, Eddie Bruin and many many others made it an awesome night!
My Takeaway Triple from Day 1
- Green does not always mean good, use it as one indication of the state of a release, but not the only one
- Multitasking makes you stupider
- Don’t cram too much into presentations!