AI QA specialist: I design AI-assisted QA decision workflows
I run a founder-led AI QA services business. I design and implement workflows that help engineering teams answer: "What should we test and why?" before they run full regression.
I combine more than ten years of quality engineering experience with test automation, backend systems, APIs, CI/CD and agentic workflows. I treat AI as part of a controlled engineering process - not as an impressive demo disconnected from how a team delivers software.
From code change to QA decision
Before meaningful testing begins, QA often has to manually combine information from the ticket, pull request, code diff, repository and pipeline. This work is repetitive, dependent on individual experience and largely invisible in test-execution reports.
I design workflows that turn this context into an actionable QA Brief. It can include the change summary, affected components and flows, risks, edge cases, suggested test scope, coverage gaps and questions requiring clarification.
The result appears where the team already works - for example, on the pull request or in the delivery pipeline - rather than creating another isolated QA system.
I wrote about this context-gathering cost in the hidden tax on every pull request. When CI adds doubt instead of a clear signal, the same team spends attention on triage. That is the subject of noisy CI.
The same way of working can extend to related QA workflows when they fit your process: CI-native AI QA, test-result intelligence and flaky-test triage, QA agent evaluation, API and backend test automation, and risk-based quality gates. I work with .NET, TypeScript, Playwright, Azure and existing CI/CD.
How I work
I design these workflows around:
- evidence-backed recommendations;
- explicit uncertainty;
- human review and final human decisions;
- least-privilege access;
- integration with existing Git, Jira and CI/CD tooling;
- evaluation of output quality and usefulness;
- no autonomous approval or silent actions.
I do not sell "magic AI," autonomous replacement of QA, or test generation as an end in itself.
Experience I bring
I have worked in quality engineering since 2015, focusing on backend systems, APIs, integrations and automation in CI/CD. I have built test frameworks from scratch, worked as a QA Lead, mentored engineers and taught future QA professionals.
My experience includes energy, e-commerce, business intelligence, travel and security systems. My strongest technical areas include .NET, Azure, C#, TypeScript, Playwright, Docker, API testing and distributed systems.
Selected experience
Technologies and tools
- C#
- .NET
- API testing
- Docker
- CircleCI
- CI/CD
- Git
- Azure Service Bus
- WireMock.NET
- SQL
- xUnit
- NUnit
- Verification process for .NET services on Docker: from the API contract and dependencies, through system and integration tests, to suites running in CI/CD.
- Extending the API test framework so the same path covers the system layer, internal integrations and external vendors.
- Isolating dependencies with WireMock.NET so lower-pyramid API tests stay repeatable and independent of flaky third-party services.
- Setting regression scope from change risk, instead of running the full suite on every fix.
- Aligning impact with developers, analysts and product owners before the test scope is closed.
Technologies and tools
- Selenium
- C#
- .NET
- REST API
- NUnit
- Azure
- Azure DevOps
- Docker
- Testcontainers
- Event Bus
- SQL
- NoSQL
- Gherkin
- BDD
- CI/CD
- WireMock.NET
- Databricks
- QA process for energy-system modernization: checking that business logic moved from mainframe to .NET behaves the same in the new services.
- Integration tests for batch jobs - data processing, state transitions and overnight orchestration - before results move further down the chain.
- Comparing legacy sources with microservices for functional equivalence and data integrity (Databricks, SQL, large datasets).
- Building automation frameworks from scratch for APIs and asynchronous processes, so a new scenario follows the same verification path.
- Wiring batch and regression suites into Azure DevOps so feedback returns in the pipeline, not outside it.
Technologies and tools
- Selenium
- Playwright
- C#
- .NET
- TypeScript
- REST API
- NUnit
- Azure
- Azure DevOps
- Docker
- SQL
- NoSQL
- CI/CD
- Snowflake
- Shaping the quality process across product teams: from agreeing scope, through automation, to a readable status before release.
- Mentoring and introducing QA practices so the decision on what to check does not depend on a single person.
- Designing backend, frontend and performance automation as one flow rather than separate silos.
- Embedding tests in CI/CD so verification results appear where the team already tracks the change.
- Turning test results into concrete corrective actions, not only a status-meeting report.
- Teaching QA as a process: from requirements and test design, through execution, to discussing risk and scope.
- Running the first demo sprint with newcomers so they practise delivery in a short cycle, not theory alone.
- Building course materials around practical skills: how to read a change, how to decide what to check, how to report.
- Mentoring students in day-to-day tester work, not only exam preparation.
Technologies and tools
- Selenium
- Java
- REST API
- JUnit
- Maven
- Docker
- Gatling
- SQL
- CI/CD
- Functional and API automation process: from scenario, through script, to a repeatable run.
- Tracking results and supporting debug so a red test ends in a decision, not a blind rerun.
- Onboarding people into QA standards: how to document, how to raise defects, how not to skip agreed scope.
- Combining functional, integration and performance tests into one picture of release risk.
Technologies and tools
- Selenium
- Java
- REST API
- JUnit
- Maven
- Docker
- Gatling
- Spock
- Groovy
- SQL
- NoSQL
- CI/CD
- BDD
- Automation process on the Security team: script design, execution and upkeep of a shared test library.
- From test plan, through defect records, to result analysis and a recommendation of what to fix first.
- A shared loop with developers: reproduce, fix, re-verify, and leave a report that can be audited.
Technologies and tools
- Selenium
- C#
- .NET
- REST API
- NUnit
- Azure
- Azure DevOps
- Docker
- SQL
- CI/CD
- Manual and integration testing process on the BI team, with TFS reporting as the shared verification trail.
- Keeping test cases current alongside documentation, performance tests and mobile execution.
- Preparing test data and fitting verification into the agile delivery rhythm before a change moved on.
How does your team currently decide what needs to be tested for a specific change?
If the answer involves manually combining tickets, pull requests, diffs and knowledge distributed across several people, let's discuss the workflow. A short discovery conversation can establish whether an AI QA workflow has a practical use case in your environment.