Why I Enjoy QA Testing

People think QA testing is just going through a check list or that at this point it doesn't even involve a human "because AI can do everything". Well neither is true.

A checklist assumes you know every way a feature can fail. You don't. You never do. The developer didn't build the feature expecting it to break, and the test cases don't cover every possible interaction between the new code and the existing system, and the edge cases live in places nobody thought to look.

QA testing is about discovering the thing nobody anticipated. It's investigation, not inspection. You're not confirming that the expected behavior works — you're hunting for the unexpected behavior that doesn't. That requires curiosity, creativity, and a human brain that can look at a feature and think: "What happens if I do this in the wrong order? What happens if I refresh mid-submit? What happens if the API is slow and the user clicks twice?" No checklist covers that. No checklist can.

Yes, an agent can run a test suite. Yes, an agent can navigate a browser, click buttons, fill forms, capture screenshots, and compare expected versus actual results. That's execution, and agents are extraordinary at it — faster, more thorough, and more tireless than any human. But judgment is different. Judgment is looking at a test failure and knowing whether it's a real bug or a test environment quirk. (And all AI agents hallucinate and the human will be the one where the buck stops.)

Judgment is looking at a feature or bug fix and knowing how to guide your agent to create the right QA tests based on what "code" was changed. It's knowing that the acceptance criteria say one thing but the user experience implies another — and deciding to test the implied behavior, not just the written one. Judgment is sitting with your agent and when the agent finds a small nuance in the test, you know where to still marke the QA test passed or failed. An agent can surface the data. A human decides what it means. An agent can run a thousand test cases. A human decides which thousand matter.

QA testing, in my opinion, has become the most exciting role in software development right now. Because when you combine human judgment with agent execution — when you take the curiosity, the creativity, the real-time collaboration with developers, and the investigative instinct that no checklist or AI can replace, and you pair it with an agent that can run tests across five platforms in three minutes and bring you the results — you get something that is neither a clipboard nor a prompt. You get a conductor standing in front of an orchestra. And that's when the job stops being something people misunderstand and starts being something they should be jealous of.

You See It First

Here's the first thing. In QA, you see the new features and the bug fixes before anyone else does. Before the customers. Before the marketing team writes the announcement. Before the release notes are drafted. Before the CEO demos it on a stage. You see it when it's still rough, still wet behind the ears, still carrying the fingerprints of the developer who just finished building it.

That's a privilege. I don't use that word lightly. When a developer finishes a feature — something they've been thinking about, designing, and wrestling with their agent for days or weeks — you're the first person they show it to. You're the first set of eyes that isn't their own. You get to watch something go from an idea in someone's head or a plan on the issue in Jira/pulse in Monday to a thing on a screen, and you get to be part of the moment where it either works or it doesn't. And if it doesn't, you get to be part of the moment where it gets fixed. You have direct access to the development team to get feedback quickly into their hands so they can address is asap before launch day. Once you prove it does work, it's released at the next software update for all customers to enjoy!

That feeling — the feeling of a customer never experiencing a problem because you caught it first and worked with the team to fix it— is one of the most satisfying feelings I know. It's invisible work by design. If you do your job perfectly, nobody notices. The product just works. The features just land. The updates just ship. And you know that you have assisted in making something for others that will help them do what they love and/or do their job better.

The Interconnectedness

But seeing it first isn't the reason I love QA. The reason I love QA is the interconnectedness that can happen.

In QA, depending on where you work, you don't sit in a corner running tests alone. You talk to the developers about the work they just did. You ping them over the internet and can test features and bug fixes together. You run a test, it fails, and you don't file a ticket and wait three days for a response. You turn to the developer — or you message them, or you call them — and you say: "This test failed. Imy agent wrote a write up about it, but here is some more context and some questions I have." Sometimes you just give them the update on Jira or Monday etc and other times they reach out to you for clarity and strategizing how to solve the problem together. Either way, the feedback loop is tight. Not tight in the corporate buzzword sense. Tight in the physical, real, felt sense. You say something, they respond, you test again, they fix again, you verify. Minutes. Sometimes seconds. The cycle from investigating to identifying to resolution is super short, and it makes you feel productive in a way that waiting on a ticket queue never will.

