My first testing party.

Not my first testing party in life, of course. I’ve been a tester a long while now and, at my age, there aren’t all that many firsts anymore.

I decide to dress up which, since I work from home, means wearing a “better” T-shirt than usual.

I’m excited, though I’m not about to admit that to anyone. I already lean toward the nerdy side, and confessing that I’m looking forward to a testing party feels like it might be taking things a bit too far.

By midday, the party begins. Midday my time, anyway. The team is spread across the globe, with an impressive collection of time zones to accommodate. Thankfully, this is the sort of team that remembers people don’t all live in the same part of the world.

As a contractor, I decide my best role is to observe while participating.

The developer who built the feature is hosting the party.

That immediately catches my attention.

In most organizations I’ve worked with, a tester—or the QA team—would organize an event like this. I want to watch how this team approaches it.

• How do they run a testing party?

• How do they collect and organize feedback?

• Will what they find change the anticipated delivery date?

• And how does the person who wrote the code facilitate all of this while racing toward a release?

The Teams call opens.

The party begins.

Susan, the developer and organizer, gives a brief overview of the feature—the sort of introduction you might expect to find in release notes or end-user documentation. But then she does something unexpected.

She begins explaining how she built it.

She openly shares the parts of the implementation she found challenging and, more importantly, what she’s worried about.

Wait a minute. What?

How refreshing, I think. How humble. More than anything, how honest.

When someone with deep technical skills and polished soft skills openly shares uncertainty, I notice.

Already we’ve moved from what could have been a required meeting to an honest invitation for help.

Susan ends her overview and ask for help and the team seems ready to jump in. I still hold back, I want to see how the team rallies and how I can be part of the help.

Mia and Jackie, two developers on the team, volunteer to work together. Not surprising. Even in a remote company, spread across different locations, they seem particularly like work friends. They outline what they plan to cover, drop from the Teams call, and promise to report back.

As they do, I’m reminded of a time when I was asked to test my manager’s code. He was also the head of development. Perhaps a story for another time.

Jason, the product owner, explains what he’d like to review. Less certain about testing, and not paired with anyone, he decides to stay on the call throughout.

My coworker, also a tester, asks if I’d like to pair up to explore a few race conditions that we’ll need to coordinate. I jump at the chance. He tells the team we’ll drop off as well and report back when we’re finished.

The rest of the team chooses what they want to cover. Some pair up. Some don’t.

I’ve been testing this feature intermittently for more than a week, yet Susan had never mentioned these concerns before.

I can’t help wondering why.

I make a mental note to ask her later. Not now. Today she’s busy shepherding a room full of testers.

We test. We return to the Teams call. We’ve only one observation, not really a bug but something worth noting.

The Teams call is hopping with activity. This really does feel like a party. Multiple conversations are happening at once. The room is alive.

I wonder whether we’ve missed the most interesting discussions and how Susan is somehow keeping up with it all.

Somehow, she is.

A wiki page has been prepared. A table lists bugs alongside observations. People are adding notes, screenshots, and discoveries as they go.

I find myself wishing I’d stayed on the main call. But like any party, you can’t be part of every conversation.

I’m not sure how today’s discoveries eventually find their way into Jira.

But this clearly isn’t the team’s first testing party. No one seems concerned about what happens next. I suspect there’s a well-worn process that begins once the party ends.

Tim, the principal architect joins the call, he’s the late party arriver and wants to see the wiki page. Interesting I think, he knows how these parties work and knew when to join.

Susan summarizes the issues, she seemed to expect Tim’s late arrival and nothing has thrown her off being the party host.

“We are at time” Susan announces and I look to see indeed, our meeting time has come to an end. Tim offers to stay on the call with Susan to discuss the issues found and next steps. I internally smile to myself about the parallel to after parties and how it is a subset of the larger group that get included. The team begins to drop from the call and I realize, it’s time for me to drop and get back to the rest of an ordinary testing workday.

Looking back, I don’t remember the bugs we found.

I remember the room.

I remember people choosing where to help.

I remember a developer comfortable enough to say, “Here’s what worries me.”

I remember a team that didn’t wait to be assigned work.

That’s what stayed with me.

As I drop from the call and step away for my own lunch, all I can think is: what a fabulous party.

But the next day rolls around and the developer slacks me a message that he can’t reproduce the problem.

My first thought is that maybe I left something out. I check but the steps and screenshots haven’t disappeared.

Mm. I wonder. I don’t reply yet.

The developer left me another slack (we’re in different time zones and the messaging helps us stay in sync) he says that he’s found a bug (no details) but not to worry because he fixed it already along with finishing up other bits of coding. He also tells me the fixes are in place in the environment I’ve been testing in and asks if I can check out the build.

