Есть вот такая картинка, что участники реализации проекта (заказчик, дизайнер, аналитик, разработчик, тестировщик etc.) понимают по своему, как должны выглядеть качели. Решить эту проблему призван Gerkin - технология описания сценариев на человеческом языке, но с особой структурой, которую можно использовать для автоматизации. Каждая строчка Given/When/Then в файле .feature - это шаг выполнения сценария. Их легко реализовать на любом языке программирования (JavaScript, Python, Golang etc.) и можно переиспользовать. Варианты проверочных данных прописываются в таблице Examples.
список сценариев:
содержимое сценария:
маппинг шагов всех сценариев:
реализация одного шага:
Что такое GraphQL? Это API с тремя типами вызовов: Query(синхронные запросы на чтение), Mutation(сиинхронные запросы на запись), Subscription(асинхронные подписки). В первой итерации достаточно реализовать атомарное покрытие тестами этих вызовов. Сценарии можно легко подготовить через ИИ-генерацию, скормливая GraphQL с постановкой задачи обнаружить связи между данными на запись и чтение. Для большего контекста, можно ещё скормить план ручного тестирования (который уже есть у Марины). Дальше реализовать шаги сценариев. Всё! Мы получили e2e-тесты работоспособности бэка.
Далее прикручиваем к этим тестам k6. Запускаем и выявляем пределы нагрузки для каждого сценария. Да, мы ещё не знаем, какие из сценариев потребуют ту или иную нагрузку в проде. Но уже можем готовиться прилагать усилия к очевидно узким местам. Всё! Мы получили нагрузочные тесты. И таким образом убили сразу двух зайцев.
Во второй итерации можно переходить к автоматизации ручного тестирования (без разделения на AQA и ручное тестирование). Только вместо GraphQL, взаимодействуем с UI приложений. Всё! Мы получили приёмочные UI-тесты для проверки бизнес-логики.
