When a tester gets the zoomies

Zoomies actually describe the frenetic random activity periods that dogs and other pets have. They are random bursts of energy in which they run around frenetically.

Then there is an activity as part of Systems Thinking which is zooming in and zooming out. According to studies at the Cornell University people tend to not zoom out. Nearly everyone zooms in, nearly no one zooms out. I think that I’m part of “nearly no one”.

In Systems Thinking theory zooming in refers to breaking up a whole into parts. Then taking a part and breaking it up again, and so on. Zooming out is taking a whole and looking at it as part of something bigger. Then taking that again and look what it’s a part of. When using different perspectives zooming in and zooming out is not necessarily a repeatable process.

Example: add a new field to an existing web form.

Zooming in:

• what type is that field on the UI, how large is it, where is it positioned
• when sending the form, what type of field is the parameter in the e.g. JSON
• when processing the field, how is it parsed and treated in code
• when it ends up in the database, in which column does it go, what is the definition of the column

We are taking a new requirement (field), breaking it down into its parts (UI, API, DB). And then we are looking into each part and go into more and more details.

Zooming out:

• what form does it belong to
• what is done with the data after it’s being stored
• which other elements of the product are impacted
• what does that mean in terms of deploying
• are there other dependencies when delivering the new feature
• do we have mechanisms in place to deliver such a change in a safe way

And then there are the zoomies, constantly zooming in and out:

• new field in the database -> do we need a migration script -> impact on other fields -> impact on other functions
• migration script -> could there be runtime issues, what about the performance, do we need a downtime -> do we have everything in place for a downtime
• delivering the new version -> migration script -> rollout, what happens in case of failure -> how to rollback the migration script
• migration scripts -> do we have mechanisms in place to run migration scripts, do we have mechanisms in place to automatically roll back the migration
• rollback of the migration -> what is the process looking like, whom to inform, what to document
• rollback of the migration -> what impact has the partial rollback on other elements of the delivery, do they need to rollback as well

And so on. This is what partially goes on in my head within seconds. Call it ADHD, hyperfocus, bonkers, whatever you want. This is only a tiny fraction that goes on in my brain, when I hear about a new requirement.

Systems Thinking is about constantly improving, adjusting, correcting, extending, and much more of our mental model. The product and its elements are only one part of this. The ecosystem of the product, the process landscape, teams and roles, the company and the customers/users are also a part of the mental model. And I don’t stop at the product borders. When I see something is missing in the process landscape or not supporting good enough, I tend to try do something about it.

I know a lot of people who are very good at zooming in. I also know that a good portion of them is also zooming out. But too many stop at product boundaries. When it comes to evaluating risk and impact, zoom further out. Look at the bigger picture. Practice to zoom in and ZOOM OUT!!! Understand the bigger picture beyond the bigger picture.