Oh. Mm. I wonder again that he cannot reproduce my issue but then also he’s made updates.

Two words come to mind: version control.

I realize these words have not been mentioned while I’ve been working here. I had already noticed that finding the build number had been damn near impossible and no one seems to discuss this.

In this environment - part of why I like working contract - is the variety, I have few set ideas about “how we do things” because every place I work is quirky in its own way.

Version control I think again. So I switch back to trying to replicate the issue I saw just yesterday.

Can I reproduce my bug? I try. I can’t. And there’s no build number and no other environment for me to test in, this new feature hasn’t been deployed into our QA environment and so it’s certainly not in staging, the env before production. The bug has disappeared.

I’m less concerned about the one bug and more concerned that all the testing I’m doing is like dancing on ice, a bit out of control and possibly a fools errand.

I feel the need to be careful rather than critical. I wonder whether suggestions like build numbers and version control will sound old school. My concern isn't helped by the fact that I've been in the field a long time. Ageism in tech is not nothing. It's rarely discussed, but it's always there.

I decide to wait before responding and see if we might “chat” once he’s online. Later in the day we connect. I wait again to hear his thoughts before rushing in.

He tells me he’s had the coolest evening the day before as he vibe coded until midnight and put the changes into the test environment he’s setup for me.

I’m dancing on ice. Mention a concern about vibe coding or late night updates and I will be tagged in this environment as someone unwilling to try the new. I’m not paranoid, this is the deal here.

I’m open to try anything. I’m not anti AI inherently. Dang I use AI everyday at work and personally. I’d actually used the company’s approved AI to write my bug report and I have to say, my reproduce steps were streamlined and I took the advice to add a screenshot for a step in the process.

I continue to listen and he begins to tell me how to test because given my bug isn’t reproducible maybe I need help understanding how to test software.

Experience isn’t always visible, and assumptions aren’t limited to one generation. I continue to listen. I wonder why he assumes I'm a novice tester instead of asking about my background. I decide not to redirect the conversation. I want to see where it goes.

He asks if I might test further on the environment. I tell him, I have two other devs asking for me to test and that I’ll move onto their stuff and cycle back to his feature to test more hopeful the code might be more “solidified” by the time I come back around. One can hope.

I bite my tongue on version control. I let the bug slide into the unknown cool night. I have doubts, concerns but this isn’t the place for that conversation. At the moment, I’m not sure with whom or when to raise bigger than a singular bug concern. Or how to raise concerns about version control and vibe coding finding a harmony. I’m aware of how quickly I could sound hooked on the software practices of yesterday and sound dismissive of new approaches.

The conversation leaves me with questions much larger than our Slack exchange or the single bug report that started it all.

Leaving me asking:

What of the old still matters?

What of the new should we embrace?

How do you raise concerns without sounding resistant to changes?

Who keeps the human watchful eye to discern what works?

Then it wasn’t.

It’s easy to feel the familiar hurry-up-and-wait frustration.

Early in my testing career, I remember feeling restless, even agitated, when this happened. I wanted the build. I wanted to get started. Waiting felt unproductive.

My manager noticed.

"You don't think there's anything you can be doing while you wait?"

The moment he asked, I wasn't so sure.

He waited.

I paused.

I could prepare test data, reread the release notes and look over the bug reports.

I could see his point.

I remember sighing. He was right.

That conversation came back to me recently when a build was delayed.

After all these years, I can still hear my former manager's voice. Only now, it has become my own. It's the question I ask myself whenever an unexpected delay appears.

Instead of focusing on what I can't test yet, I start looking at the work already in front of me. If I still have the previous build, I can reproduce issues that are about to be fixed, capture missing screenshots, document existing behavior, or think through new test ideas before anything changes.

There is really always something that can be done, the better question is what is the best use of time?

Over the years, “waiting for the build” has become an opportunity to:

• revisit assumptions

• reread release notes

• review bug reports

• refine a test idea

• prepare test data

• organize screenshots

• think through different test scenarios

• learn more about the feature

• simply think

The question isn't, "What can't I do?" The question is, "What's the best use of this time?"

Subscribe now

A basic regression test. An essential workflow. The kind of test that can lull you into going through the motions if you’re not careful.

I was nearly bored stepping through it, but discipline matters. Some tests aren’t exciting. They still need to be executed.

Then the test failed.

A bright red toast message appeared in the corner of the screen and disappeared almost as quickly as it arrived.

Wait. What did that say?

A reminder to never fall asleep at the wheel. You never know.

Fortunately, there was a way to reproduce the failure.

I turned on screen recording, repeated the steps, and captured the error. I’ve learned that if I have a recording, I can play it back frame by frame to catch a screenshot of a message that appears for only a moment.

