DEV Community: Alexandru A

How We Stopped Mixing Up Test Cases Across 5 Client Projects

Alexandru A — Sat, 12 Sep 2026 11:27:40 +0000

A typical week running QA for multiple clients looks something like this: Monday, a SaaS client needs results by Wednesday. Tuesday, an e-commerce client finds a checkout bug that needs same-day regression. Wednesday, a healthcare client uploads a new feature for next week's review. Three clients, three timelines, one QA team keeping all of it moving at once. If that rhythm sounds familiar, the actual challenge usually isn't the workload itself, it's keeping each client's context, test cases, and defects from blurring together while you context-switch between them all day.

We found one structural decision, not a new tool and not more process, that made the biggest difference in keeping all three engagements on track without any of them bleeding into each other. We wrote up the complete workflow in Managing Multiple Client QA Projects. Here's the short version.

One project, one client

The boundary that actually matters is the project itself: each client gets their own project, holding their scenarios, defects, and environments completely apart from anyone else's. There's no separate "client" object in Evaficy Smart Test, so a naming convention like "Acme Corp: Checkout" isn't just decoration, it's what actually lets your team recognize which project belongs to which client at a glance, whether that's scanning a project list or reading a message about a defect. Skip that discipline, or get inconsistent about it across the team, and projects blur together fast.

Roles don't leak between projects

This is the detail that made the real difference for us. Roles (Owner, Product Owner, Tech Lead, QA Engineer, Viewer) are set per project, not per account. The same person can be QA Engineer on one client's project and Tech Lead on another's, at the same time, with zero crossover between them.

In practice, that looks like this: your most experienced tester is a QA Engineer executing tests on your SaaS client's project on Monday, then spends Tuesday as the Tech Lead approving validation requests on your e-commerce client's project, then is back to QA Engineer for the healthcare client on Wednesday. Three different responsibilities, three different clients, same person, and none of those permissions bleed into a project they don't belong to.

That single fact changes how you staff engagements. You can assign each client the role structure that specific project needs, without spinning up a new account for someone or worrying that a permission granted on one project quietly carries over somewhere it shouldn't.

Know your ceiling before you say yes

Before taking on a fourth or fifth concurrent client, it's worth checking your actual capacity on two fronts: the practical kind (how much time your team genuinely has) and the platform kind (how many projects and team members your current plan supports). The second one is easy to overlook until it becomes a blocker mid-onboarding, so it's worth checking before the sales conversation, not during it. If you're already close to your plan's ceiling, upgrading ahead of time is a much smoother move than discovering the limit with a client waiting on you. Knowing both numbers ahead of time makes "can we take this client?" a much easier conversation than finding out the hard way mid-engagement.

The four-step loop that repeats for every client

The same loop runs for every client project, and that repetition is the point:

Kickoff: scope and access get defined, so everyone agrees upfront on what's in and what's out
Build: scenarios and test cases come together based on that agreed scope
Validate: a Tech Lead and Product Owner sign off before anything runs, catching gaps early
Execute: testing happens and results get delivered to the client

Because the loop is identical across clients, onboarding a new team member only means teaching it once. They can apply the same four steps to the next client project without relearning anything, and you can spot-check quality by asking the same questions at the same stage regardless of which client it's for.

Scope creep's one-line defense

New scope that shows up mid-engagement becomes its own scenario, not an edit to the one you already validated. That keeps the original scope's history intact and gives you a clean, honest record of what was actually agreed to versus what got added later, which matters the next time a client asks why an estimate changed.

This turns "can you also just check X while you're in there" from an invisible scope expansion into a visible, separately-tracked item. It doesn't stop clients from asking, and it shouldn't, since requirements genuinely evolve. What it does is make the extra work legible: your team can point to exactly what was added, when, and estimate it on its own terms instead of quietly absorbing it into the original timeline.

Takeaways

Project-per-client is a structural boundary, not a naming habit, and it's what actually keeps client data from crossing over.
Roles are set per project, so the same person can take on different responsibilities for different clients with zero crossover.
Check your real capacity, both team time and plan limits, before committing to a new client engagement.
New scope gets tracked as a new scenario, keeping the original agreement and the additions clearly separate.