That's the thing about QA that I don't think people on the outside understand. The process of investigating, identifying, and resolution isn't a workflow diagram on a Confluence page. It's more of a live conversation, especially with the right co-workers. When things get tough, complictaed, or 2 verbal processors who just like to work in tandum are involved, the creative thinking and strategic problem solving happens in real time. Two people who are both looking at the same screen, both seeing the same behavior, both trying to figure out why it's doing what it's doing. One of you built it. One of you is trying to break it. And you're both on the same side — because the goal isn't to prove the developer wrong. The goal is to find the thing that's going to cause a problem for a customer, and fix it before it gets there.

I've been in those conversations where the developer watches the test fail and their face changes. That moment — the "oh, I see what's happening and what the agent did wrong" moment. That high level of interconnectedness to implement a solution and get the job done happens when we are both looking at the problem. We're both working it. The developer pulls up the code, prompts his agent to write it, build it, and deploy it to his test environment and I get my agent to do what can be automated or step in and manually take care of what needs a more thorough human evaluation of the "fix" or created thing. We go back and forth: "What if I change this?" "Try it." "Still failing." "What about this?" "Try it." "Pass." And the feature is better. The product is better. And we did it together in a conversation that took 15 minutes and would have taken hours or days if we'd been passing updates though an issue or pulse.

Mission Control

It's easy to identify why I'm so motivated and inspired to work this way: NASA Mission Control during the Apollo program.

If you've ever watched footage from Mission Control — or if you've seen the transcripts, or read the books, or listened to the real live recordings of the audio loops (which are on Youtube)— you know that it wasn't a room full of people sitting quietly at desks, each one doing their own thing and occasionally checking in on eachother. It was a room alive with communication. Every controller had a headset on. They were constantly talking — to each other, to the astronauts, to the back rooms. The flight director sat in the middle, and around him in a horseshoe were the specialists: EECOM monitoring the electrical system, GUIDO tracking the guidance computer, CAPCOM talking to the crew, FIDO running the flight dynamics, and a dozen more. And behind them — in rooms the public never saw — were the back room people. Engineers at strip charts and telemetry readouts, watching the same data from a different angle, ready to be consulted the second something looked off.

When something went wrong — and on Apollo, things went wrong constantly — the response wasn't for one person to file a report and wait. The response was immediate. A controller saw a reading drift. They keyed their headset: "EECOM, I'm seeing a spike on fuel cell two." EECOM checked their own display, confirmed, and turned to the back room: "Back room, you seeing this?" The back room confirmed and started running calculations. EECOM came back to the flight director: "Flight, we have an anomaly on fuel cell two. Recommend we switch to the secondary." The flight director made the call. CAPCOM relayed it to the crew. The crew executed. The whole thing — from anomaly detected to resolution implemented — might take ninety seconds. And it involved four or five people, each one with a specific role, each one connected to the others by a headset and a shared sense that what they were doing mattered.

The stakes were the highest that had ever been. They were literally out of this world. A mission to not just attempt to leave Earth but actually do it with human beings on board — land them on another world out in space and then bring them back safely. Three lives sitting on top of a rocket, flying to a place no human had ever been, with no margin for error and no ability to call a timeout. Based on that, they had to have the highest level of teamwork, the clearest communication, and they had to execute perfectly as a team. And they did. Not because they were superhuman, but because they had built something that most teams never build: a culture of live interconnectedness.

Here's the part that I think about the most. Their teamwork wasn't driven by triggers, incidents, procedures, and mandated interconnectedness. It wasn't "when X happens, you must contact Y within Z minutes." That kind of procedural interconnectedness is what most companies have. It's what ticketing systems enforce. It's what escalation policies mandate. It works — sort of — but it's mechanical. It's a machine that routes information according to rules. It moves information from person to person, but it doesn't make people connected.

