It was my first time attending a LAST conference and it was certainly quite a different experience to any other conference I’ve attended. Most of my experience is in attending testing-related conferences (of both commercial and community varieties) and LAST was a much broader church, but still with a few testing talks to be found on the programme.
With about a dozen concurrent tracks, it was a tough job choosing talks and having so many tracks just seems a bit OTT to me. It was the first person experience reports that made for highlights during this conference, as is usually the case. The Seek guys, Brian Rankin and Norman Noble, presented Seek’s agile transformation story in “Building quality products as a team” and this was a compelling and honest story about their journey. In “Agile @ Uni: patience young grasshopper”, Toby Durden and Tim Hetherington (both of Deakin University) talked about a similar journey at their university and the challenges of adopting more agile approaches at program rather than project levels – this was again good open, honest and genuine storytelling.
(I also made an effort to attend the talks specifically on testing, see later in this blog post for my general thoughts around those.)
The quality of information provided by the LAST organizers in the lead up to the conference was second to none, so hats off to them for preparing so well and giving genuinely useful information to presenters. Having said that, the experience “on the day” wasn’t great in my opinion. It still amazes me that conferences think it’s OK to not have a room helper for each and every session, especially for those conferences that encourage lots of new or inexperienced presenters like this one. A room helper can cover introductions, facilitate Q&A, keep things on track timewise, and assist with any AV issues – while their presence can simply be a comfort to a nervous presenter.
Secondly, this was the first time I’d co-presented a talk at a conference and it turned out to be a very good experience. Paul Seaman and I practiced our talk a few times, both via Skype calls and also in front of an audience, so we were confident in our content and timing as we went into the “live” situation. It was great to have some company up there and sharing the load felt very natural & comfortable. Paul and I are already discussing future joint presentations now that we know we can make a decent job of it. (The only negatives surrounding the actual delivery of the talk related to the awful room we had been given, with the AV connection being at the back of the room meaning we couldn’t see our soft-copy speaker notes while presenting – but neither of us thought this held us back from delivering a good presentation.)
Thirdly, this was the first time I’d given a conference talk about my involvement with the EPIC TestAbility Academy. The first run of this 12-week software testing training programme for young adults on the autism spectrum has just finished and Paul & I are both delighted with the way it’s gone. We’ve had amazing support from EPIC Recruit Assist and learned a lot along the way, so the next run of the programme should be even better. My huge thanks to the students who stuck with us and hopefully they can use some of the skills we’ve passed on to secure themselves meaningful employment in the IT sector. The feedback from our talk on this topic at LAST was incredible, with people offering their (free) help during future runs of the training, describing what we’re doing as “heartwarming” and organizations reaching out to have us give the same talk in their offices to spread the word. This was a very rewarding talk and experience – and a big “thank you” to Paul for being such a great bloke to work with on this journey.
Turning to the testing talks at LAST (and also the way testing was being discussed at Agile Australia the week before), I am concerned about the way “QA” has become a thing again in the agile community. I got the impression that agile teams are looking for a way to describe the sort of contributions I’d expect a good tester to make to a team, but are unwilling to refer to that person as a “tester”. Choosing the term “QA” appeared to be seen as a way to talk about the broader responsibilities a tester might have apart from “just testing stuff”. The danger here is in the loading of the term “QA” – as in “Quality Assurance” – and using it seems to go against the whole team approach to quality that agile teams strive for. What’s suddenly wrong with calling someone a “tester”? Does that very title limit them to such an extent that they can’t “shift left”, be involved in risk analysis, help out with automation, coach others on how to do better testing, etc.? I’d much rather we refer to specialist testers as testers and let them show their potentially huge value in agile teams as they apply those testing skills to more than “just testing stuff”.