A question I often ask testers is 'can you draw me the architecture of the systems that you test?' The answer is often stares blankly. I believe this is a core competency for an effective tester and the answer should be (more often than not) 'of course I can!' Architecture is a social construct, it is one of the main artifacts a team will gather around to discuss technical direction and customer need. If a tester cannot contribute effectively to this process, then an opportunity may be missed to gather important context for a balanced approach to testing.
Architecture is changing rapidly too. Testers will often be faced with cloud replacing the on premise physical architectures, or even hybrids of both, creating a further dimension of risk. Add containerisation and infrastructure as code then the big picture becomes even more complex. However, where there is challenge there is also opportunity for testers to add further value and play a greater role as teams adjust to change.
This tutorial encourages testers to interrogate, evaluate and elucidate the architectures they test, with the end goal of providing analysis of risk and insight into how testability can help address those risks.
- Attendees can recognise and explain the load balancing, web, API, database and shared access networks architectural layers
- Attendees can recognise and explain the impact of cloud architectures on testing and testability concerns
- Attendees will be able to sketch an architecture from a set of technical documentation and anecdotal sources
- Attendees can identify key risk points within an architecture and build a context sensitive approach to testing
- Attendees can apply models of testability to identified risks to propose enhancements