None of this required new tooling on top of what we already used day to day, just a different way of structuring the same work. That's usually the more durable fix anyway: a decision about structure holds up better under deadline pressure than a habit does.

The full workflow, including plan limits, a real capacity-planning framework, and the complete kickoff-to-delivery handoff, is here: Managing Multiple Client QA Projects.

We Ran the Numbers: Manual vs. AI-Generated Test Cases (Real Cost Breakdown)

Alexandru A — Thu, 10 Sep 2026 07:32:55 +0000

Manual test case writing brings something valuable to every project: a QA engineer's full context and judgment on each individual case. AI-assisted generation brings something equally valuable: speed, producing a complete first draft in seconds instead of hours. Both approaches have real strengths, and most QA agencies end up using some blend of the two. What's less common is actually measuring that blend, so we wanted to know exactly how much time and cost each approach takes for the same scope of work, and where the line between them should sit.

We measured it on a real e-commerce checkout flow project (product selection, cart, payment, order confirmation) and wrote up the complete workflow in How QA Agencies Use AI Test Generation to Deliver Faster. Here's the short version: just the arithmetic.

Where the 30-34 hours go with manual testing

A checkout flow redesign is a well-scoped project. Here's where a QA engineer's time typically goes when writing test cases by hand for a project like this:

Reviewing requirements and acceptance criteria: 2 hours
Writing 50-100 test cases across happy paths, negative flows, edge cases, and boundary conditions: 16-20 hours
Reviewing and refining with the product owner: 4 hours
Executing tests and logging defects: 8 hours

That's 30-34 hours total, with 16-20 of them dedicated to writing test cases before execution even begins. Those hours buy something real: test cases shaped by product knowledge and judgment about what's likely to break.

The napkin math

At a fully-loaded QA engineer cost of $25/hour (a typical blended rate for a team based in Eastern Europe, for example), writing 50-100 test cases by hand costs $750-850 in labor. That's the investment in a thorough, well-considered first draft of your test suite.

An AI-assisted pass on the same scope works differently: about 30 minutes describing the feature, generation in seconds, then two hours reviewing and refining the output. Labor cost: roughly $150.

	Manual	AI-assisted
Time	16-20 hours	~2.5 hours
Cost	$750-850	~$150

Same scope. Same 50-100 test cases covering the same flows. An 18-hour, roughly $1,350 difference: time you can reallocate to execution, defect analysis, and deeper exploratory work.

That difference compounds well. If your agency runs five similar projects a year, that's roughly 90 hours and $6,750 in labor freed up for the work clients notice most: deeper exploratory testing, faster turnaround, or taking on an additional project without hiring anyone. It's a standing margin improvement on every project of similar shape going forward.

What each approach is best at

Manual test writing and AI generation aren't competing for the same job. Each is strongest in a different place.

Where AI-assisted generation excels:

Functional testing of well-defined features and forms
Regression testing after product updates
API and backend testing with consistent, rule-based scenarios
Happy paths, negative scenarios, and standard boundary conditions

Where manual QA judgment adds the most value:

Exploratory testing: finding the cases nobody thought to write down
UX and usability judgment calls
Complex workflows spanning multiple systems
Security, compliance, and accessibility testing

The strongest setup combines both. AI-assisted generation covers the structured, high-volume ground quickly, and the hours it frees up go straight into the exploratory and judgment-based testing that benefits most from a human. Teams getting the biggest margin benefit tend to be the ones who moved their QA engineers from writing to reviewing, then reinvested the extra hours into the testing that genuinely needs a person doing the thinking.

What clients actually respond to

Clients care about outcomes more than methodology. Whatever mix of manual and AI-assisted testing produces the result, what matters to a client is turnaround time, quality, and cost.

In practice, that means leading with the outcome works well: "We deliver test results in 48 hours instead of five business days, at the same quality." It keeps the conversation focused on what the client actually came for, regardless of which methods produced the result.

Try it in a week, not a quarter

You don't need to overhaul your process to see how this compares for your own team. Pick one feature you'd test this week anyway. Write the acceptance criteria the way you normally would. Generate half the test cases with AI and write the other half by hand, then have someone senior review both sets without knowing which is which. Compare time spent and defects found.

That's the whole pilot: a controlled comparison on real work you were already planning to do. It gives you your own numbers, on your own codebase, with your own team's actual review standards, which matters more than any published benchmark including this one.

