testomat.io управление авто тестамиДобро пожаловать в боль распределенных команд и роли тестировщика в них.
Если есть возможность то лучше тестирование Бек, АПИ и ЮИ сервисов выполнять одной общей командой тестировщиков (тогда тестировщики будут знать всю систему в целом и знать на что влияет каждое изменение в каждой из частей распределенного сервиса)
Как может быть в идеальном мире:
-
Бек (ядро)
1.1. Юнит тесты - команды девелоперов (покрытие ± 90%)
1.2. Функциональные тесты, тесты приёма, преобразования и сохранения данных - команда тестировщиков (можно вручную)
1.3. Функциональные тесты АПИ интерфейсов - команда тестировщиков (покрытие 100%) обязательно автоматизировать (очень желательно функциональное тестирование, а не только контрактное, поскольку разработчики очень часто любят зашивать всю бизнес логику на этом уровне) -
Клиенты (мобильные, веб и т.п. )
2.1. Юнит тесты - команды девелоперов (покрытие ± 90%) - заглушки на основании Вашей Swagger схемы (Настройте Faker так чтобы он сам всегда читал обновленный (свежий) свагер от Бека и заполнял все поля необходимыми данными) (Это Ваша первая линия защиты интеграции кода распределенных команд)
2.2. Функциональные тесты, юзер стори, тесты приёма, преобразования данных для передачи посредством АПИ (можно вручную) - команда тестировщиков
2.3. Автоматизированые тесты ЮИ интерфейсов (с замоканым АПИ) - команда тестировщиков (покрытие до 90% счасливых юзер стори, 20-30% - основных обработчиков ошибок)
2.4. Автоматизированые тесты Е2Е - команда тестировщиков (покрытие - только основные счасливые юзер стори те которые являются рисковыми и могут негативно повлиять на бизнес процессы. Пишите здесь только то что действительно важно их прийдется пускать часто и они должны проходить за вразумительное время) (Это Ваша вторая линия защиты интеграции кода распределенных команд) -
Поддкерживающие тесты:
3.1. Бек (ядро) - нагрузочные (Базы данных) - команда девелоперов (автоматизированые)
3.2. Бек (ядро) - нагрузочные (АПИ) - команда тестировщиков (автоматизированые)
3.3. Бек (ядро) - уровни доступа юзер ролей (АПИ) - команда тестировщиков (автоматизированые)
3.4. Клиенты (мобильные, веб и т.п. ) - уровни доступа юзер ролей - команда тестировщиков (автоматизированые) (Это Ваша третья линия защиты интеграции кода распределенных команд)
3.5. Тестирование связаное с изменением инфраструктуры, кластеризация, смены БД или ЯП, обновление версий - команда тестировщиков (тут в основном ручками, желательно иметь в помощь толкового девопса)
Ну и конечно нужно расписать процессы релизов и сборок, для разных команд. Тестовые связки желательно держать вместе.
Я не знаю обьемов Вашего приложения и количества разработчиков каждой из команд, но мне почемуто кажется ту работы явно не на одного двух тестировщиков. Желательно держать отдельную команду тестировщиков в связке с девопсами, ну либо Вам самим прийдется обслуживать тестовые связки, а как показывает практика там бывает такой зоопарк БД и технологий что самим тестировщикам очень тяжело будет справится, особенно если системы будут требовать кластеров и их тонких настроек.