Зоопарк фреймворков в QA — это не «гибкость», а дорогой бардак на зарплате.

Зоопарк фреймворков в QA — это не «гибкость», а дорогой бардак на зарплате.

В крупняке обычно происходит одно и то же: десятки команд пилят свои “удобные” костыли, тесты живут отдельно от логики продукта, документация устаревает быстрее, чем её успевают открыть, а потом сверху прилетает ИИ и должен “магически помочь”. Не поможет. Если контекст размазан по сотне репозиториев, LLM будет уверенно врать на стероидах 🤷‍♂️

Нормальное решение — не ещё один фреймворк, а централизация. Один каркас, единые правила, RAG поверх актуальной базы знаний и MCP-сервер как мост к контексту тестов. Тогда модель понимает не только текст запроса, но и что вообще происходит в вашей QA-экосистеме.

Главный вывод неприятный, но полезный: будущий QA-инженер — это не “человек, который кликает автотесты”. Это промпт-инженер с глубокой предметкой и умением не кормить ИИ мусором.

И да, если у вас внутри компании тестовая система напоминает ссылочный спам из 2016-го — никакой AI это не спасёт. Пока не вычистите базу, результата не будет.