A screenshot from a screen recording. Whatever it takes.

With evidence in hand, I reached out to the more experienced tester on the team.

His response was what I expected: guiding questions.

What had I been testing?

What steps had I taken?

What data was involved?

What environment was I using?

He knows the application so well he didn’t need to actually see anything. He knew which clues mattered. He knew which variables could influence the outcome. Within a few questions, he had already narrowed the possibilities.

Sometimes I wonder if a trained eye carries an entire system in memory.

That’s knowledge grown from experience. The trained eye.

The developer joined the conversation and began asking questions of his own. What struck me was that the experienced tester understood parts of the system that the developer, who had been changing the code, did not.

I’ve seen that before.

As the discussion unfolded, I found myself watching how an experienced tester responds to a failure.

Not with certainty.

Not with a solution.

With questions.

The developer and I were both relying on his expertise in that moment. Yet what stood out wasn’t simply what he knew.

It was that he cared.

This wasn’t his bug. It wasn’t his task. He could have pointed us elsewhere or stayed focused on his own work.

Instead, he got involved.

He felt ownership.

He wanted to understand what had happened.

What does experience teach us to see?

How much knowledge is accumulated simply because someone remains curious, pays attention, and keeps showing up for the work?

As I watched him work, I realized the trained eye isn’t just about spotting failures.

It’s knowing which questions to ask.

It’s understanding which details matter and which don’t.

It’s caring enough to keep digging when the answer isn’t obvious.

And perhaps most importantly, it’s creating enough safety that other people are willing to bring you the problem in the first place.

The bug was eventually understood.

What stayed with me was something else.

Part of what made it easy to bring him the problem was knowing there would be no ego, no finger pointing, and no boasting. He created space for investigation. Space for learning.

I’ve worked with brilliant people who made others afraid to ask questions.

The knowledge existed, but access to it was limited.

Knowledgeable.

Approachable.

Caring.

A safe space to learn.

That combination matters.

The trained eye isn’t simply the ability to see what others miss.

It’s creating the conditions for others to learn how to see it too.

Subscribe now

A new person on my team asked for a 1:1. Of course, absolutely, glad to meet.

When we hopped onto a Zoom call, he shared a bit about his background and then mentioned that he had never worked in software before.

He had a simple question:

What does a tester do?

I haven’t been asked that question in years.

My mind immediately went in a dozen directions. Years of experience had given me countless answers. I could have talked about exploratory testing, automation, release testing, risk, strategy, tools, techniques, or process.

Instead, I found myself searching for a simple answer.

Not because the question was difficult, but because I was aware of the moment.

This was someone new to software. I had an early opportunity to help shape how he might think about testing and testers. We only had so much time, and I wanted to be thoughtful about the answer.

After considering far more possibilities than the moment required, I finally said:

“We help. We explore software. We point out findings and ask developers to fine tune issues so that when we ship as a team, our product is better for our customers.”

As soon as I said it, I noticed the language I had chosen.

We.

Team.

Our product.

Not inspection.

Not policing.

Not gatekeeping.

Collaboration.

That surprised me.

I wasn’t really describing testing techniques or explaining the mechanics of the job. I wasn’t talking about tools, processes, or methodologies.

Instead, I was describing how I see the role of a tester within a team.

There will be time to discuss testing approaches, different techniques, and the details of the craft. He’ll see the kinds of questions I ask and the issues I raise. Those lessons come with experience and time.

What felt more important in that moment was helping him understand that testers are participants in building software, not observers standing outside of it.

He asked what a tester does.

What does a tester do? How would you answer that question?

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?

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.

Subscribe now

There’s a welcome in the ask and so much opportunity.

The invite sends the message that they are open to feedback, curious to see what I find, and the offer tells me they see the work of a tester as helpful.

Alongside the preview build, a developer often walks through a feature or fix in detail, explaining how they approached a technical challenge and what areas concern them most. The one-on-one conversation outside of a team meeting creates an easier setting to ask multiple “what if” questions without slowing down a larger discussion.

I listen carefully to what is ready for review and what is not quite finished.

I learn more about the feature, the developer gains another perspective, and together we begin to identify areas that deserve a closer look. By the time the build reaches the QA environment, I already have a deeper understanding of what was built and why.

In the early stages, there is also more time. Time to offer suggestions. Time to raise concerns that may require deeper thought or more time, topics like performance issues or other risks that are easier to address before a feature is complete.

Some of my favorite moments as a tester happen before a build ever reaches the QA environment. They begin with a developer saying, “Hey, can you take a look at this?”

No wonder someone coined the metaphor of a “train” as I envision pieces finally arriving at the end destination station called Production.

