Testing is an important part of systems thinking. And systems thinking is an important part of the tester’s job. So what does a (software) tester actually do when it comes to thinking in systems while testing? Not in the abstract, philosophical sense. Practically. What happens in your head when you sit down to test something? I’ve been chewing on this for a while, and DSRP from the Drs. Cabrera gave me a vocabulary for something I’ve been doing intuitively for decades.
DSRP stands for Distinctions, Systems, Relationships, and Perspectives. It’s a framework for structuring your thinking. Let me walk you through it.
Distinctions: What am I testing, and what am I not?
Every test starts with drawing a line. This feature. This version. This user flow. A tester who doesn’t make these distinctions consciously ends up testing everything and nothing at the same time. You’ve seen it happen. Someone runs around clicking buttons with no clear idea of what’s in scope.
Making distinctions is the first act of understanding. Especially in complex systems. What is the thing I’m looking at? What is it not? Where does it start, where does it end? This sounds trivial, but it isn’t. Part of the confusion in testing comes from people not agreeing on what they’re actually testing. Drawing that boundary, that’s your first job.
Systems: What are the parts, and what’s the whole?
Once you know what you’re testing, you need to understand what it’s made of. A login feature isn’t just a form. It’s a frontend, a backend, a database, a session manager, maybe a third-party identity provider. Each of those is a part. Together they form the whole.
A good tester zooms in and out constantly. You look at the button (part), then you look at the entire authentication flow (whole). Then you zoom further out to understand its role in the larger context. You test the input fields in isolation, then together. Then you test how it behaves when the identity provider is slow or not reachable at all. You look at database tables and log entries. This zooming between parts and wholes is how you build your mental model of the thing you’re testing. Without it, you’re just poking at a surface.
Relationships: How do the parts connect, and what happens when I poke one?
This is where testing gets interesting. You’ve identified the parts. Now you ask: what happens between them? What does the frontend send to the backend? What does the backend expect? What happens when the database is not reachable? What’s the feedback loop when a user enters a wrong password three times?
Relationships are where bugs live. Not in the parts themselves, but in the connections between them. A tester builds a mental model of these relationships and then deliberately stresses them. That’s what a test really is: a hypothesis about a relationship. “If I do X here, then Y should happen there.” And when Y doesn’t happen, you’ve found something. Your mental model just got updated. That’s learning. That’s testing.
Perspectives: Whose eyes am I looking through?
Here’s one that many testers skip, though friends of mine are pondering on this topic for a long time. (Remember “personas”) You can test the same feature from radically different perspectives. The end user sees a login screen. The visually impaired user sees the same screen but different. The security engineer sees an attack surface. The product owner sees a conversion funnel. The ops team sees a service that might go down at 3 AM.
Each perspective has a point (where you’re looking from) and a view (what you see from there). A tester who only tests from the user’s perspective misses what the security engineer would catch. A tester who only tests the happy path is stuck in one view. Switching perspectives intentionally is one of the most powerful things a tester can do. And it’s something no automated test suite will do for you.
So what’s the outcome?
When you put all four together, something emerges. You don’t just “run tests.” You build a rich, structured mental model of the thing you’re testing. You understand its boundaries (Distinctions), its structure (Systems), its behavior (Relationships), and the different ways it can be seen and used (Perspectives).
The outcome isn’t a test report. The outcome is understanding. And from that understanding, you can tell the team things they didn’t know. Things they couldn’t see from their own perspective. That’s the role of the tester in this game. Not to be the person who finds bugs. But to be the person who thinks about the system in ways that nobody else on the team has the time or the inclination to do. This is how you detect risks. This is what you need to bring to the table when shifting left or right, away from that implementation verification slot.
That’s what a tester actually does. Think well about systems. Everything else follows from there.
PS: At a certain point in my career I realized the importance of systems thinking. And I tried to teach this to my team. And the ones who were good systems thinkers were actually fantastic testers. And the ones who struggled, you could tell. In their way of planning and doing testing, in the way they wrote bug reports.