Subject matter expert:
Victor Olkhovskyi
Manual/Automation QA Engineer at Kindgeek
There is a moment in every fintech QA automation effort when the tests are ready and the infrastructure to run them is still pending.
The suite exists. It validates transaction flows end-to-end, catches breaking changes across microservices, and produces clear results on the automation engineer’s machine. Nobody else ever sees those results. The pipeline that would deliver them to the wider team has yet to be configured.
On a MiCAR-regulated crypto-fiat platform, we decided to act. By applying AI in QA automation to bridge a specific technology gap, we built production-grade GitHub Actions pipelines from the QA side: daily scheduled runs, structured Slack reporting, and conditional execution logic. DevOps reviewed and approved the result in a two-hour session rather than a multi-week build.
This article covers how we did it, what we learned, and where AI in QA automation genuinely delivers value.
Content:
- Why QA Automation Gets Stuck in Fintech Teams
- How We Applied AI in QA Automation to Build Production-Grade CI/CD Pipelines
- What the AI-Assisted QA Automation Pipeline Actually Delivered
- Where AI in QA Testing Delivers and Where It Has Limits
- Beyond Pipelines: Other High-Value Uses of AI in QA Automation
- Lessons From Applying AI in QA Testing on a Live Fintech Project
- How Fintech Teams Can Start Implementing AI in QA Automation
- Conclusion
Why QA Automation Gets Stuck in Fintech Teams
The Pipeline Bottleneck Most Teams Accept
The pattern repeats across fintech engineering teams: an automation engineer writes a capable test suite, runs it manually a few times, and then watches it sit idle because the CI/CD pipeline to make it a shared daily signal has yet to be configured.
This is a structural constraint. Building reliable pipelines for test automation takes time and specific platform knowledge, and in most fintech teams, the person with both is the DevOps engineer, who is already committed to higher-priority work.
The typical response is to wait. File a ticket. Raise it at standup. Wait longer. Eventually, the pipeline gets built weeks or months later, and the team retroactively starts extracting value from automation they wrote long ago.
When DevOps Priorities Push QA Infrastructure to the Backlog
On our project, the DevOps engineer was doing exactly what he should have been doing: securing production infrastructure for a platform handling digital asset transactions under regulatory oversight, managing deployment pipelines for the development team, and keeping live environments stable.
A test runner for QA was correctly further down the priority list. This reflects how most fintech engineering teams actually operate. Infrastructure and security take precedence. QA automation pipelines wait.
The question we asked was: does it have to be this way?
How We Applied AI in QA Automation to Build Production-Grade CI/CD Pipelines
Translating CI/CD Knowledge Across Platforms with AI
Our lead QA automation engineer had built CI/CD pipelines for test frameworks on three previous projects, all on Jenkins. He understood the architecture well: scheduled triggers, conditional execution paths, structured Slack notifications with pass/fail breakdowns and change attribution, and failure handling that routes differently based on test type and severity.
He knew exactly what a finished pipeline looked like. His gap was fluency in GitHub Actions, the CI/CD platform this project used: different syntax, a different configuration model, a different ecosystem of marketplace actions.
This is a very specific engineering problem, and one where AI in QA automation is genuinely effective. You understand the domain deeply. You know the target architecture. You can evaluate whether an output is correct. What you are missing is familiarity with one platform’s idioms. AI excels at exactly this kind of translation: describe what the pipeline needs to do, receive platform-specific implementation, review against your mental model, iterate.
Our engineer used Augment Code and built the pipeline across several focused sessions. He described specific behaviors, reviewed every block of generated YAML, and made judgment calls at each step about what actually fit the project’s requirements.
What Made AI Effective Here: Adjacent Expertise
The concept that kept coming up in our internal review of this process was adjacent expertise. Our engineer had full CI/CD knowledge; what he lacked was GitHub Actions syntax. That distinction matters enormously for how AI in QA testing can be used responsibly.
When someone with deep pipeline architecture experience uses AI to generate configuration files, they can evaluate the output. When the generated YAML contained a logic error, our engineer caught it, because he knew what correct pipeline behavior looked like and could recognize when the output would fall short.
The reverse situation is materially different. If someone with no CI/CD experience on any platform attempted the same approach, the AI would still produce something. It might even run. Yet that engineer would have no frame of reference to evaluate whether the notification logic handled edge cases correctly, whether the conditional execution was robust under failure conditions, or whether the overall design was appropriate for production use.
What the AI-Assisted QA Automation Pipeline Actually Delivered
Daily Scheduled Test Runs
What we call a Platinum Journey test suite, a focused set of 5-10 end-to-end tests covering the platform’s core user journeys (account creation, account linking, send, receive, swap, and top-up), now runs every morning on a scheduled trigger. No manual intervention. No dependency on anyone remembering.
The design principle behind Platinum Journey was deliberate restraint: targeted coverage rather than exhaustive coverage, structured as a daily stability signal. When it passes, core transaction flows are intact. When it fails, something changed and the team finds out before users do.
On one occasion before the pipeline existed, a backend developer added new mandatory fields to the onboarding endpoint. Platinum Journey failed immediately with a 400 error, surfacing that the frontend had yet to implement the corresponding changes. The issue was caught ahead of deployment. That is the value the suite was designed to deliver, and it delivers it consistently only when running automatically.
Structured Slack Notifications That Engineers Actually Use
The Slack integration goes beyond a basic webhook. Each notification includes which specific tests passed and which failed, who pushed the last code changes before the run, and direct links to detailed reports in the CI/CD dashboard.
The engineering team sees automation results where they already work, rather than in a dashboard that only gets opened when something is visibly broken, a design principle that holds at any scale. Before the pipeline, test results required a conversation: ‘Hey, did you run the tests?’ After the pipeline, they became a shared signal, visible and passive, part of the daily workflow. Automation shifted from the QA team’s private concern to part of the engineering team’s shared infrastructure.
Conditional Execution Logic Matched to Test Purpose
Different test suites run under different conditions. Platinum Journey executes daily as the core stability canary. Service-level suites trigger on specific deployment events when deeper coverage is needed. Failure handling routes differently based on test type and severity: a Platinum Journey failure triggers a different response than an edge-case failure in a service-level suite.
This conditional logic is what separates a production-grade CI/CD setup from a basic scheduled runner. Building it correctly required the engineer’s architectural judgment at every step; AI supplied the implementation velocity.
Where AI in QA Testing Delivers and Where It Has Limits
AI as a Force Multiplier for Experienced Engineers
AI in QA testing delivers the clearest value as an accelerant for engineers who already have domain expertise. On our project, beyond the pipeline build, this included:
- Refactoring endpoint definitions across 30+ service classes into a centralized registry
- Generating data providers from a Swagger specification
- Replacing hardcoded strings with Java enums across a 900-endpoint project
- Post-writing review passes that surface naming inconsistencies and missing test coverage
The engineer provides architectural intent and domain context. AI provides implementation velocity. Under sprint pressure, this means code quality holds up better: the fixes you would make given more time actually get made.
Why Domain Knowledge Remains Essential
Writing a meaningful test for a MiCAR-compliant custody flow, a multi-party cross-border transaction, or a reconciliation process spanning three payment processors requires deep understanding of the business domain, regulatory context, data flows, and integration behavior. Human expertise is essential here.
AI lacks inherent understanding of why a system behaves differently for a German customer versus a UK customer. Without that context provided explicitly, it may adjust the logic based on patterns that look reasonable to a language model but contradict the actual business requirement.
The Risk of Treating AI as a Substitute for CI/CD Fundamentals
AI will generate a CI/CD pipeline for someone who has yet to build one. It may even run without errors. Producing something production-grade, however, requires the ability to evaluate whether the output is correct, and that ability comes from experience rather than from the quality of the prompt.
AI still delivers something basic when you lack deep experience and you will stay unblocked. But building something production-grade requires knowing what good looks like.
— Victor Olkhovskyi, Manual/Automation QA Engineer at Kindgeek
Our recommendation: build a working understanding of CI/CD fundamentals before using AI to accelerate implementation. The two are distinct capabilities, and treating them as equivalent leads to pipelines that appear functional but fail in the edge cases that matter.
Beyond Pipelines: Other High-Value Uses of AI in QA Automation
Framework Refactoring at Scale
Migrating all endpoint path definitions into a centralized registry, which is what we did on this project, would have taken hours of manual copy-paste work with predictable human error. AI completed it consistently and quickly. The resulting registry enabled automated coverage tracking: comparing which endpoints had test coverage against the full Swagger spec to produce a defensible, data-based picture of coverage gaps.
Structural refactoring is where AI in QA automation is at its strongest. The target state is well-defined. The engineer understands the architecture. The output is verifiable. The manual execution is tedious. AI removes the tedium while the engineer retains architectural control.
Measuring Test Coverage Through Endpoint Registries
Once the centralized registry existed, coverage analysis became a data problem rather than an estimation exercise. The team could generate reports showing exactly which endpoints had automated test coverage and which were still manual, giving engineering leadership a factual basis for prioritizing new test development.
This kind of structured visibility into automation investment is difficult to build manually, particularly as the API surface grows across microservices. Building it with AI assistance made it practical enough to actually ship.
Code Quality and Framework Standardization Between Sprints
We used AI for code quality passes between sprint cycles: review runs that catch the things engineers would address with more bandwidth. Hardcoded strings that should be Java enums. Missing data providers for field validation tests. Inconsistent method naming that accumulates across multiple sprints without a dedicated cleanup cycle.
Unglamorous as these tasks are, they are the maintenance work that keeps test frameworks manageable as they scale. AI makes them practical to do on a consistent basis, and consistency is what prevents the framework sprawl that leads to expensive rewrites later.
Lessons From Applying AI in QA Testing on a Live Fintech Project
AI Amplifies What You Already Know
The clearest conclusion from this project: a senior engineer with AI moves significantly faster. A junior engineer with AI is still at a junior level, with better autocomplete. The judgment that makes AI-assisted output safe for production comes from the engineer.
This distinction gets lost in many AI-in-engineering discussions. AI in QA testing is a velocity multiplier for existing capability. Using it as a capability generator leads to pipelines, tests, and frameworks that look credible but fail in ways the team is ill-equipped to diagnose.
Build the Infrastructure Before Expanding Test Coverage
AI’s clearest value in automation engineering is in pipelines, reporting, boilerplate generation, and refactoring: tasks with clearly verifiable outputs where the engineer can confirm correctness. This is the right place to start. Test logic for complex fintech flows should be written by engineers with domain knowledge, with AI in a supporting role.
Getting the infrastructure right first also creates compounding returns. Once the Platinum Journey pipeline was operational, extending it for additional service-level suites became a configuration task rather than a construction effort. The infrastructure was in place; adding a new suite meant adding a workflow file rather than filing a DevOps ticket and waiting three sprints.
Treat Every AI-Generated Output as a First Draft
On this project, AI renamed an endpoint from getAddress to getAddresses because the plural form looked more appropriate. It invented request fields absent from the API. It made assumptions about business logic based on naming patterns rather than actual system behavior.
We caught these in review because the engineer knew what the system actually did. Every AI-generated output requires genuine code review. That holds especially in fintech environments where incorrect test infrastructure produces false confidence rather than genuine quality signal.
How Fintech Teams Can Start Implementing AI in QA Automation
Start With Infrastructure and Verifiable Tasks
CI/CD pipeline configuration, reporting setup, boilerplate generation, and framework refactoring are the right entry points for AI in QA automation rather than complex test logic for regulated business flows. These tasks share a key property: the engineer can define the target state clearly and verify whether the output matches it.
Starting here builds practical intuition for where AI helps and where it requires more guidance. It also produces immediate, measurable value: pipelines that run, reports that reach the right people, frameworks that are easier to maintain.
Bring Clear Architectural Intent to Every Interaction
The engineers who get the most value from AI are those who can describe, in precise terms, what they want the system to do. Architectural intent, the ‘what’ and ‘why’, must come from you. AI supplies the ‘how’ in a specific technology’s syntax. The less clear your intent, the less useful the output.
On our project, this meant specifying exact trigger conditions, notification content, failure routing behavior, and execution order before generating any configuration. The AI’s job was translation; the design remained entirely with the engineer.
Build Review Into Every AI-Assisted Workflow
Establish code review as a mandatory step in any AI-assisted development process, a genuine review against your understanding of correct behavior rather than a cursory approval. The engineer remains responsible for every line that reaches production, regardless of how it was generated.
This is particularly important in fintech QA environments, where incorrect test infrastructure can actively obscure bugs by producing false passes. Thorough review is the control that keeps AI-assisted output trustworthy.
Conclusion
If your test automation is sitting idle because the CI/CD pipeline has yet to be configured, and you have experience building pipelines on any platform, there is a clear path forward. AI in QA automation can bridge the technology gap between the architecture you understand and the platform syntax you are learning.
The conditions for this to work well are straightforward: you know what a production-grade result looks like, you review every AI output against that standard, and you build the infrastructure because you understand it, with AI accelerating the execution.
The tests you have already written are an asset generating zero returns until they run automatically, produce visible results, and reach the people who need to act on them. There is a reason teams that delay automation tend to pay for it twice, and it has less to do with engineering hours than with the context that gets lost in the meantime. The infrastructure to change that is now within reach of the QA team itself.
Running test automation that the wider team never sees?
Contact Kindgeek, and we will help you build the way out.
Contact usWhat is AI in QA automation and how does it work in practice?
AI in QA automation refers to using AI tools to accelerate or support quality assurance engineering tasks: CI/CD pipeline configuration, test framework refactoring, code quality review, data generation, and coverage analysis. In practice, the engineer provides domain expertise and architectural intent, while AI generates implementation in a specific technology’s syntax. This works most reliably when the engineer has enough knowledge to evaluate whether the AI’s output is correct. It multiplies the output of engineers who already have expertise rather than substituting for it.
Can AI write test cases for complex fintech applications?
AI can scaffold test structure and generate boilerplate, but writing meaningful test cases for fintech flows requires domain knowledge that AI does not inherently possess. Regulatory compliance checks, multi-party transactions, and reconciliation processes spanning multiple integrations all depend on business context the engineer must supply. AI in QA testing is most effective as a collaborator on well-defined tasks rather than as an autonomous author of logic involving regulatory or financial precision.
What are the biggest risks of using AI in QA testing without the right expertise?
The primary risk is accepting AI-generated output without sufficient review. AI will produce plausible-looking code that can be subtly wrong: inventing API fields that are absent from the spec, applying naming conventions from one context incorrectly to another, or making assumptions about business logic based on patterns. A secondary risk is using AI as a substitute for foundational knowledge. Without prior CI/CD experience, an engineer will be unable to evaluate whether the generated pipeline is production-grade, which makes the gap invisible rather than closed.
How does AI help with CI/CD pipeline setup for test automation?
AI is particularly effective for translating CI/CD knowledge across platforms, for example from Jenkins to GitHub Actions. The engineer contributes architectural intent and evaluation capability; AI contributes platform-specific syntax and implementation speed. This works because the engineer can recognize when the output is wrong, which is the essential condition for AI-assisted development to produce reliable results rather than only plausible-looking ones.
What types of fintech QA work are best suited for AI assistance?
The highest-value applications of AI in QA automation tend to be: CI/CD pipeline configuration and optimization, framework refactoring and code standardization across large test suites, automated coverage analysis built from API specifications, notification setup, data provider generation, and post-writing code quality reviews. These tasks share a common property: the target state is well-defined and the output is verifiable. Complex test logic for regulated workflows is better handled by engineers with domain expertise, with AI supporting specific, bounded tasks.