Features, flags and database changes often move on different timelines and yet still need to arrive in Production in coordination, often involving multiple teams with different sprint cadences.

The moving parts eventually come together to not just roll out a feature but to “stand up” the entirety of the feature in Production.

A feature built in code is like a car on the train.

Database changes are like train tracks running underground, laying boundaries for the data beforehand.

A feature flag is like a traffic signal, gating the code until all the parts arrive at the station.

Multiple teams are at work, each with their own Sprint cadence and yet ultimately the code, the database changes and the flag all need to catch the Release Train. A flag flipped “on” when the time is right, a feature unfurling into Production, database and configuration settings lined up correctly — it is a grand orchestration.

Testing isn’t always about visible user interface windows and pop-up messages. The invisible is sometimes the most interesting to test and probably why I can find bugs away from the keyboard at times.

Issues are not always what you can see physically but what you can see mentally as you draw on a whiteboard, a notebook or inside your own internal white space.

Thinking about automation, I think I’ve found a solution and then immediately realize a possible roadblock to what I thought might work.

Existing automation that works before this new feature could be re-used if there is a rollback or if the flag is turned off.

But as I mark up my notebook, it occurs to me that the database changes themselves might block the automation.

The existing automation may eventually break, but that break might not happen on a visible software release date. It could happen later when another team rolls in database changes. I’m not sure. There’s probably an interesting discussion there, the complexity of rollouts and the alignment of more than one team’s work.

When more than one team is building and making changes to a single product, each team has its own sprint cadence and pressure to move code onto the Release Train. Knowing where the code actually exists — in a test environment or in Production — takes coordination and oversight. That coordination is beyond my current role as one team’s tester but not beyond the kind of operational awareness testers begin to develop over time.

Earlier this week a developer was insistent that they had fixed a bug, reliable and rock solid work, so another tester and I weren’t calling it a bug but it was clear the fix wasn’t in the test environment. The developer had to dig in to find if her code had been included in the deploy and when she found out her code had made the release, all three of us were puzzled.

A bit later the developer mentioned another software program built by yet another team but essential to the application we were testing. She’d discovered the other team’s code changes hadn’t made the release. I think back to the train analogy and see disconnected train cars in my mental mind map. The puzzle pieces have to move in coordination or issues begin to surface.

The longer I test, the less I think only about features and the more I think about movement. Timing. Coordination. Dependencies. What arrives where and when. What happens if one piece rolls forward and another does not.

Somewhere along the way my testing stopped being only about what I could click on a screen. As my testing chops grew, so did the need to think beyond the visible and draw mental models of systems in motion.

Underneath are feature flags, rollout timing, database changes, deployment coordination, environments drifting apart and multiple teams trying to move software forward together without disconnecting the train cars along the way.

Maybe this is why exploratory testing still holds my attention after all these years. The software itself matters, of course, but so does the operational choreography surrounding it. The invisible movement underneath before anything becomes visible to the end user.

Sometimes the problems reveal themselves while thinking through the alignment of all the moving parts.

Subscribe now

I need to gather my thoughts first. I write phrases in my notebook, not organized in any particular way. I don’t want to force structure too early in the thinking process.

Ideas come at assorted times. Like testing, insight rarely arrives all at once or only while sitting at a desk. For that reason, I try to start early and let time and space do some of the background percolating that tends to happen.

I write before I speak.

I let my thinking drift and shift because I trust that eventually my scattered thoughts will become a coherent talk.

One beautiful aspect of speaking is that it forces clarity. You want to know your subject matter. You want to know where you stand on a topic and how you practically do the work you’re talking about. Any speaking I do has to come from lived experience, recent and relevant.

Storytelling is an important part of how I present, but the stories have to be mine.

The preparation beforehand forces me to organize my thoughts, revisit resources I value, and fully immerse myself in the subject. I go through that process in pursuit of clarity and simplicity. What do I actually think? What do I really do in practice?

Work experiences go through a kind of mental filtration process. I try to keep as much of the reality as I can while stripping away client confidentiality or details that distract from the larger point. I want the heart of the experience, not the specifics of the client.

Then there is the question I keep returning to: what might someone learn from what I’m saying?

If I’m not sharing something that could genuinely help someone, then I don’t want to stand up and speak. I repeatedly ask myself: What is the takeaway? Can I articulate it clearly enough?

Speaking also carries responsibility. I committed to a topic when I submitted an abstract. Am I prepared to deliver what I promised? Does the presentation match the intent of the proposal?

And then there is the practice itself. Years ago, I would record myself speaking and force myself to listen back. It was awkward and uncomfortable, but worth every moment.

I take my introverted self to conferences and stand up to speak anyway.

