Комментарии 17
1. Исключаем с помощью сервиса quick-block. После решения задачи тест автоматом начнет запускаться, так как проверяем актуальность задачи в jira перед каждым запуском приёмки.
2. На практике, часто падающие тесты анализируются после сбора статистики, и в причинах их падения мы разбираемся. Исключить пропуск плавающих багов нельзя, но при нашем числе релизов лучше принимать такой риск, чем тормозить релизный цикл за счет ручного разбора упавших flaky-тестов.
Если тест параметризован и один из них упал — перезапускается ли вся параметризация?
Обычно сценарии поломанных тестов проверяют вручную, непротестированные фичи ни в коем случае не деплоятся в продакшен.
Важная функция блокировки — дать возможность отложить запуск новых тестов, написанных на фичу, до ее релиза. Блокировка старых тестов бывает не так часто, и, как правило, команды актуализируют код тестов параллельно изменениям в сервисе. Отключаются только тесты на минорную функциональность, и под ответственность команды, которая релизит компонент.
Яндекс.Деньги? Скажите, вы когда-нибудь дадите возможность оплачивать штрафы с карты, прикреплённой к ящикам Почты для домена?!
Спасибо за увлекательную статью! Интересны подробности :)
- Сколько у вас приемочных тестов? Какова стабильность?
- Какие классы приемочных сценариев вы покрыли тестами, а какие — нет? Интересуют не сценарии продукта, а категории типа "совместимость нового компонента с данными старой версии" или "сценарии отката релизас
- Если команды разработки сами пишут приемочные тесты, то почему они не разбирают их падения и почему гоняют тесты только перед релизом? Могли бы делать это раньше, например до своего ручного тестирования :)
- Я правильно понял, что при деплое нового компонента на стенд, версии других на стенде сбрасываются до релизных? Если нет, то на какой версии всего продукта гоняются тесты?
- Как у вас релизятся фичи, в которых надо согласованно обновить несколько компонентов от разных команд?
- Какие требования вы предъявляете к пулл-реквестам в проект с тестами?
Code review осуществляем в bitbucket, в соответствии с successfull git branching model.
Изменения должны быть оформлены в соответствии с нашим Coding Convention. Для merge обязателен аппрув от члена команды интеграционного тестирования.
У нас автоматизирована логика назначения ревьюеров на созданный PR, а также автоматическая проверка бранча на предмет соответствия минимальным требованиям — но это, возможно, тема для отдельной статьи.
Приемочных тестов на данный момент около 1500, они покрывают end-2-end сценарии разной степени сложности: иногда в сценарии участвуют 2 компонента, иногда 22. Компонентные тесты на сервисы, unit тесты — запускаются отдельно. Стабильность зависит от множества факторов, например, от того, задействован ли web-браузер в тесте, сколько компонентов затрагивает сценарий, как нагружены тестовая среда и CI-инструментарий. Перепрогоны в jenkins pipeline позволили снизить частоту откровенно случайных падений почти до 0.
Проверка сценариев отката, как и совместимость существующих данных с новой версией компонента, находится в зоне ответственности команд. Наша задача — провести интеграционное тестирование работоспособности бизнес-сценариев на окружении, приближенном к боевому максимально возможно.
Команды часто гоняют тесты на фичесборках, но это на сегодняшний день опция. Причина — в тонкостях организации тестовой среды. Интеграционные тестовые стенды более прокачаны, чем тестовые стенды команд, как с точки зрения ресурсов, так и с точки зрения числа сервисов: на тестовых стендах команд могут отсутствовать компоненты, которые данной командой не используются при разработке новых фичей, а следовательно, полный набор приемочных тестов на такой схеме проходить не обязан.
Каждую ночь версии всех компонент на тестовых средах синхронизируются с продакшен-средой. В течение дня релизы тестируются на свободных схемах, выбранных рандомно. Таким образом, к концу дня имеем разной степени обновленности схемы. Ночью — снова синк. Как показала практика, жить так можно. При тестировании зависимых сервисов приходится вручную накатывать их на все стенды.
Здесь без вмешательства человека не обходится. О таких коллизиях нас предупреждают команды, и мы уже самостоятельно разрешаем все зависимости.
Автоматизируй это! Как мы улучшали интеграционное тестирование