Bjarke Ingels had mentioned “In the big picture, architecture is the art and science of making sure that our cities and buildings fit with the way we want to live our lives”. On those lines, serving as proxies to users, testers would benefit from understanding the system architecture to identify whether the features fit the user’s needs. Ash Winter‘s workshop on testing the bigger picture at TestBash piqued my interest. I attended it and thoroughly enjoyed it!
Have you heard someone mention about zooming out to look at a problem? Has your mind/someone constantly reminded you to think about areas you want to test by looking at the bigger picture? If you answer yes to either of the questions, you would probably have enjoyed the workshop too.
Ash had a nice style of conducting the workshop. He started the intro talking about the importance of system architecture to a tester which were elucidated by the subsequent group exercises he had in store for us. So…why exactly do testers need to understand the system architecture?Some of the key points mentioned were:
- Understanding the system architecture helps testers contribute better towards the project
- In agile teams rather than being affected by the ticket-by-ticket syndrome (testing only a story rather than the feature as a whole), we need to look at the system as a whole. This reminded me of an article from Janet Gregory and Lisa Cripsin (Testing the Big Picture on Agile Teams)
- Avoids scale panic if testers understand the architecture.
- One of the use of understanding architecture is to understand risk and for testers it can be one of the methods to identify risks.
- By understanding the system architecture we could be in a better position to know what to ask for in terms of enhancing testability.
You may be wondering why I mentioned earlier that I loved the workshop structure. It was because the group exercises were introduced with clear missions and learning objectives and we followed Kolb pattern. It felt like a very useful learning method to me. I was new to ‘Kolb cycle’, so if any of you are wondering what it is, the picture below summarizes it. (See Reference)
Ash employed the Bloom’s taxonomy to help plan effective group exercises.
He provided us with lots of analogies for the conceptual layers of system architecture to help us familiarize and start recognizing the main conceptual layers that may exist within an architecture. The terminology would be a reference for subsequent exercises. The layers we discussed were:
- Networks – data plumbing
- Web – for consumer communication
- App – where your business logic might be
- Storage – where you probably persist data
In the next exercise, anecdotal evidence, performance stats and bug reports were provided which acted as pieces from a jigsaw puzzle. We were asked to piece together the puzzle by identifying oracles which might be most/least reliable. Based on the common architectural notations we had learnt from our previously exercise, we had to propose an architecture plan thinking about the tiny details from the evidence provided.
Ash introduced us to Scott Barber’s FIBLOTS mnemonic and James Bach’s heuristics for testability. By stepping back and viewing the system architecture we had drawn as a group, we were then asked to identify architectural risk and look for ways to improve testability. This was a brilliant way to cement our learning in my minds!
To sum it up, the workshop was too short for the amount of learning content Ash had to deliver. It would have been wonderful to have worked on his exercises for the entire day. With respect to what Ash introduced, the experience and reflection stages ended and the journey for conceptualization and experimentation stages are about to begin…