Over time, I’ve come to appreciate those opportunities deeply. I’ve met more testers through speaking than writing. I’ve heard other people’s stories, perspectives, and experiences, and those exchanges have been enriching.

For as solitary as the preparation behind speaking can be, the community and kinship around craft that comes afterward feels like a real gift.

Subscribe now

There is something about the mental energy of testing, trying to find where software breaks, that has me deeply engaged in the work.

When I worked as a Director, much of my day revolved around coordination, communication, staffing concerns, deliverables, and organizational pressure. I cared deeply about the people on my teams, but somewhere along the way the keyboard seemed to move further across the room from me.

I missed the proximity to the work.

The sustained concentration of trying to understand how a system behaves. The curiosity of tracing workflows and designs, exploring edge cases, and following hunches down to reproducible bugs.

In an earlier chapter of my career, I once wrote about the delight of finding bugs while out on a walk, hands nowhere near a keyboard. Some of my best testing ideas arrived away from the screen, while mentally turning over risks, workflows, and system behavior.

That is how compelling testing feels to me. It’s not just the keyboard at my hands; it’s how deeply mentally engaged I become in the work. Time disappears.

I like being part of a team, not apart from a team.

I like finding problems and advocating to get bugs fixed.

I love being a tester because I spend most of my day noodling around features and fixes, trying to understand how things work and where they might break.

I spend my time asking “what happens if…” over and over again until I find bugs. I build mind maps, trace workflows, test around boundaries, and follow vague concerns long enough to turn hunches into reproducible bugs.

Thinking through edge cases. Reproducing bugs. Noticing inconsistencies. Exploring beyond simple validation.

Testing is the craft of sustained thinking.

At my desk early, offline status in Slack, I create the quiet I need. My second cup of coffee and I’m ready to dig.

I’m curious. I might find ideas to test. I might find patterns in issues. I don’t know what I’ll find—I want the space for my own wander through Jira.

I query Jira for bugs that are closed, I filter for higher priority and severity. What has the team fixed before. What has been deemed important? What do they see as priority?

Technical debt. How many bugs in a backlog do they have? How does the team balance maintaining a quality product versus the pressure to deliver new features.

How has the team balanced fixes versus features?

I wonder how hefty the bug heap is. The backlog size raises the bar on what gets fixed.

Backlog tells me too, how challenging will it be to get bugs fixed. I want to wrap my head around existing bugs before I begin thinking my bug finds are the only issues in the queue. I’m all about advocating to get a bug fixed but my finds aren’t the only ones.

Querying by feature, I focus on the most essential parts of the application. I especially want to know about these past issues; what was addressed and what remains.

I query by reporter, who has historically been finding the issues? I find a Product Manager no longer working at the company reported more bugs than anyone else. Mm, frustration factor? I drill in to check by priority and severity, they didn’t seem to nitpick, their finds were good it see

I query by developer assignment. Everyone has habits, good and bad. What types of issues do the devs make? I’m looking for patterns and tendencies.

After every query, I run an export and build a folder on my desktop. Jira History. I finish my coffee. I flip my status in Slack to Active. Ready for the day. I’m new, but the product isn’t. I’ve spent the morning distilling some of its history. I’m less new now, more informed.

I can’t quite wrap my head around it. I can’t yet build a mental model that makes sense to me. I’ve scribbled notes more than once and all my notes seem like gibberish. Dashes of thoughts not formed, not yet cohesive thinking. There’s a clarity I expect to reach, and I’m trying to puzzle my way there.

If I don’t understand something with enough clarity, that leaves space for a bug to escape. I could miss an issue and not even know it.

It’s been a while since learning something new has troubled me like this. I feel self-conscious that I’m not catching onto it. The day offers disruptions and distractions and my frustration grows. I vow to show up early the next day and take a fresh crack at it.

I try some of the same things I’ve done in times past. Is there a help file? Are there specs? Are there bug reports that highlight where this feature has had issues before? I like to play with software to learn, but I also like to read if there is something to be found. There is no documentation.

I ask someone whose knowledge of the software is stronger than mine and, in record time, he demos the feature with ease. I understand more, but not all of it. We wrap up a Teams call and I try simulating the same steps—a gift to have a few moments so shortly after our call that I lose no time from demo to trying on my own. I must have missed a step because I can’t get through the process.

Time feels tight. The more I try to hold onto what was demo’d, the less I feel like I retained. How embarrassing.

I remind myself what I need at moments like this.

I’ve learned complex things before and I will master this too.

I’ll ask for help again if I need to, but I want to muddle the best I can—the balance between lost time struggling and someone else’s time helping. I want to find my own way and I am determined to do so.

It’s a funny thing. I’m generally looking to break software, not have software break me.

