# Background Dzianis Talstsiuk, a QA engineer at EXANTE, describes how he built AI into testing for desktop, web and mobile trading terminals. The aim: speed up routine work, broaden test coverage, and free testers to focus on analysis and higher-value tasks. The domain is financial trading, where rendering or state errors can cause client losses and regulatory risk, so requirements and acceptance criteria must be precise.
# Tools and technical stack The project keeps a conventional automation stack and layers generative models on top:
- Automation: Python and pytest.
- Web terminal testing: Playwright.
- Desktop automation: OpenCV, EasyOCR, PyAutoGUI.
Rather than fine-tuning, the team provides a context layer (called a Model Context Protocol, MCP) that connects the model to internal documentation, testing guides, and prior feedback. This gives the model project-specific context when reviewing requirements and generating test artefacts.
# How the workflow changed Traditional flow: QA often joins late and reacts to implementation gaps found after code is written. That creates rework and slower delivery.
New flow: QA joins as soon as requirements are fixed by Product. The tester runs the requirements through the LLM to check for completeness, ambiguity, logical gaps, and missing edge cases. The model returns structured questions and drafts that the tester reviews and refines.
Concrete example: a feature to pin a focused instrument at the top of a list appeared complete on first read, but the model flagged a missing case for the search screen. That gap, if found after implementation, would require rework. The model helped catch it earlier.
# What AI does well in this setup
- Finds ambiguous or multi-interpretation wording in acceptance criteria.
- Generates structured follow-up questions a tester would otherwise need to list manually.
- Drafts test scenarios and can expand them into cases tied to acceptance criteria.
- Speeds routine parts of test planning so testers can spend saved time on exploratory testing or bug fixes.
# Where AI falls short
- Business judgement and release decisions remain with humans.
- The model can surface possibilities but cannot decide risk trade-offs or final acceptance when requirements are unclear.
# Practical implementation notes
- The MCP is used as a contextual layer, not model fine-tuning, so the assistant sees internal rules and historical feedback when producing output.
# Outcome and recommended approach Embed an assistant at the QA entry point to shift testing left in a way that preserves human control. Use models to reduce routine drafting and to act as a fresh pair of eyes during requirements review. Keep explicit control points where testers make the final calls about acceptance and release readiness. Where domain risk is high, treat model output as a structured aid rather than an automated decision.