Takeaways

Manual test case writing and AI-assisted generation each bring something different: judgment and context versus speed and volume.
Combining both, using AI for structured coverage and reinvesting the saved hours into exploratory and judgment-based testing, is where the real margin benefit shows up.
Clients respond to outcomes such as faster turnaround and consistent quality, whatever mix of methods produces them.

We go deeper on this in How QA Agencies Use AI Test Generation to Deliver Faster: the full breakdown of where the hybrid model pays off, how to introduce it to your own team, and a real 3-week pilot plan for testing it on your next client project.

How I Used AI Tools to Create a SaaS Demo Video as a Solo Developer

Alexandru A — Thu, 02 Jul 2026 16:11:21 +0000

Creating a product demo video for a SaaS launch sounds straightforward until you actually sit down to do it. As a solo developer launching Evaficy Smart Test on Product Hunt, I had no active video production setup, no marketing team, and no budget for professional editing. I did have some basic video editing knowledge from about ten years ago, enough to understand tracks, timelines, and how to import files — but nothing recent and nothing close to professional production experience. Here is how AI-assisted tools bridged that gap and made the entire process not just possible but genuinely good.

Starting with AI consultation

The first step was not picking up a camera or opening an editor. It was thinking through the structure. I consulted with Claude to build a script optimized specifically for a Product Hunt audience — short attention spans, technical viewers, and a 60 to 90 second sweet spot for demo videos. The script went through several iterations: adjusting the opening to lead with value rather than complaints about the problem space, trimming feature coverage to the three or four most impactful moments, and rewriting every sentence for AI voiceover pacing — shorter sentences, no ambiguous numbers, natural pause points between scenes.
The consultation also produced something I would not have thought of independently: splitting the recording into separate scene clips rather than one continuous screen recording. The reasoning was simple — if one scene needs a retake, you redo 15 seconds, not the entire video. This single decision saved significant time during editing.

Choosing the right tools for each job

A trap many developers fall into is reaching for the most powerful tool available rather than the most appropriate one. For screen recording, Windows Snipping Tool was genuinely sufficient. It captures at 1080p, exports clean MP4 files, and requires zero setup. No OBS configuration, no scene management, no learning curve. For a silent screen capture of a web application UI, it was exactly the right tool.
For AI voiceover I used ElevenLabs Text to Speech — the only part of this entire production where I spent any money, approximately 7 USD for the full script across all six scenes. The settings that produced natural calm narration suitable for a technical SaaS product:

Voice: Joseff Novak — Calm and Professional
Model: Eleven Multilingual v2
Speed: 0.98
Stability: 60%
Similarity Boost: 75%
Style: 0%
Speaker Boost: Enabled

The stability at 60% gave consistent delivery without sounding robotic, while the slightly reduced speed at 0.98 added natural breathing room between sentences. Generating each scene as a separate audio clip rather than one long file made timeline alignment in the editor significantly easier.

For editing I used DaVinci Resolve free version — no watermark, no length limit, full 1080p export at 30fps as H.264 MP4. My ten year old video editing knowledge was just enough to feel oriented in the interface: I understood what tracks were, how importing worked, and the general concept of a timeline. What I did not know — specifically how to add separate audio tracks and unlink video from its embedded silent audio — took about fifteen minutes of trial and error to figure out. The free version handled everything needed for a straightforward assembly edit without any paid features. The YouTube preset in the Deliver tab handled all the technical export settings automatically.

For hosting, YouTube was the natural choice — free, reliable, and dev.to renders YouTube links as embedded players automatically when you paste the URL on its own line.

The scene-by-scene approach in practice

The final video runs approximately 82 seconds across six scenes, each recorded separately against the actual product UI at app.evaficy.com:

Homepage hero section overview (8 seconds)
Projects and Scenarios view (12 seconds)
AI test case generation in action (15 seconds)
Test runs overview with step by step execution, pass/fail tracking, and the defect creation form (22 seconds — the most complex scene, intentionally given more time)
AI Risk Insights dashboard (13 seconds)
Sign-up and CTA screen (12 seconds)

