Where Am I?

On orientation before testing

I made a mistake and tested something in the wrong environment.

It’s not like I tested in production and caused an issue. It’s that I lost time. And I embarrassed myself.

The developer was kind about redirecting me and explaining where I should be testing and why the environment mattered.

For a moment, I felt like a rookie tester all over again.

I listened as he explained things I already knew. I bit my tongue, nodded, and when the conversation ended, I walked away with a deep sigh.

The embarrassment was real, but staying stuck on that wasn’t particularly useful. The faster I could get past it, the faster I could focus on what I had missed and what I needed to do next. I should have checked the environment first.

Orientation is one of the most basic parts of software testing and one of the most important.

Testing is not just execution. The environment, the data, the permissions, the release state, the flags, the assumptions—all of that shapes what a result means. And to start, testing in the right environment.

This is why I’m often mumbling to myself: Where am I? Who am I?

Key points of orientation are about:

• What environment am I in?

• Is the correct build deployed?

• Is the feature flag on or off?

• Which account am I using?

• What permissions does that account have?

• What data do I have or have to build?

Testing without basic orientation is like navigating with the wrong map.

Time gets lost.

Defects don’t count because they were found in the wrong place or incorrect configuration.

Work has to be repeated.

And sometimes the lesson arrives with a healthy dose of embarrassment.

Testing is not just execution.

The weekend arrives. I take the quiet of a Saturday afternoon and begin all over again. On the upside, I’ve experimented with the new feature already, I have been down the core path of the feature.) Step by step, I follow the expected path, taking screenshot after screenshot getting a feel again for how the feature works. There is no Slack action on this Saturday afternoon, my time is pure focus and I quickly get caught up and then past what I’d been able to test during a noisy workday.

Given enough quiet and enough time, my understanding deepens. This testing session counts, I nail down an issue I had only a hint of before, the issue is still there and I can isolate it. I can also see that even though I had tested in the wrong environment, the first exploration wasn’t completely wasted. I had started building a mental model of the feature and that understanding was not wasted.

I review the notes from the developer and better understand his concerns and the amount of testing that remains. I take the dense notes and break all of what needs to be tested into pieces, crafting separate sessions so I can return to smaller tighter hyper-focused testing sessions.

I’ve set myself up to return to work in sessions, blocks of time, focus and the aspects I need to test and the developer wants feedback.

Now the map of what to do feels like mine.