The Invisible QA Work That Prevents Expensive Failures

There’s a lot that goes into each project that we do here in Enlighten, but not everything is seen by every member of the team, much less the clients. Our very own Dimithri Wellage, a test analyst at Enlighten, sums it up best: “Clients only see the finished build. What they don't see is the work that happens before a single test case is even written. It’s the days spent reading requirements, planning, and setting things up so that testing, when it starts, actually catches what matters." 

But that's where the real work starts. That's where you decide whether the next six months go smoothly or become a nightmare of reworks and delays. 

We wanted to explore the work she does, so we sat down, had a chat, and found out that it’s not really complicated. It's just disciplined. And it works. 

Start with a Team, Not a Brief 

Every new project begins with a kickoff that's carefully structured.

"A good kickoff has the right people in the room. Developers, testers, BA, PM, designers, and usually the client lead," Dimithri explains. "The PM sets the structure clearly upfront: introductions, scope review, timeline, meeting cadences." 

But it's not just logistics. Real alignment happens when the team understands what matters. On one project, a client stakeholder brought clarity that shaped everything. She adds. "That kind of clarity from the client side tells you a lot about what will matter in testing. It’s not just whether features work, but whether they're built in a way that holds up." 

For Dimithri, the kickoff is where her role becomes visible. And while the team settles into alignment, something critical happens: the requirements get read. Really read. 

Read Like You're the User 

"A developer reads requirements to understand what to build,” she adds. “I read them as a sceptical end user, like asking what this product actually promises, who relies on it and what for, and where the gaps are." 

This reading also serves as something of a preventive measure instead of finding holes in someone else’s work. She uses a video autoplay issue as an example where she noticed that a Gherkin scenario for video autoplay was missing a key condition. It was stated in the acceptance criteria, but hadn't been carried through into the Gherkin. She uses this opportunity to ask different questions to the rest of the team so they can identify if anything’s missing, together. 

There’s also the 24-gap discovery, in which she went through an entire BRD acceptance criteria against the available Gherkins. She used Claude to help with the analysis and identified 24 gaps, hence the name. “Some were missing scenarios entirely, some were partial, and a couple needed BA clarification before I could proceed,” Dimithri added. 

And then there are instances where gaps don't exist in documents at all. In moments like these, it’s where a test analyst can step in, create the proper documentation, and fill in the gaps. 

To clarify, these aren’t criticisms as the documents were thorough. Dimithri added, “A test analyst reads the same documents as the rest of the team but asks different questions. Sometimes that surfaces things worth discussing as a team before the build starts. When something isn't documented yet, like a set of rules the whole team needs to follow, the test analyst steps in and creates it. That kind of early groundwork saves time and confusion later for everyone from developers to testers and the client.” 

And as the backlog takes shape, the team makes a critical move: they align on what every column actually means. 

Setting Up the Board 

Most of the projects we do, like customer software development, live in Azure DevOps from day one. Some that don’t are managed through a manual setup depending on the project. But in cases where the projects are, your team gets full visibility into progress, status, and what's actually being built. No hidden spreadsheets or guesswork about where things stand. Though that visibility only works if everyone agrees on what each column means. 

"Ready for Testing" means different things to different people. Though before it moves into “Ready,” a test analyst usually expects the developer to have done basic unit testing to check the function actually works. The expectation is that builds need to be ensured to work before it’s handed off. 

Real velocity comes from real numbers, not wishes. Most teams guess their velocity and adjust by Sprint 2. To address that, Enlighten builds it from what they've actually shipped. 

"We don't slot every ticket into a specific sprint upfront. Most tickets live in a prioritised backlog and get pulled into sprints as we go. Only anchor tickets, the ones tied to known milestones, dependencies, or client commitments, get pre-slotted. Real velocity replaces guessed velocity after the first couple of sprints," she explains further. 

As Dimithri reads and the team aligns, a new tool has changed the pace: Claude AI, integrated directly into Azure DevOps. 

AI as a Partner, Not a Replacement 

Claude AI has become part of Dimithri's workflow. It reads work items, linked user stories, acceptance criteria, and Gherkin scenarios straight from ADO. It eliminated copy-pasting between tools and context-switching, which is part of how Enlighten brings AI development services into delivery workflows. 

Here, the work splits into two phases. At the start of a project, Claude helps build the testing foundation. Dimithri uses it to generate test plans and test cases, including steps, which she adds directly to the ADO board.  

During testing, Claude helps structure bug reports. When something fails, she shares the screenshot alongside the acceptance criteria and Gherkin scenarios, and Claude drafts a structured bug report. This saves time on the mechanical side of bug reporting and ensures nothing important gets left out. 

But here's what's critical: Claude doesn't replace thinking. Instead, it clears boilerplate, so thinking has room to happen. "Claude is reading the documents, the work items, the acceptance criteria, and the Gherkin scenarios. But it doesn't know the conversation that shifted direction in the kickoff, or what the BA mentioned offhand that isn't written down anywhere. Context that lives in people rather than documents is still entirely on me," she explained. 

Every test case Claude generates gets reviewed before it goes on the board. Every bug report it drafts gets Dimithri's eyes on it. And clarifications that need a conversation with the BA aren't something Claude can resolve. This part requires a human call on intent, and the tool accelerates the routine work so the human work can be deeper. 

Then comes the step that ties everything together: backlog refinement. 

Where It All Converges 

Backlog refinement is where developers, testers, BAs, PMs, and often the client walk through upcoming stories together before anyone starts building. It's not a read-through, though; it's where assumptions get tested out loud. 

Real things get caught here that would be expensive later. On one project, the team used refinement to confirm the media upload limit before development started. That one conversation meant everyone built and tested to the same number from day one. That one conversation ensures no rework or surprise comes later. 

On another project, a whole chain of decisions around sold listing visibility came up, like how long listings stay visible, whether photos stay up, and what the experience looks like for someone on a phone in a rural area. None of these was gaps exactly. They were implementation decisions that needed the client and dev team in the same room before anyone wrote code. 

The cost of delay in QA is straightforward. "A question raised before the build starts costs a conversation. The same question raised after the build costs a rework. The same question raised in UAT costs a release," she added.  

Every question raised in refinement is a question that doesn't have to be raised in UAT, where the cost of answering it is exponentially higher. At Enlighten, every testing hour is tracked and billable. That discipline forces the right question: Are these hours landing where they create the most value?  

The answer is yes, as refinement is done all throughout each project. It may happen early, but it’s standard agile practice and discipline that the team continuously walks through upcoming work together to sharpen every detail before anyone picks it up. And that same accountability that runs through project delivery carries through to managed services support after launch. 

This discipline is what separates good testing from reactive testing. It's what allows testing to work as a continuous function rather than a checkpoint. And it fundamentally changes what a test analyst actually does from day one. 

Ask the Right Question About Your Next Project 

When you're planning your next software project, ask your team the right question. Not "how do you test?" but "what do you do before the testing starts?" 

At Enlighten, quality isn't a gate at the end of the project. It's built into how teams run kickoffs, how they read requirements, how they set up their boards, how they run refinement, and how they test. Every one of those hours is accounted for. It’s tracked, budgeted, and spent where it creates the most value. 

Dimithri said it best: "Good QA is decided long before anyone clicks Pass or Fail." But it doesn't stop at the script. It's the discipline that runs through the entire delivery, making the visible testing work because the invisible work was done right. 

Talk to our team about how we approach your project from day one and why that first week matters more than you think.