AI Tool for QA: How a High-Risk Release Was Tested

⚡ The gist in 5 seconds - The gist: to test a high-risk release in a microservice environment with legacy code, the team broke the task into subtasks and assigned them to separate AI agents. - Where it's available: the tool is implemented as a reusable environment for Cursor agents in an IDE with agentic AI support. - Limitation: the first version was built in vibe-coding mode, but the prototype needs refinement and testing before it becomes a reliable team tool. ### 🔍 What was found In one sprint, the team took on a task that looked simple on paper, but in reality the new logic had to be embedded in high-load data flows passing through several microservices, where legacy code held plenty of surprises. Even a single missed defect could create significant financial risk. Manually reviewing 8,000+ documents in Confluence (business requirements, functional requirements, user stories, specifications) was unrealistic. So the author developed a process with four artifacts. First, they searched in parallel for requirements related to publishing messages to a Kafka topic and modifying data in a target SQL database table, and also explored the codebase (artifacts #1–3). Then they sequentially built a map of expected flows, identifying triggers and reproduction methods, after which they compared it with the map of the actual implementation. The comparison revealed matches, discrepancies, implementation without requirements, and requirements without implementation — each statement was accompanied by links to Confluence and the code. The report was reviewed with developers and system analysts; the data turned out to be accurate and complete, and it was used as precise test coverage. After the team handled the task, the author decided to turn the process into a reusable environment for Cursor agents. The environment answers questions about expected and implemented behavior with the source indicated (documentation, code of the deployed version, or configuration), analyzes new requirements and a Git branch/MR, identifies discrepancies, gaps and ambiguities, and, on request, updates the knowledge base with a distinction between production behavior, branch behavior, and documented behavior without implementation. The tool is already being used in the team to find implementation defects, gaps in functional requirements, and to explain why services behave the way they do. ### 💡 Why it matters This approach solves the key problem of testing in microservice systems with legacy code: manually analyzing thousands of documents and the codebase takes too long and doesn't guarantee full coverage. Splitting the work among specialized AI agents with clear input and output formats makes it possible to process large volumes of information, link requirements to code, and find discrepancies. The tool gives the team a shared context and an understanding of the relationships between documentation and implementation, which is critical for high-risk releases where an error can lead to financial losses. The ability to update the knowledge base and indicate sources makes the process transparent and verifiable. ### 🧩 Context In one of the recent

🔗 Read on habr.com