How can I possibly find a good bug if I can’t step through the basic operation—the happy path, the “it works” path—before I go off road looking to throw a condition unplanned for? I realize I want to see this feature work before I try to break it.

I think about the business process. What is a user trying to do? Understanding why the software is being used helps me understand how it functions.

The next day I begin early. I stay offline, showing inactive on Slack. I silence my phone and my computer. I pull out my gibberish notes with a clear head and a strong coffee.

I try again to mimic the demo. I’m still not able to model what was shown, but my stumbling blocks are now clear questions. I can see where I’m stuck.

Being able to clearly articulate where I’m stuck makes the ask different. I’m comfortable tracking someone down—literally or metaphorically—if my questions are solid and my attempts on my own have been credible.

I return to my notes. The gibberish becomes questions. I sketch a flow of the feature. I start to see how the pieces connect.

And I begin to wonder if the places I struggled are the connective tissue in the system—the places where things could break once I understand enough to go off road.

The deeper I know something, the deeper I can test.

The team is onto the next set of features and bug fixes. I don’t move on as quickly. There’s a mental pull to production—wondering if everything is going to hold.

What I do next depends on where I’m working and what I have access to. That first hour is a narrow window.

If I can, I tiptoe into production. I might spot check a fix or a feature—something small, something familiar. I’m looking for where things feel fragile.

I remember a go live after a long testing cycle. That morning, a required license file was missing in production. The system went offline. Chaos. Experiences like that build testing bones.

If I have access to production dashboards, I’ll take a look.

In more restricted environments, production requires clearance. No access, no wandering.

In an office, I might “happen” by customer support or the DevOps team.

Remote, it’s Slack.

Are we in the clear?

I’ve lived through enough rollbacks and hotfixes to know—we don’t know yet.

I don’t trust the silence right after deploy.

What matters is when the system is in real use—when customers start showing up. Time of day matters more than the moment of release.

Go live is a sharp on–off switch.

Confidence takes time.

A fresh fix increases a file size limit, allowing a user to upload a larger file. Boundary testing.

I build files around the new file size; at the boundary, above and below the new max limit. Equivalence partitioning. I create files of different types and gather them into a collection, tucked into a folder. This collection will serve my testing well.

I upload files one at a time. There’s some refreshing in between uploads. Then a session with no refreshing, choosing instead to upload the maximum number of files, all at the max file limit. The max of the max. The retests are straightforward—uploading files of different sizes and observing how the software responds.

Then there is a passing thought: where else does this application allow uploads, and what are the limitations on those file sizes? Are the limits the same? (Should they be the same?)

At this moment in testing, I’m looking at the application through a different mental lens. I’m not thinking about functionality—I’m thinking only about files and size limits. This leads me into a short testing session focused just on that: file sizes across the application. There are other spots to test, places to consider.

As I encounter a different file size limit somewhere else in the application, I pop a question into Slack to the Product Manager about the consistency of file size limits across the app. I’ll see what response comes back.

Another thought about files—this time about downloading. What goes in I’ve explored, but what about what comes out?

The application hasn’t had to handle exports or downloads of this new file size. This isn’t the specific retest anymore—this is thinking about the change introduced and how one change can ripple into other areas.

These tests are not drift. It’s an intentional expansion of the original ask—one way testing can act as an anchoring source for keeping an app consistent.

Taking notes has always been part of how I work. Really, it’s how I think.

In journalism, in technical writing, and in software testing, writing things down is how I learn and make sense of complex systems. Some ideas don’t fully form until I’ve jotted notes. Even when they look messy or disorganized, the writing is where my brain is synthesizing information.

I didn’t set out to study how I think. I just wrote. Over time, I realized the writing was my thinking.

On my desk—and on my computer—are the ways I keep track of my work.

One notebook is for confidential client work. Labeled and kept separately.
Questions. Half-formed ideas. These notes are work artifacts. When a contract ends, I shred and dispose. Nothing strays.

Alongside that, my electronic Daily Folder holds screenshots, Slack snippets, and assorted items—the record of what happened.

My paper notebooks give me space to think through what I’m seeing.

For a long while, I had a practice of writing a capital “T” circled on the page.
A signal to myself—this is a test idea. I could flip back, recall test ideas, and see what I wanted to follow up on.

I’ve used similar patterns in session notes too—not always perfectly—but enough to make ideas findable later.

Alongside my work is a separate notebook altogether. This is not a daily notebook—this is my tester’s notebook.

This notebook holds distilled thinking.
Where I go meta.

Observations about how I explore a system.
How I decide what matters.
Patterns that repeat.

These notes are not tied to any specific company, system, or product.

