Articles & News about QA

Subject matter expert: Victor OlkhovskyiManual/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. ADJACENT EXPERTISE — WHERE AI BRIDGES THE GAP Venn diagram: CI/CD Architecture Knowledge overlaps with GitHub Actions Syntax, with AI bridging the gap in the intersection CI/CD architecture knowledge Jenkins experience Pipeline logic Notification patterns GitHub Actions syntax YAML configuration Marketplace actions Workflow triggers Where AI bridges the gap Our engineer had this · AI translated between them · This project used this 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. CI/CD PIPELINE — THREE-COMPONENT SETUP 1 Daily trigger Platinum Journey runs every morning on a scheduled trigger. No manual intervention, no dependency on anyone remembering to run it. Scheduled daily No manual trigger Platinum Journey suite Delivers: a consistent daily stability signal without any human action required 2 Conditional logic Different test suites execute under different conditions. Failure handling routes by test type and severity: a Platinum Journey failure is treated differently from a service-level edge case. Routes by test type Routes by severity level Platinum vs. service suites Separates: core transaction failures from isolated edge cases, so the team knows exactly how to respond 3 Slack notification Results delivered where the team already works with enough detail to act without opening a separate dashboard. Automation results become a shared engineering signal, not a QA-only concern. Pass/fail breakdown Last commit author Full report link Delivers: shared visibility across the engineering team — passive, daily, no dashboard-checking required 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 us

QA

AI in QA Automation: How We Built Fintech CI/CD Pipelines Without Waiting for DevOps

How We Went from Quarterly Releases to Weekly CI/CD in a Regulated Fintech

Automation-First: Why We Write Tests Before Code Ships (and Why It Saves Weeks)

The 900-Endpoint Problem: Why Starting Automation Late Costs You Double

Latest posts

Top 10 Mistakes Fintech Startups Make When Building an MVP [+ Solutions]

AI in QA Automation: How We Built Fintech CI/CD Pipelines Without Waiting for DevOps

Top 10 Fintech Software Development Companies in 2026

Popular

Ultimate Guide on Financial Management for Small Businesses

What is BitClout: a new big player or..? Thoughts on the new social network with its own cryptocurrency

How to Develop a Hospital Management System

AI in Fintech: 4 ways AI impacts the financial industry

About

Subscribe

STAND WITH UKRAINE

What you can do

QA

Latest posts

Popular

Subscribe and Follow

About

Subscribe