The 22 second test runs scene is worth noting specifically. The initial script allocated 15 seconds but the feature complexity genuinely required more time to demonstrate meaningfully. Rather than rushing it, I extended that scene and adjusted the voiceover script accordingly. Having separate clips made this a simple timeline adjustment rather than a full re-record.

The result

What AI actually changed

The honest conclusion is not that AI replaced skill or effort — it is that AI compressed the learning curve and filled the gaps where inexperience or rustiness would have otherwise created a bottleneck. Script structure that would have taken hours of research came from a conversation. Voiceover that would have required hiring a narrator or recording myself as a non-native English speaker came from a text input and approximately 7 USD in ElevenLabs credits. Remembering how DaVinci Resolve's track system worked took minutes of guided trial and error rather than watching hours of tutorials.
The creative and technical decisions were still mine. AI handled the parts where a ten year gap in experience would have slowed everything down.
For solo developers building in public with no marketing budget, that compression matters. The total production cost was under 7 USD. The tools are good enough now that production quality is no longer gated behind budget, specialization, or an unbroken decade of keeping your skills current.

Have you created a demo video for your own product? What tools did you use and what would you do differently? Drop it in the comments.

Evaficy Smart Test is live on Product Hunt today if you are curious what I have been building:
Evaficy Smart Test on Product Hunt
Evaficy Smart Test

Chasing a Ghost: Debugging a Silent Google OAuth Failure in Production

Alexandru A — Thu, 02 Jul 2026 09:22:33 +0000

Yesterday I launched Evaficy Smart Test on Product Hunt — an AI-powered QA platform I've been building solo. Quiet launch, but that's not really what this post is about.

This morning I woke up to intermittent invalid_grant errors on Google Sign-In in production. No clear pattern. No reliable way to reproduce it by clicking around myself. Just the occasional 500, logged with no obvious trigger next to it.

Here's how I tracked it down — because the actual cause turned out to be something I wouldn't have guessed, and I suspect it's more common than people realize.

The symptom

Users occasionally hit a 500 error trying to sign in with Google. Not every time. Not for every user. No visible pattern in when it happened.

The stack trace pointed at passport-oauth2:

TokenError: Bad Request
    at OAuth2Strategy.parseErrorResponse
    at OAuth2Strategy._createOAuthError

Classic invalid_grant — Google rejecting an authorization code as invalid, expired, or already used.

The obvious suspects (all wrong)

My first instinct was double-invocation — somewhere, the same authorization code was probably being sent to Google twice. Common causes:

