Если вам достался высоконагруженный проект с микросервисной архитектурой и парой десятков интеграций со сторонними системами, включая AI и платежные агрегаторы, что ж… Бог в помощь)

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

Что сделать, чтобы облегчить тестирование?

1. Разработчики должны писать unit-тесты. Без этого любая ошибка будет стоить дороже в три раза.
2. Выделите 1-2 тестировщиков для написания end-to-end тестов на Backend. Это занимает не так много времени, но релиз автоматически станет безопаснее.
3. Разворачивайте тестовую среду для каждой крупной задачи. Забудьте каскад Dev → Test → Demo/Stage → Prod. Должно быть несколько независимых тестовых сред, всегда свежий master. Не пытайтесь делать релизы двух крупных задач одновременно. Потеряете обе задачи.
4. Обрабатывайте отказ микросервиса и интеграции. При тестировании, подменяйте ответы, чтобы убедиться, что базовый функционал будет работать без большинства менее значимых функций.
5. Синхронизируйтесь между командами. Читайте доски друг друга, собирайтесь на кофе в конце рабочего дня и обсуждайте, кто и что делает.
6. Изолируйте тестовые среды от доступа от внешнего доступа. Поверьте, обязательно найдется пользователь, который найдет ваш тестовый стенд и будет там ждать боевых результатов. Это не шутка, а боль из опыта.

Как же быть тестировщикам?

1. Погружайтесь все глубже и глубже в бизнес-логику. Это поможет понимать, куда “копать” и что правда критично.
2. Мокайте внешние сервисы, чтобы не быть от них зависимыми. Ответы от них, как правило, не меняются внезапно, поэтому не тестируйте чужие системы.
3. Ни в коем случае не используйте данные реальных пользователей при тестировании. Заменяйте их на UserTest простейшими скриптами.

Если все сделать правильно, то сложность проекта станет просто интересной задачей