Comments 2
По опыту самое сложное
Интеграция. Часто экземпляры тестовых систем не могут тиражироваться, проект вроде интернет банкинга - это 20+ разных систем
Подбор тестовых данных, так как часто "моки" не помогают либо нерелевантны
Необходимость регресса по внешним процессам типа закрытия дня
В больших проектах обычно QA требуется серьезная помощь, так как крайне редко можно увидеть человека, который сам нарисует для команды схему тестовой среды всего комплекса
Ну и почему-то не упомянута проблема деперсонализации данных, хотя тут скорее всего на нее забили болт, и тупо тестят на реальных данных
Интеграцию и стабильный интеграционный контур это то, что действительно сложно обеспечить.
У нас полностью обезличенный стейдж (какие-то системы просто подняли без данных, какие-то деперсонализировали), где мы как раз и отлаживаем то, что можно пропустить на моках. Бывают ситуации, когда вроде все проверили, но ошибку в итоге отловили только в интеграции между системами.
Но стремимся делать именно компонентное тестирование на заглушках, как раз потому что тестирование сразу на интеграционном полигоне - ломает полигон и страдают все.
Поэтому все сначала на локальном стенде проверяют и только потом делают проверку минимально необходимых интеграций. Плюс все фичи с фичи тоглами, чтобы если что сразу выключить.По подбору данных тоже много что делаем на эту тему, например, есть инструмент, который заглушки на основе апи спецификаций делает.
Или если говорить про стейдж у нас есть Портал тестовых данных, который сквозную синтетику генерит, сквозь несколько систем, чтобы валидные данные были.
В том числе делали инструментарий, который исторические данные создает.
Если заморочиться можно сделать достаточно качественную синтетику.Для меня закрытия дня не внешний процесс, а просто процесс АБСки, его тоже можно на деперсе смотреть, мы сейчас на НТ это смотрим. Но тут скорее проблема в проверке сходимости, что закрылось корректно. Это скриптами можно выверить.
А если говорить прям про внешние на которые нет возможности повлиять или узнать об изменених, то надо контрактные тесты регулярно гонять, тогда хотя бы можно быстрее отловить ошибку.
Тестировщик в банке (не в трёхлитровой)