А также Qdrant, Allure TestOps и вера в светлое будущее
Как по старинке?
Если в вашей компании по каким-либо причинам продолжают верить в силу тестирования, то вам, как тестировщику, необходимо писать тестовую документацию, основа которой лежит в наборе тестовых кейсов. Ходят легенды, что тест-кейсы содержат самую актуальную информацию о продукте и его фичах. Спецификации устаревают, эксперты, знающие все и вся, увольняются, а тесты по тест-кейсам прогоняются каждый божий день и демонстрируют реальное состояние дел в вашем замечательном (или не очень) продукте.
Базовой основой для составления тест-кейсов выступают спецификации, макеты, возгласы продактов, намеки аналитиков, опыт самого специалиста по тестированию, который, включая внутреннего пользователя, проходит юзкейсы, применяя техники тест-дизайна, силу интеллекта и проф чутье.
Как это происходит на пальцах? Открываем конфлюенс, фигму, тест менеджер, сам продукт и заводим кейс за кейсом, аккуратно проходя требование за требованием. Если не отвлекаться на кофе и вотеркуллер госсипс на один тест-кейс уйдет 5-10 минут. Умножаем это на количество требований, учитывая негативные кейсы и природную лень.
А как можно?
Что в этом процессе можно ускорить и автоматизировать? В целом – всю цепочку от спецификации до тест-кейса в тест менеджере. Рассмотрим конкретную реализацию. Что имеем на старте: требования разбросаны в спеках в Confluence и описании Jira задач. Что нужно получить в конце: заведенный тест-кейс в Allure TestOps.
Нарезаем дольками
Как можно получить контент из вики и Jira без танцев с бубном с Atlassian API? Воспользоваться вершиной эволюции человеческого сознания – MCP. Достаточно указать пути к внутренним ресурсам, креды доступа и вуаля – ключевые действия с вики и таск менеджером в твоем клиенте.
Можно прочитать контент вики страницы по заголовку, таски по ключу, подвести статистику по задачам и много чего еще. Для наших целей хватит гет тулов, которые обеспечивают доступ к контенту. Не все модели одинаково хорошо взаимодействуют с mcp, но gpt-4o-mini справляется с задачей на ура.
Доступ получили, что дальше? Дальше нарезаем наш контент на чанки и кладем внутрь БД. Мы взяли qdrant, потому что потому.
А как же без AI
Далее нам необходим «тестеровщикозаменитель», которым будет выступать чат клиент с довольно обширной инструкцией о том, что есть тестирование, что такое тест-кейс, какие критерии оценки кейсов необходимо соблюдать. Сформированный промпт пробуем на кошках и удостоверяемся, что выдаваемый ответ каким-то образом совпадает с нашим представлением о прекрасном.
Здесь стоит отметить, что выбранная ранее для работы с mcp модель тест кейсы формировала только в путь, но в ограниченном количестве. Как ни дорабатывай промпт, какой максимум токенов ни указывай – на выходе стыдливый десяточек кейсов. После непродолжительных экспериментов была выбрана более сговорчивая модель.
После – дело техники. При нарезке чанков мы оставляем якорек, который позволяет нам отделить скоуп документов только нужной нам фичи. Отправляя запрос с промптом, мы указываем, что обрабатывать нужно только документы с якорем и на выходе получаем список из тест-кейсов в виде JSON.
Остается последний шаг – полученный список положить внутрь нашего тестохранилища. Кланяемся в ноги разработчикам Allure, которые описали API для работы, и постим наш список в нужный проект.
Сила Spring-a
Что по технологиям? Повторно кланяемся в ноги, но уже разработчикам Spring AI, которые уместили в едином месте возможности работы с разными моделями, БДшками и MCP. Разделяем логику работы с БД, TestOps и продуктами Atlassian по разным сервисам, создаем для сервисов контроллеры для доступа к функционалу через REST. В нетерпении начать заменять тестировщиков бездушной машиной, навешиваем на контроллеры аннотации OpenApi и на выходе получаем связку методов в Swagger-документе.
Пока еще работающий тестировщик заполняет первый метод заголовком документа из вики, пополняет хранилище и выставляет отметку для дальнейшей фильтрации. После этого отправляет запрос на формирование тест-кейсов, который заботливо предоставляет список в удобном для импорта в TestOps формате. Специалист просматривает кейсы на предмет их адекватности и актуальности, удаляя ненужное и дописывая необходимое. Копипаст массива кейсов в следующее окно пополняет коллекцию проекта.
Итого
Что по итогам? Тут должна быть информация о том, что n человекочасов сэкономлено, m специалистов отправлено на заслуженный отдых. Но мы только в начале пути. Промпт можно и нужно дополнять и переписывать, модели – менять. Каждый сервис можно пользовать по-отдельности – MCP Atlassian и qdrant можно запускать в чате по дефолту, функционал с формированием тест-кейсов и экспортом в тест-менеджер тоже можно обернуть в виде MCP-сервера и работать со всей цепочкой из какого-нибудь Cursor или Claude. А можно нарисовать красивый фронт с завитушками.
Но больший интерес составляют, конечно же, сами генерируемые тест-кейсы. Существующие AI-агенты, если им задать контекст из уже написанного фреймворка автоматизации (POM, классы-провайдеры и написанные автотесты) могут продолжить нашу цепочку и писать автотесты по сгенерированным кейсам, освобождая время на лесные прогулки и игру в дженгу.
Автор: nick_and_his_name
