Организация контрактного тестирования микросервисов и графического портала

Добро пожаловать в боль распределенных команд и роли тестировщика в них.

Если есть возможность то лучше тестирование Бек, АПИ и ЮИ сервисов выполнять одной общей командой тестировщиков (тогда тестировщики будут знать всю систему в целом и знать на что влияет каждое изменение в каждой из частей распределенного сервиса)

Как может быть в идеальном мире:

  1. Бек (ядро)
    1.1. Юнит тесты - команды девелоперов (покрытие ± 90%)
    1.2. Функциональные тесты, тесты приёма, преобразования и сохранения данных - команда тестировщиков (можно вручную)
    1.3. Функциональные тесты АПИ интерфейсов - команда тестировщиков (покрытие 100%) обязательно автоматизировать (очень желательно функциональное тестирование, а не только контрактное, поскольку разработчики очень часто любят зашивать всю бизнес логику на этом уровне)

  2. Клиенты (мобильные, веб и т.п. )
    2.1. Юнит тесты - команды девелоперов (покрытие ± 90%) - заглушки на основании Вашей Swagger схемы (Настройте Faker так чтобы он сам всегда читал обновленный (свежий) свагер от Бека и заполнял все поля необходимыми данными) (Это Ваша первая линия защиты интеграции кода распределенных команд)
    2.2. Функциональные тесты, юзер стори, тесты приёма, преобразования данных для передачи посредством АПИ (можно вручную) - команда тестировщиков
    2.3. Автоматизированые тесты ЮИ интерфейсов (с замоканым АПИ) - команда тестировщиков (покрытие до 90% счасливых юзер стори, 20-30% - основных обработчиков ошибок)
    2.4. Автоматизированые тесты Е2Е - команда тестировщиков (покрытие - только основные счасливые юзер стори те которые являются рисковыми и могут негативно повлиять на бизнес процессы. Пишите здесь только то что действительно важно их прийдется пускать часто и они должны проходить за вразумительное время) (Это Ваша вторая линия защиты интеграции кода распределенных команд)

  3. Поддкерживающие тесты:
    3.1. Бек (ядро) - нагрузочные (Базы данных) - команда девелоперов (автоматизированые)
    3.2. Бек (ядро) - нагрузочные (АПИ) - команда тестировщиков (автоматизированые)
    3.3. Бек (ядро) - уровни доступа юзер ролей (АПИ) - команда тестировщиков (автоматизированые)
    3.4. Клиенты (мобильные, веб и т.п. ) - уровни доступа юзер ролей - команда тестировщиков (автоматизированые) (Это Ваша третья линия защиты интеграции кода распределенных команд)
    3.5. Тестирование связаное с изменением инфраструктуры, кластеризация, смены БД или ЯП, обновление версий - команда тестировщиков (тут в основном ручками, желательно иметь в помощь толкового девопса)

Ну и конечно нужно расписать процессы релизов и сборок, для разных команд. Тестовые связки желательно держать вместе.

Я не знаю обьемов Вашего приложения и количества разработчиков каждой из команд, но мне почемуто кажется ту работы явно не на одного двух тестировщиков. Желательно держать отдельную команду тестировщиков в связке с девопсами, ну либо Вам самим прийдется обслуживать тестовые связки, а как показывает практика там бывает такой зоопарк БД и технологий что самим тестировщикам очень тяжело будет справится, особенно если системы будут требовать кластеров и их тонких настроек.

4 лайка

jdckjfoweutlsjb,sjhflieuöp9wiutilkshg