System analysis is an essential skill for software testers. It helps us identify how different parts of a system connect and where potential risks or opportunities for testing might lie.
While system mapping may seem daunting at first, using the right technique can simplify even the most complex systems.
This activity is all about putting system analysis into practice! Let’s explore different ways to visualise and understand a system and share what we find!
Steps:
Pick a system: Choose one from the list below list of possible application(s):
Social media platform
E-commerce website
Video streaming service
Fitness tracking app
Food delivery application
Select a tool: Use one of these tools to represent the system or choose your own technique:
Use Case Diagram - Focus on user interactions and system boundaries.
Data Flow Diagram (DFD) -Show how data moves through the system
Mind Map - Capture key components and their relationships.
Create your diagram:
Map out the key components and workflows of your chosen system.
Focus on making the diagram simple and clear.
Reflect:
Write a few sentences on what you learned from visualising the system.
Try using a second tool to create another diagram, then compare the results.
Share your work
Share your reflections and comparison findings in reply to this thread to share and gain insights from others.
Why take part?
Sharing your work helps others see different ways of analysing systems.
I used the e-commerce site example and applied use case/mind map.
It is easier to visualise rather than looking a document, mapping out the use case diagram may be able to help you find things you may have missed reading a document (pages of text is never fun)
Mind map - found this was more higher level to plan for functional/non functional/technical + key features. But also could see how they relate to each other, and more of “what do we need/what is required” questions started to pop up.
Use case diagram - more zoned in to the step by step process of “how” the process works, but then also gets into the detail of what’s involved at which process. Also found I was asking more “what will happen if” questions. And so many arrows, Figma skills are still basic
I didn’t complete this exercise exactly as described because I’ve plenty of experience with the majority of techniques described, some of which were required as part of my role.
Even without creating a new diagram, I could answer the reflection. The act of modelling out systems for data flow diagrams when threat modelling was really powerful in challenging our understanding of the system. It makes me think about the different components, what interacts with what and also the different data involved, trust boundaries in place and different data stores (including more than databases!).
When asked in an interview about how I would learn the system to get up to speed, modelling it was my immediate answer.
The Actual Activity
As mind maps and DFDs are very familiar, I ruled them out and whilst I’ve worked with Use Case Models, we didn’t include UCDs (instead had UML diagrams)so went with this. As with another recent activity, I used the video streaming service (thinking Netflix, Youtube etc).
I found this a little tough to be honest. I suspect I’ve gotten it wrong, even after diving into more details on them. I could see it being a nice way to represent a Use Case Model but without that (and there was no way I was writing a 10 page UCM again!), it wasn’t that straightforward or even useful.
I think to represent the flow of behaviours with the different actors, I’d definitely prefer using swimlanes (used them in the past) as a way to model out the system. That said, if I had a UCM then the UCD would be a simple nice addition.
I keep seeing this topic, and was reminded of a mapping setup for mapping teams, not systems. And that still get’s me thinking, because if you use swimlanes and journeys, or prefer UML or even prefer Data-FlowDiagram versus mind maps, they all work for some kinds of problem but not others, or just don’t scale easily without you regretting having chosen one modeling system over another. Regardless you have to start somewhere. and that’s something Simon Wardley does with his Wardley Maps. Although he is mapping companies and teams on their journey towards whatever vision they have, some of the ideas he touches on are portable into system mapping. Things like choosing your landmarks and language so that your target audience can use your map while they are out there in the real world is one of them. As is being able to zoom out and see the entire beast in one go too.
Ability to check or test assumptions about a system, but in small chunks where the smallest discrete chunk is analogous to one instruction on a roadmap, and still useful as a goal. Gives me a better sense of how detailed I will be allowed to make my model and still not get bored before I finish. If I get the zoomed out level right, my model can easily ignore inconsequential changes in the product, in much the way someone navigating from A to B might reroute if there are roadworks or if a bridge gets moved permanently. Product feature details must be allowed to change at all times, just like road trip plans. And that’s becasue your perception of a large system will change as you discover more of it.