This is the notebook I carry to a coffee shop.
The notebook that sits on my writing desk—no computer, just space to think.

It’s where ideas like these begin:

• Thinking in Mind Maps

• Heuristics, Mnemonics & a Card Deck

• Dealing with the Incompleteness of Testing

• Asking for Production Stats

• Testing Parties

• Looking for risks

• How a tester helps during production deploy

• Backlog grooming

• Waterfalling testing

• Bad old code no one owns

The folders hold the record of the work.
This notebook holds the thinking that comes from it.

And this is what I’m publishing here—what is literally inside my Tester’s Notebook.

Subscribe now

An internal Slack post shares the Product Team’s release notes — the same notes that will be emailed to customers. I read the post, curious to see the marketing spin on the new features and the handful of bugs fixed in the release.

Nothing new here.

And then I notice two bugs listed that I didn’t know were in the build.

My thoughts fracture in different directions at the same time:

• Why didn’t I know those bugs were included?

• What code effects could those fixes have introduced?

• How quickly can I catch up on regression testing around those fixes?

Product release notes can offer an unexpected place to find ideas for bug hunting. Preferably before shipping.

I catch up to Jira but don’t see tickets referencing these fixes. I didn’t miss them. Somewhere, the process did.

Not a bug, but still a problem.

Production health comes first, so I shift to catch-up testing. What can I learn about these fixes, and what risk might already be in motion?

Two bug fixes shipped without visibility.

Not because anyone intended it.
But because the system allowed it.

Software bugs break features.
Process gaps break awareness.

And awareness is what keeps small issues from becoming larger ones.

This is the type of risk that accumulates quietly — until something larger slips through the same gap.

Awareness is protection against risk.

This is one reason why I show up for deployments. To listen. To learn. To note where weak spots reveal themselves. To be part of the team in moments that matter.

On one team, I needed to show up in person at 4am — not just once, but weekly. I’d run smoke tests as soon as the build was in place, providing assurance that the build we had worked on together was now in production and ready.

The team in this case was well organized, making the 4am part of the job more doable. One habit the team had was choosing one or two visible bug fixes as a way of confirming the expected build had deployed — a small, reassuring signal. Even though we could confirm the build number, the UI check provided an extra measure.

At 4am, there was no confusion, no apprehension — just a calm, quiet checkpoint.

On another team, all of us worked remotely, using a Slack huddle to navigate deployments. I couldn’t see the anxious moments, but I could hear the tension. Even remote, I could learn over time which parts of deployment were most vulnerable.

In the most anxiety-provoking moments, I can see and hear what has worried the team most. I listen for the moments of apprehension from developers. I sometimes wonder why these concerns hadn’t surfaced earlier, but tight timelines and the reality of release into production often reveal last doubts.

In person or remote, I’ve learned something that has played out over and over again:

Listen. Take note.

That’s where a tester can help.

Someone I worked with recently told me they had never worked a deployment before. A situation I found unusual.

“If it’s all been tested, why would I be there? A deploy should just be mechanical.”

Mm. If only.

Some observations I’ve discovered during deployments:

Learning environment differences.
Production data — it’s never quite like test or staging. Environmental gaps surface issues.

Verifying what matters, not everything.
At deploy time, broad coverage isn’t the goal. Focus narrows to a few critical paths — the ones that would hurt most if broken — checked carefully.

Watching the quiet checks.
The quick UI glance or repeated workflow isn’t random. It signals where trust is thin.

Noticing what changes at deploy time.
Feature flags turning on and off. Configuration settings shifting. These small changes often surface the real issues.

Most testers who’ve “been around the block” know that production deploys are part of the job. Not the glamorous part — but an important one.

It signals to the team that you’re part of it — living, breathing, deploying — not just critiquing. I don’t always know what will unfold or how I’ll help. But it matters to show up, be there, and be willing to lend a hand.Thanks for reading Tester's Notebook! Subscribe for free to receive new posts and support my work.

Curious to find fresh bugs for a revised feature soon to ship, I curated a list of existing bugs and asked an LLM for ideas. A list generated. There could be a lead.

The hunt.
The curiosity.

I have my own ideas, my own ways of bug hunting, so this use of AI isn’t a shortage of ideas or a false dependency as much as a curiosity about what might emerge from another source.

And like any source, there’s skepticism. There’s discernment in reading a list. I’m not asking for directions or steps. I’m looking for ideas and willing to weed through generated output even if the net result is only one good lead.

Time invested? A data export from bug tracking, a data scrub, an import with a few directions, and a scan through a list.

Proprietary data concern? I’m not sloppily exporting confidential proprietary data but making use of a workplace’s gated internal LLM — a safe place to experiment.

The output.

