Тест-кейсы на автопилоте: как Spring AI и Atlassian MCP упрощают жизнь тестировщика

А также Qdrant, Allure TestOps и вера в светлое будущее

Как по старинке?

Если в вашей компании по каким-либо причинам продолжают верить в силу тестирования, то вам, как тестировщику, необходимо писать тестовую документацию, основа которой лежит в наборе тестовых кейсов. Ходят легенды, что тест-кейсы содержат самую актуальную информацию о продукте и его фичах. Спецификации устаревают, эксперты, знающие все и вся, увольняются, а тесты по тест-кейсам прогоняются каждый божий день и демонстрируют реальное состояние дел в вашем замечательном (или не очень) продукте.

Базовой основой для составления тест-кейсов выступают спецификации, макеты, возгласы продактов, намеки аналитиков, опыт ^[1] самого специалиста по тестированию, который, включая внутреннего пользователя, проходит юзкейсы, применяя техники тест-дизайна, силу интеллекта ^[2] и проф чутье.

Как это происходит на пальцах? Открываем конфлюенс, фигму, тест менеджер, сам продукт и заводим кейс за кейсом, аккуратно проходя требование за требованием. Если не отвлекаться на кофе и вотеркуллер госсипс на один тест-кейс уйдет 5-10 минут. Умножаем это на количество требований, учитывая негативные кейсы и природную лень.

А как можно?

Что в этом процессе можно ускорить и автоматизировать? В целом – всю цепочку от спецификации до тест-кейса в тест менеджере. Рассмотрим конкретную реализацию. Что имеем на старте: требования разбросаны в спеках в Confluence и описании Jira задач. Что нужно получить в конце: заведенный тест-кейс в Allure TestOps ^[3].

Нарезаем дольками

Как можно получить контент из вики и Jira без танцев с бубном с Atlassian API? Воспользоваться вершиной эволюции человеческого сознания – MCP ^[4]. Достаточно указать пути к внутренним ресурсам, креды доступа и вуаля – ключевые действия с вики и таск менеджером в твоем клиенте.

Можно прочитать контент вики страницы по заголовку, таски по ключу, подвести статистику по задачам и много чего еще ^[5]. Для наших целей хватит гет тулов, которые обеспечивают доступ к контенту. Не все модели одинаково хорошо взаимодействуют с mcp, но gpt-4o-mini справляется с задачей на ура.

Доступ получили, что дальше? Дальше нарезаем наш контент на чанки и кладем внутрь БД. Мы взяли qdrant ^[6], потому что потому.

А как же без AI

Далее нам необходим «тестеровщикозаменитель», которым будет выступать чат клиент с довольно обширной инструкцией о том, что есть тестирование, что такое тест-кейс, какие критерии оценки кейсов необходимо соблюдать. Сформированный промпт пробуем на кошках и удостоверяемся, что выдаваемый ответ каким-то образом совпадает с нашим представлением о прекрасном.

Здесь стоит отметить, что выбранная ранее для работы с mcp модель тест кейсы формировала только в путь, но в ограниченном количестве. Как ни дорабатывай промпт, какой максимум токенов ни указывай – на выходе стыдливый десяточек кейсов. После непродолжительных экспериментов была выбрана более сговорчивая модель.

После – дело техники. При нарезке чанков мы оставляем якорек, который позволяет нам отделить скоуп документов только нужной нам фичи. Отправляя запрос с промптом, мы указываем, что обрабатывать нужно только документы с якорем и на выходе получаем список из тест-кейсов в виде JSON.

Остается последний шаг – полученный список положить внутрь нашего тестохранилища. Кланяемся в ноги разработчикам Allure, которые описали API для работы, и постим наш список в нужный проект.

Сила Spring-a

Что по технологиям? Повторно кланяемся в ноги, но уже разработчикам Spring AI ^[7], которые уместили в едином месте возможности работы с разными моделями, БДшками и MCP. Разделяем логику ^[8] работы с БД, TestOps и продуктами Atlassian по разным сервисам, создаем для сервисов контроллеры для доступа к функционалу через REST. В нетерпении начать заменять тестировщиков бездушной машиной, навешиваем на контроллеры аннотации OpenApi и на выходе получаем связку методов в Swagger-документе.

Пока еще работающий тестировщик заполняет первый метод заголовком документа из вики, пополняет хранилище и выставляет отметку для дальнейшей фильтрации. После этого отправляет запрос на формирование тест-кейсов, который заботливо предоставляет список в удобном для импорта в TestOps формате. Специалист просматривает кейсы на предмет их адекватности и актуальности, удаляя ненужное и дописывая необходимое. Копипаст массива кейсов в следующее окно пополняет коллекцию проекта.

Итого

Что по итогам? Тут должна быть информация о том, что n человекочасов сэкономлено, m специалистов отправлено на заслуженный отдых. Но мы только в начале пути. Промпт можно и нужно дополнять и переписывать, модели – менять. Каждый сервис можно пользовать по-отдельности – MCP Atlassian и qdrant можно запускать в чате по дефолту, функционал с формированием тест-кейсов и экспортом в тест-менеджер тоже можно обернуть в виде MCP-сервера и работать со всей цепочкой из какого-нибудь Cursor или Claude. А можно нарисовать красивый фронт с завитушками.

Но больший интерес ^[9] составляют, конечно же, сами генерируемые тест-кейсы. Существующие AI-агенты, если им задать контекст из уже написанного фреймворка автоматизации (POM, классы-провайдеры и написанные автотесты) могут продолжить нашу цепочку и писать автотесты по сгенерированным кейсам, освобождая время на лесные прогулки и игру в дженгу.