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

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

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

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

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

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

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