A router mounted twice (I actually found a comment in my own code from a past bug: // Bug fixed: was '/auth/google' (double prefix since router is mounted at /auth) — promising lead, right?)
A React useEffect firing twice, maybe due to StrictMode
The OAuth callback route being hit twice in the middleware chain I checked all three. All clean. The router was mounted exactly once. The frontend button did a plain window.location.href redirect — no React state, no effects anywhere near the callback. The middleware chain had no loop-back.

Dead ends, but useful ones — they narrowed the search.

The clue that mattered

I asked for the actual server logs instead of trying to reproduce the bug live (reproducing intermittent bugs by clicking around is a great way to burn an afternoon for nothing). One log entry stood out:

"url": "/auth/google/callback?iss=https%3A%2F%2Faccounts.google.com&code=...
&scope=email+profile+...&authuser=2&prompt=none"

prompt=none.

My actual "Continue with Google" button used prompt: 'select_account' — it always produces an interactive flow with a visible account picker. It would never generate a prompt=none callback. That single query parameter meant this request wasn't coming from a real click on my button at all. Something else was silently triggering Google auth in the background.

The actual cause

A quick grep through the frontend turned up this, still mounted at the app root:

<GoogleOAuthProvider clientId="...">
  <Authentication />
</GoogleOAuthProvider>

GoogleOAuthProvider is from @react-oauth/google — a different, client-side OAuth pattern than the one I was actually using. My real login flow was 100% server-side: browser redirect → Express → passport-google-oauth20 → session. Textbook, and it worked fine on its own.

But at some earlier point I'd started migrating toward the client-side flow, wired up the provider, wrote a useGoogleLogin hook — then abandoned it and commented the hook out. The provider, though, stayed mounted.

Here's the part that got me: commenting out the hook doesn't stop the provider from doing anything. GoogleOAuthProvider loads Google's Identity Services script the moment it renders, regardless of whether anything downstream actually consumes its context. That script can independently trigger a silent/background re-authentication check using the same client_id — completely decoupled from any button click. Since that client ID's redirect URI pointed at my real callback endpoint, the silent flow's (possibly stale or already-consumed) code was landing on my production auth route and getting rejected by Google as invalid_grant.

Dead code, alive side effects. The import was unused. The component it wrapped didn't need it. But the script it loaded was doing something the whole time.

The fix was one line of removal — dropping the provider wrapper entirely, since nothing in the active code path used it. I also hardened the callback handler itself, since TokenError was throwing before passport's failureRedirect logic could catch it, turning a normal auth failure into an unhandled 500:

router.get('/google/callback',
    (req, res, next) => {
        passport.authenticate('google', (err, user, info) => {
            if (err || !user) {
                return res.redirect(`${clientUrl}?auth_error=google`);
            }
            req.logIn(user, (loginErr) => {
                if (loginErr) return next(loginErr);
                next();
            });
        })(req, res, next);
    },
    (req, res) => { /* existing session logic */ }
);

Takeaways

Dead code isn't always inert. An unused import can still execute side effects the moment it's rendered/loaded — check what a component does on mount, not just whether anything reads its output.
A single unexplained query parameter can be the whole story. prompt=none was the one detail that ruled out every "obvious" theory and pointed straight at the real cause.
Logs before reproduction, when the bug is intermittent. I never had to manually trigger this bug once — the production logs had already recorded exactly the parameter I needed to diagnose it. If you're running Google OAuth alongside any client-side Google library (@react-oauth/google, google-one-tap, etc.) — even ones you think are unused — it's worth checking whether they're still mounted somewhere, quietly doing their own thing in the background.

Building Evaficy Smart Test, an AI-powered QA/test case generation platform, solo. Happy to answer questions about the debugging process or the product itself in the comments.

I built an AI-powered QA platform because manual testing tools haven't kept up — launching on Product Hunt today

Alexandru A — Wed, 01 Jul 2026 00:54:59 +0000

For the past year and a half, I've been building Evaficy Smart Test — a QA platform for manual testing teams that brings AI into the parts of the workflow that are still painfully manual: writing test cases, tracking validation, and figuring out what to test before a release.

We're launching on Product Hunt today, and I wanted to share the story behind it, plus some of the technical decisions along the way.

The problem
Most QA tooling falls into two buckets: traditional test management tools (think spreadsheets with extra steps), or newer AI tools that focus almost entirely on test automation — generating Selenium/Playwright scripts, self-healing locators, that kind of thing.
But a huge number of QA teams are still doing manual testing — and that segment hasn't gotten much attention from AI tooling. Writing comprehensive test cases, covering edge cases, tracking validation across reviewers, linking failed tests to defects — all of that is still mostly manual, repetitive work.

What I built
Evaficy Smart Test covers the full manual QA workflow:

Projects & Scenarios — organize test cases by project, with role-based access for Owners, POs, Tech Leads, and QA
AI test case generation — generate comprehensive test cases (including edge cases and negative scenarios) based on test type and affected page
Expert validation — PO/Tech Lead review workflow before test cases go live
Test runs — step-by-step execution with real-time pass/fail tracking
Defect tracking — inline defect logging with full traceability, one-click push to Jira
AI Risk Insights — scores scenarios by failure risk using historical test run data, so teams know where to focus before a release

Stack & technical notes
Built with React and Material UI on the frontend, with Stripe for subscription billing. Some of the more interesting build challenges:

Designing the AI generation flow to feel fast and controllable rather than a black box — letting users specify criteria (test type, affected page, custom fields) rather than just a free-text prompt
Building the validation workflow so AI-generated and manually-written test cases go through the same review process, since trust in test cases matters more than where they came from
Keeping the defect → Jira sync simple (one click, no field mapping headaches) since context-switching is the #1 complaint QA teams have about their current tools

Try it out
If you work in QA, or you're a dev/PM who's tired of testing falling through the cracks, I'd genuinely love your feedback.
🚀 We're live on Product Hunt today: Evaficy Smart Test - Launch Page
🔗 Try Evaficy Smart Test: Evaficy Smart Test

Happy to answer any questions about the build, the AI integration, or manual QA workflows in general — drop a comment below!

AI Made Me a Better Reviewer (The Hard Way)

Alexandru A — Mon, 13 Apr 2026 03:45:53 +0000

I build a SaaS QA platform. When AI coding assistants became good enough to trust with real work, I leaned in — and my velocity went up noticeably. Less boilerplate, faster feature implementation, fewer rabbit holes on syntax I'd forgotten.

But something shifted that I didn't expect. I wasn't writing less code and saving time. I was writing less code and reviewing more instead.

For a while I thought that was fine. Then one evening I pushed a feature involving Google SSO and suddenly users couldn't log in. Not "the Google button doesn't work" — I mean the entire sign-in and logout flow was broken. Silent. No obvious error.

I dug in. The AI had been working on routing middleware to serve pre-rendered pages for SEO. Reasonable task. What it also did, without flagging it, was intercept every GET request that looked like a browser navigation — including /auth/google. The OAuth redirect came back from Google, hit the middleware, got served the SPA shell instead, and the session was never established.

The fix was one line. The damage could have been significant if it had reached more users.

Here's what stayed with me: the feature it was building worked perfectly. The tests I ran against the new functionality passed. What broke was something adjacent — code I didn't ask it to touch, changed in a way that was internally logical but contextually wrong.

That's the real lesson about working with AI on production code. It doesn't lack skill. It lacks awareness of consequences outside the task boundary. It will solve the problem you gave it and not think twice about what it quietly rearranged to get there.

So now I review differently. I don't just check that the feature works. I read the diff the way I'd read a pull request from a smart junior developer who might not know what they don't know — looking for what changed that I didn't ask to change.

The trade-off is real: I write far less code than before, but I spend more time in review. Whether that's a net win depends on how careful you are. If you test properly and treat every AI output as a PR that needs approval, the productivity gain holds. If you trust the result because the happy path works, you're accumulating invisible risk.

I've caught CORS middleware generating 500 stack traces from bot traffic. A VAT field being HTML-encoded into / before storing in the database. A soft-delete flag silently stripped from a user object because the context mapper didn't know about the new field.

Each one was a sensible decision in isolation. Each one was wrong in context.

AI didn't make me a worse engineer. But it did make me a much more deliberate reviewer. That wasn't in the marketing material.

Do you have similar situations — where AI solved the task but broke something it wasn't supposed to touch? How do you review AI-generated code differently now?

How Do You Actually Integrate Jira and CI/CD Into a Real Web Application?

Alexandru A — Sat, 11 Apr 2026 11:31:24 +0000

When you first hear about integrating Jira with CI/CD, it often sounds abstract—like something happening “around” your application rather than inside it. But once you start building a real system, you quickly realize the challenge is very concrete:

How do you connect your codebase, pipelines, and issue tracking into one coherent flow?

Recently, while working on a quality assurance platform, I had to implement this integration from scratch—and the biggest lesson was this: integration is not a feature, it’s an architecture decision.

At the application level, everything starts with traceability. Your web app doesn’t directly “talk” to Jira in most cases, but your development workflow does. The first real bridge between your application and Jira is your version control strategy. By enforcing that every branch and commit references a Jira ticket, you create a consistent link between code and requirement. This small discipline allows Jira to automatically reflect development activity without any custom logic inside your application.

From there, CI/CD becomes the execution engine. Tools like Jenkins or GitHub Actions take over whenever code is pushed. They build your application, run validations, and determine whether the current state of the code is reliable. At this point, your application is indirectly part of the integration: every change to it triggers a pipeline that evaluates its health.

The real integration happens when you close the loop between pipelines and Jira. A CI/CD system that only runs builds is useful, but not enough. The moment it starts sending results back—marking tickets as ready, blocked, or completed—you move from automation to coordination. This is where your application lifecycle becomes visible to the entire team.

In practice, this often means configuring your pipeline to communicate with Jira through existing integrations or APIs. For example, after a successful build, a ticket can automatically move to a “Ready for Testing” state. If something fails, the same ticket can be flagged or annotated with the failure context. None of this requires your web application to change—but it fundamentally changes how your application is delivered and validated.

While implementing this for a QA-focused platform, I went a step further and introduced a few key capabilities to make the integration truly practical in real-world scenarios. One of them was personal access tokens, allowing users to securely authenticate API requests and integrate the platform with CI/CD pipelines, scripts, and internal tools—without exposing credentials. This made automation much safer and easier to adopt.

Another important piece was the ability to push defects directly to Jira, including detailed information and reproduction steps. Instead of manually copying bugs, test failures could be turned into structured Jira issues instantly, improving both speed and consistency in defect tracking.

Finally, I implemented CI/CD-triggered Test Runs, where pipelines can automatically create test runs as part of the delivery process. This ensures that every build is not just compiled, but also prepared for structured and traceable manual testing, fully connected back to Jira.

One subtle but important realization is that your application’s structure influences how effective this integration can be. If your project lacks clear environments, consistent build steps, or reliable test execution, even the best Jira integration will feel unreliable. In other words, CI/CD doesn’t fix chaos—it exposes it.

What truly defines a good integration is not how many tools you connect, but how well they communicate. A well-integrated setup creates a powerful effect: your Jira board becomes a real-time reflection of your application’s state. You no longer rely on manual updates or status meetings, because the system itself tells the story.

In the end, integrating Jira and CI/CD into a web application is not about embedding APIs into your frontend or backend. It’s about connecting the lifecycle around your application so tightly that every change is tracked, validated, and visible.

And once that happens, your application is no longer just code—it becomes part of a system that continuously proves its own quality.

So the real question is not whether you can integrate Jira and CI/CD…

…but whether your application lifecycle is structured well enough to support it.

What happens when you give an AI your acceptance criteria and ask it to write test cases?

Alexandru A — Mon, 06 Apr 2026 06:13:08 +0000

After years of building frontend applications across e-health and e-learning products, I've sat in enough sprint reviews to notice a pattern: QA test cases are written the same way every time. Happy path first, a handful of negative cases if the deadline allows, edge cases if the tester has seen that bug before.

The process is repetitive, experience-dependent, and the first thing to get cut when a release is running late.

So I started experimenting — feeding acceptance criteria directly to an AI and asking for a complete test suite. Here's an honest account of what works, what doesn't, and what it actually changes about the process.

What the AI gets right immediately

The output quality on structured coverage is genuinely impressive. Given clear acceptance criteria, the AI will produce happy path cases, negative scenarios, boundary conditions, and precondition states faster than any manual process — and it won't skip the boring ones.

It also structures the output consistently: steps, expected results, preconditions. That consistency alone has value when you're maintaining a growing test library across releases.

Where it falls short

The AI has no knowledge of your system beyond what you give it. It doesn't know that your application handles an unauthenticated empty cart differently from an authenticated one, or that a particular field has a known edge case from three sprints ago.

More critically: vague acceptance criteria produce vague test cases. With a human tester, ambiguity triggers a question. With an AI, it triggers a confident but incorrect assumption. If your requirements only describe the happy path, the generated test suite will skew heavily toward the happy path.

What actually determines the output quality

After enough iterations, the pattern is consistent: the quality of the generated tests is almost entirely determined by the quality of the input. A few things that made a measurable difference:

Write constraints explicitly. "The form should validate correctly" is not a requirement. "The email field must reject inputs without an @ symbol and a valid domain" is.
Include failure conditions in your acceptance criteria. If you only document what should succeed, the AI will generate tests for success.
Specify the user role and context. "As an admin" and "as a guest" produce meaningfully different test suites for the same feature.
Add environment context. First-time user vs returning user, mobile vs desktop, authenticated vs unauthenticated — these details shape coverage significantly.
An honest assessment

AI doesn't replace a QA engineer. It replaces the first draft.

A good tester still needs to review the output, discard cases that don't apply to the actual system, and add scenarios based on knowledge no requirements document captures. That judgment isn't going away.

But the shift from writing to reviewing is more significant than it sounds. Starting with 80% of the test suite already structured means your QA effort goes toward the cases that actually require expertise — the ones that come from understanding the system, not from reading the spec.

That's a different kind of QA work. Arguably a more valuable one.

I cover this in more depth in a free QA handbook — link in my profile if you're interested.

Has anyone else been experimenting with AI-generated test cases? Curious whether the input quality pattern holds across different approaches — and what you've found the AI consistently gets wrong.