Keep in mind, I wouldn’t take a list from someone on a product team or from a development team — or anyone’s list — without applying my own discernment, product knowledge, background, and experience to vet it.

But what every tester does carry is history — past bugs, patterns, instincts about what tends to break. That knowledge is powerful, but it can also introduce bias. AI, used this way, doesn’t carry my biases, and I’m counting on that.

I eyeball through the list like a detective on the lookout for a clue. There’s more focus on one aspect of the feature than I had formulated. Why? Did I miss something? In that moment of pause, I try to cultivate an open mind while thinking through test conditions.

Another idea: what do I know that the LLM doesn’t know?

I load the feature specs into the LLM. How does the addition of this information change the test ideas? Are all the requirements covered by one or more tests?

Another idea. My draft of test ideas — I had held those back as a test of sorts. Now the LLM has the requirements, the test ideas, and the history of bugs. How do those inputs influence the ideas?

I realize this has become a kind of conversation; the back and forth of input and results. Few people are willing to spend this much time ferreting out ideas without their own biases.

It is, I think, one of the more interesting conversations I’ve had this day.

An original introvert, AI is a quiet companion of sorts.

There is no shortage of conversation about AI — predictions, concerns, debates about what it might mean for the future, environmental questions and more. It’s not that I don’t care about these rippling ramifications. I’m simply curious to gain my own experience.

AI is not perfect — nor has any tool I’ve worked with over the years been perfect. And like working with another person, I’m learning how to ask questions in a more directed way. I’m learning how much to share to get better-shaped answers.

Our conversations are growing on some projects, limited on others, but always there is an opportunity for another way of thinking.

I never leave my judgment to the side.

AI brings perspective.
I bring discernment.

The value comes from combining the two.

Because remember, there is no space for blind faith in a tester.

Testing demands a strange combination of thinking.

Structured. There’s a helpful approach to thinking in structured concrete pathways, the type of thinking aided by disciplined execution especially helpful when pushing through regression testing. Stay the course, do the thing you’ve done probably done dozens of times already and somehow stay alert just the same.

Adventurous. There’s a creative approach to playing with a new build, a new feature, uncharted land often accompanied by a developer or team looking for “fast” feedback if possible. Sure there’s a plan (maybe) but you want to see as much as you can as fast as you can. You want to try tests that have never been run before.

Strategic. There’s the customer, the marketplace, the business side of the software you’re working on at a small company looking to make it big with what they’re building. You believe in the product, you’ve researched the market space, you’re reading the reviews in the App store of the latest release gone live.

There are more mental approaches to testing, I am sure but there is one mentality, one way of thinking that may hit you in the face every time there’s a product software release. You will never test every condition you can think of. Can you accept that?

The space is vast, the browsers, the devices, the data, the features, the weird twists and turns in the code, you won’t have time to venture into every corner.

I’ve watched testers wrestle with this in different ways. No matter the approach, the problem remains.

• We care.

• We try.

• We plan.

• We cannot do it all.

• And still we ship.

One time, a big release getting ready to ship, I had a giant spreadsheet of ideas, test conditions to cover and I asked my boss: “want to look at my plan?”

His answer stuck. His answer: “Nah, I trust you. I know you’re doing your best. We’ll just see what the customers find or not when the code ships.”

Bone chilling. The responsibility was real. I had to trust my thinking. I had to choose wisely. And I had to make peace with what I left untested.

The instinct to find issues doesn’t just happen when it’s time to test. There are opportunities all around the project to listen, to watch and to gather ideas.

Testing is hunting, hunting for ideas.

Notice when

• a developer shares concerns or roadblocks while building a feature

• a product manager admits uncertainty about how part of a feature works

• learning user device statistics and realizing coverage hasn’t been as complete as assumed

• and other times I troll through Jira, read through past issues, looking for where issues, looking for patterns — where things broke before, and where they might break again.

I’m hunting and I gathering.

A long time ago, my parents were in a small disagreement about where a street was located. This was before GPS and other easy ways to look up information.

“I know where that street is” I piped up.

“No, that can’t be right,” my mom had said.

“Well, maybe she’s got something,” my dad said.

I told them more. They were surprised that I knew but I had been a kid sitting in the back seat time and time again, reading street signs, observing houses, people and what I saw. Street names stuck. Sharing what I saw wasn’t about being right. It was about observing — and helping.

When I hear a developer struggling to build something, I find a moment and share what I plan to test, what I’m noticing. If I can help before something is built broken, I’m deeply happy to help someone, to help a team.

Listen, watch, gather and hunt.

More recently, I exported a set of Jira defects tied to a feature and fed a defect list into AI to see what patterns might surface. Sometimes hunting is instinct and listening. Other times, it’s strategic pattern analysis.