Привет, Хабр!

Мы — команда тестирования в IT-департаменте крупной компании. За годы работы мы накопили опыт борьбы с рисками, которые возникают при выпуске релизов. Сегодня расскажем, как мы их классифицировали, минимизировали и превратили в управляемый процесс.

Почему это важно? Незаметные на первый взгляд проблемы могут привести к задержкам, ухудшению качества и финансовым потерям. Мы систематизируем свой опыт, анализируем прошлые ошибки и заранее готовимся к возможным сложностям — чтобы релизы проходили гладко и без сюрпризов. Хотите узнать, как мы это делаем? Тогда поехали!

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5–7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

Проблема в том, что у нас практически нет системы мониторинга состояния сервисов. Я не получал автоматической информации о том, что происходит с каждым из них, а расспросы коллег не давали ясных ответов.

Со временем мне стало важно быстро понимать, какие ветки задеплоены на конкретных стендах для всех сервисов, входящих в релиз. В Git такой возможности прямо из коробки нет — нельзя выбрать сразу список сервисов из разных проектов и посмотреть их окружения в виде таблицы или списка.

Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования.

Когда количество проектов увеличилось, а релизов и сервисов стало больше, необходимость быстро получать актуальную информацию о статусе сервисов на стендах стала особенно важной.

Привет, Хабр! Мы сотрудники Управления контроля качества компании Capital Group. Непосредственно участвуем в процессах тестирования программных продуктов, которые используются нашими менеджерами, работниками управляющих компаний, гостями и жителями ЖК CG.

Так как релизы наших приложений происходят почти еженедельно и нагрузка на ручных тестировщиков велика, в прошлом году мы внедрили автоматизацию регрессионных тестов. В этой статье расскажем о том, как мы настраивали запуск автотестов для мобильных устройств на реальном девайсе iOS.

Изначально такие автотесты писались и прогонялись на симуляторах, что довольно удобно: можно быстро собирать разные смартфоны и планшеты, проверять работоспособность приложения на различных версиях операционных систем и платформах. Тем не менее проверки должны быть максимально приближены к реальному пользовательскому сценарию взаимодействия с приложением, поскольку, в редких случаях могут возникать ошибки, которые не воспроизводятся на симуляторе. Поэтому, для получения более точных результатов тестирования было принято решение запускать автотесты на реальных устройствах. Со смартфоном Android все получилось быстро и безболезненно, но айфон заставил нас помучаться, этап подготовки показался долгим, сложным и запутанным.