Mission Control wasn't that. Mission Control was a lifestyle of interconnectivity between teammates. The controllers weren't communicating because a rule told them to. They were communicating because they were in it together, in real time, watching the same data, sharing the same goal, and trusting that the person next to them — and the person in the back room they couldn't see — was as locked in as they were. The headset wasn't a tool they used when something went wrong. The headset was always on. The channel was always open. The connection was constant.

That's what QA feels like when it's working right. The headset is always on. The developer or another QA tester is one message away. You see something, you say something, they respond, you work it together. It's not always a trigger-based process. And when I work with coworkers who are similar to me, it's a live, continuous connection between people who are all looking at the same thing and all want it to be right asap.

Some companies and teams within companies are really good at this kind of interconnectedness in general. But where you sit in the company drives whether you get to be part of it more or less. Some roles are isolating by structure — you receive work, you do work, you hand off work. You ask permission more than you get to make decisions. QA tends to not be one of those roles more than other roles in a company. In the world of development, teams have to be more tightly interconnected to solve issues, create solutions, and give the public a great product. This is what birthed DevOps and QAOps. And QA sits at crucial spot in the system. You're connected to the developers because you're testing their code. You're connected to product because you're verifying their requirements. You're connected to support because you're preventing the tickets they'd otherwise receive. You're connected to the customer because you're the last person who stands between them and a broken feature.

You're part of the process and "project" to build or fix software. People who are part of projects always have the opportunity and ability to be more interconnected. Those who sit at the end of the line and are just receivers don't.

You Don't Just Report. You Solve.

While other roles like support get the comment or concern from the customer, test and validate whether it's a bug or not, and then pass it along to the development team to be solved, QA gets to be a part of the process to actually fix the issue.

But the reality of good QA — the part that makes it not just a job but something I genuinely love — is that when there is an issue or new feature that is going to be deployed to production soon, you get to be involved. When there is an "bug" reported by the customer, you don't just document it, write a ticket and move on. You see the solution come in from the developer, the PR (pull request), ready for testing and you get to jump in with your agent, see what the developer/his agent did and make sure it's all ready to go for the customer. As you run the different tests (some with your agent, others manually), you look at the new feature or bug fix from different angles. You reproduce it with different inputs. You use your agent to check the network tab and look at the console. You read the error message or update from your agent to see if it truly passes or not.

If needed, you give specific feedback to the developer, "I think I know what's happening. Can you check if the API is returning null when the field is empty? Because that's what it looks like from the response." And the developer checks, and you're right, or you're wrong but you've narrowed the search, and then together you're closer to the answer than either of you would have been alone. Then after another rewrite from his agent, PR request, and deployment to QA, you try again. And then you go to the developer and you don't say "this is broken, fix it." You say: "I think I know what's happening. Can you check if the API is returning null when the field is empty? Because that's what it looks like from the response." And the developer checks, and you're right, or you're wrong but you've narrowed the search, and now together you're closer to the answer than either of you would have been alone.

That's not just reporting. That's active solving. And being part of the solving process — not just the finding process — is what makes QA feel like real work instead of inspection work. You're interconnected not just in the sense that you're communicating with people, but in the sense that you're contributing to the resolution. Your investigation matters. Your hypothesis matters. Your ability to read a stack trace and say "I think the issue is in the serializer, not the controller" matters. You're not a gatekeeper. You're a teammate. And the developer knows it, because you just saved them thirty minutes of debugging by narrowing the problem before you even picked up the phone.

The Agent in the Loop

And then there's the part that has made QA more exciting than it has ever been in the history of software development. The part that makes me feel, every single day, like I'm working with the most advanced tool humanity has ever built.

Agentic AI.

In QA, you have a reason and a purpose to discover what agentic AI can do. You're not exploring AI as a novelty. You're not playing with it to see if it can write a poem or generate a picture. You have a job that needs doing — testing features, verifying fixes, running regression suites, checking integrations, monitoring dashboards — and you have an agent that can help you do that job in ways that weren't possible twelve months ago.

And the beautiful thing is that QA gives you the perfect laboratory for pushing the agent's boundaries. Every test is a new prompt. Every failure is a new investigation. Every integration is a new connection to figure out. You have a reason to ask: can the agent connect to more? Can it keep a larger context across multiple test cycles? Can it learn from the results of the last test and adjust its approach for the next one? Can it pull information from one platform, carry it to another, run a test, capture the results, and deliver them to the right place — all in one orchestrated flow?

Here's what that flow looks like in my daily work. I need to test a feature. I tell my agent what to look at the Monday board for the pulses that are assigned to me in the current Sprint. The agent connects to Monday.com to pull the pulse — the ticket description of the issue or the new feature requirements, the QA tests that need to be done, acceptance criteria, the context of what code was changed and why. It reads the pass requirements. Then it opens Playwright and navigates to the QA environment — logging in, navigating to the right page, interacting with the feature exactly as a user would. It runs the test steps. It opens Chrome DevTools to monitor the network requests, the console output, the DOM state. It checks whether the API calls are returning the right responses. It captures screenshots of the behavior. It compares the actual results against the acceptance criteria from Monday.

And then — here's the part that still gives me a thrill every time — it takes all of those results and writes them back to Monday.com. It updates the pulse with the test outcome, attaches the screenshots, logs the network traces, and flags any discrepancies between expected and actual behavior. If the test passed, the pulse gets a green status. If it failed, the pulse gets a red status with a detailed breakdown of what went wrong, what the agent observed, and a hypothesis about the root cause — all formatted and posted for the developer to read.

Monday. Playwright. Chrome DevTools. The company's software. API calls. Back to Monday. One continuous flow. One agent. One conductor.

It's like orchestrating a small band of musicians. Each platform is an instrument. Monday is the score — it tells you what to play. Playwright is the performance — it executes the piece. Chrome DevTools is the tuner — it tells you whether the notes are coming out right. The API is the rhythm section — it keeps everything in time. And Monday at the end is the audience — it receives the performance and records the review.

And I'm standing in front of all of it, baton in hand, telling each instrument when to come in, what to play, how loud, how soft, when to stop, when to go again.

From Switchboard Operator to Orchestra Conductor

I wrote recently about what it feels like to work with multiple agents — how it used to feel like being a switchboard operator, plugging and unplugging cords, routing information from one line to another, manually carrying outputs from one agent to the next. And that was true. For a while, that's exactly what it felt like. Copy from here, paste over there, ask for a summary, ask for a rewrite, carry the result somewhere else. The board was lit up and the calls were coming in and I was the operator.

But something has shifted. As the models have gotten better — as the agents have gotten smarter, faster, more capable of holding context across longer interactions — the feeling has changed. The token usage has decreased because the agents need less hand-holding to understand what I want. The pressure to be as efficient as possible — to craft the perfect prompt, to provide exactly the right context, to manage every micro-step — has started to reside. I spend less time figuring out what the agent can do and more time telling it what I need it to do. And that distinction sounds small, but it's the difference between operating a machine and conducting an orchestra.

As agents through OpenCode, Claude, and other platforms connect to more and more platforms — as the integrations deepen, as the context windows grow, as the models learn to navigate between tools without me manually carrying the output — the orchestration starts to flow. It's not choppy anymore. It's not "do this, stop, now do this, stop, now take that result and do this." It's "here's what I need. Here are the tools. Go." And the agent goes. It pulls from Monday, runs the test in Playwright, checks the network in DevTools, verifies the API, and writes the results back to Monday — and I watch it happen, and I intervene when I need to, and I adjust the baton when the music needs to go somewhere different.

I feel less like a switchboard operator and more like an orchestra conductor. And by being a QA tester — by being the person whose job it is to verify, to investigate, to push the product to its limits before it reaches the customer — I get the opportunity to conduct agents to do more and more complex things. Test more. Do more complex tests. Run scenarios that would take a human three hours to set up and execute, and do them in three minutes. And then do them again with different data. And then do them again with a different configuration. And then compare all the results across all the runs and tell me which configuration produces the most stable behavior.

That's not a checkbox. That's a symphony.

The Most Advanced Tool in the History of Humanity

I want to say this plainly, because I mean it literally: working with agents is like working with the most advanced tool we have in the history of humanity.

I'm not saying agents are the most advanced technology in history. I'm not making a claim about silicon or parameters or benchmark scores. I'm saying that as a tool — as something a person picks up and uses to do work they couldn't do without it — an agent is the most advanced tool I have ever encountered. Because it doesn't just extend my hands or my eyes or my memory, the way a hammer or a microscope or a notebook does. It extends my reach. It lets me be in Monday.com and Playwright and Chrome DevTools and the company's QA environment and the API layer — all at the same time, all in one flow, all orchestrated by me. It lets me test things I wouldn't have time to test. It lets me investigate things I wouldn't have the tools to investigate. It lets me connect things I wouldn't have the patience to connect manually.

And in QA, where the whole job is about investigating, identifying, and resolving — about being interconnected, about being part of the solution, about catching things before they reach the customer — that tool doesn't just make me faster. It makes me better. It lets me see more of the picture. It lets me run more tests. It lets me provide the developer with richer, more detailed, more actionable information about what's happening and why. It lets me be the teammate I want to be — the one who comes to the developer not just with "this is broken" but with "this is broken, here's why, here's the evidence, and here's what I think the fix is."

I would love to see how great companies — companies like JLP — are using agents to test and verify test results that lead to the revolutionary stuff that they do. I think about the scale at which a company like that operates, the complexity of the systems they're testing, the stakes of getting it wrong, and I think: if I can do what I'm doing at my scale, with my agent, at my desk — what are they doing? How are they orchestrating their agents across their testing pipelines? How are they using agents to verify results that feed into the kind of work that changes an industry? I don't know, but I'd love to see it. Because I get to do a version of that every day, on a much smaller scale, where I work now. And even at my scale, it's the most exciting work I've ever done.

Bottom Line

The job is the job of a QA tester: you are the last person who sees the product before the customer does. You are the person who sits with the developer and works the problem in real time in many cases. You are the person who investigates, identifies, and helps resolve — not in days, but in minutes. You are the junction point between development and delivery, between "we built it" and "we shipped it," between a feature that works in theory and a feature that works in the hands of a real person.

And now, you are the person who gets to conduct an orchestra of agents across a stage of platforms, pulling data and running tests and capturing results and delivering them to the right place, in one continuous flow, faster and more completely than any human could alone. You get to push the boundaries of what the most advanced tool in human history can do — not as an experiment, but as your job. You have a reason and a purpose to discover, to create new processes, to build testing and reporting methods that didn't exist before you sat down at your desk and picked up the baton.

Mission Control wasn't great because they had good procedures and a bunch of nice people who reached out when needed. They were great because they were connected — live, continuous, headset-on, in-it-together connected. They were great because they worked the problem as a team, in real time, each person bringing their piece to the solution. They brainstormed, strategized, bounced ideas off each other, and came up with high quality solutions. They were great because the stakes were the highest imaginable, and they rose to meet them by being more interconnected than any team had ever been.

QA testing feels like the closest I will ever get to Mission Control. The stakes aren't life and death — I know that. But the principle is the same. You see the data first. You communicate what you see. You work the problem together. You resolve it fast and thoroughly using the greatest tools available. And you ship something that works — something that's worthy of the people who use it — because you and your team and your agents were connected enough, and sharp enough, and thorough enough to catch everything before it mattered.