🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Про тестовые окружения (стенды).
Иногда кажется, что тестовые стенды живут по своим законам.
Ты начинаешь проходит тест-кейс, вчера все работало, а сегодня внезапно ошибка. При этом разработчик уверяет, что на его стенде все работает корректно.
И несмотря на то, что чаще это конечно может быть реальный баг, но на самом деле я все чаще замечаю, что именно нестабильные тестовые окружения становятся главной причиной срывов регрессий и фейковых багов. И это не про плохую настройку окружения, а про системную проблему, что тестовые окружения никто не держит в актуальном состоянии. У них часто нет владельца, мониторинга, а данные там живут по принципу кто раньше успел , то и молодец, особенно в больших командах.
Самое забавное, что иногда тестировщики часами ищут баг, а потом выясняется, что просто одна из зависимостей в тестовом окружении отвалилась, соседняя команда задеплоила свою версию микросервиса и случайно все тебе сломала или кто испротил тестовые данные.
В идеале тестовое окружение должно быть предсказуемым, а именно чистые данные, стабильные сервисы, контроль версий, деплой как в проде. На практике же - это чаще набор контейнеров, которые поднимаются как попало и живут своей жизнью, пока кто-то не заметит, что тесты снова не работают, причем уже в больших масштабах
Я за то, чтобы тестировщики начали относиться к окружению как к продукту, умели поддерживать версионность, мониторить, документировать и не стесняться попросить у DevOps нормальный пайплайн для обновлений.
А у вас бывало, что баг оказался не багом, а особенностями тестового стенда?
Как решаете проблему нестабильных окружений, автоматизацией, изоляцией от команд или просто привычкой перезапусти, вдруг заработает? 👇
Все мои проекты:
TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту |
Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний