Last week was #TestBash and I’m still fully excited about the experience. The conference for me started off with the Workshop Day, I attended Ash Winter‘s “Testing the Bigger Picture – System Architectures”. The topic is something that resonated a lot with me the last few months – as recently mentioned, and also from experiences at my workplace, where we started to do collaborative sessions on system architecture, zooming in on different parts of our system and exploring them via the whiteboard. Ash’s workshop hit the mark for me there.
The format was pretty much hands-on, with a good balance of setting the stage, diving into group exercises, stepping back and reflecting on what we’ve done and learned, and a few handy methods, techniques and heuristics being introduced along the way. We worked our way through different exercises, starting off abstracting different conceptual layers (storage, app, web, network) that we than molded into an analogy of a common life scenario – my group explained “authentication” with the image of a party, where you are being let in based on some token, e.g. invite, have to pass a door, can be rejected, etc.
Up next we regrouped and attempted to sketch an system architecture based on bits and pieces of information we received – an older version of an architecture diagram, oracles, bug reports, comments of colleagues, statistics. I loved how real this all felt – typical types of information you might come across as a tester, and which you would need to make sense of, including trying to gauge how reliable the information or its source is. After presenting and discussing this together, we moved on to apply Scott Barber’s FIBLOTS performance testing heuristic. Looking at our model we tried to assess any risky area, asking for Frequent, Intensive, Business Critical useage, wondering about Legal issues that would get you sued or not paid, Obviously wobbly or Technically Risky areas or one’s that are strongly Stakeholder Mandated. Suffice to say, we had yellow post-it’s all over the place.
No surprises, Ash had still another ace up his sleeve. Now that we had been thinking about risk, he was challenging us to go back to the drawing board again and think about testability. For this he introduced us to James Bach’s thoughts on Testability – to look towards accessibility, observability, control, simplicity, unbugginess, smallness, decomposability and similarity, on tools we could use and data we might need. A lot of blue post-its accompanied the yellow ones on our system architecture picture although we also tried to pinpoint in the end the one area we’d want to focus most on.
Unfortunately we’d had to wrap it there – this could easily span over a full day, and no doubt we’d like to have spent more time on this. All together there was a lot to enjoy and learn in this workshop, and I’m really excited to go back to the project I currently work on and revisit my understanding of it, applying the perspective, methods and heuristics I learned here. A few examples and takeaways for me:
- I quite liked the balance of diving into challenging tasks in smaller groups and than regrouping as a whole, presenting and reviewing together on what each group had thought of.
- Getting introduced to some heuristics in context and being able to try them out immediately is what I’d wish for in a workshop – and as I hadn’t yet used the FIBLOTS mnemonic before that was a good one for me.
- I had wondered about testability in the past and was really happy now to being pointed to good resources and try it in action.
- To bring together risk analysis, wondering about testability and system architecture really brought value for me – as the bigger picture here did not only focus on me understanding what I’m testing, what’s happening or on understanding how something works, but led more pro-actively into looking what I as a tester should ask of the product and a fresh perspective on how I would and could be testing and implement as automated checks.