Яндекс.Деньги corporate blog
IT systems testing
Web services testing
Build automation
Comments 17
UFO landed and left these words here
+1
Спасибо за вопросы!

1. Исключаем с помощью сервиса quick-block. После решения задачи тест автоматом начнет запускаться, так как проверяем актуальность задачи в jira перед каждым запуском приёмки.
2. На практике, часто падающие тесты анализируются после сбора статистики, и в причинах их падения мы разбираемся. Исключить пропуск плавающих багов нельзя, но при нашем числе релизов лучше принимать такой риск, чем тормозить релизный цикл за счет ручного разбора упавших flaky-тестов.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
+1
Расскажите по поводу ретраев:
Если тест параметризован и один из них упал — перезапускается ли вся параметризация?
0
При перезапуске параметризованных тестов «из коробки» заново прогоняются все комбинации. У нас немного параметризованных сценариев в приемке, они чаще используются в других типах автотестов.
+1
Ничего не понятно. Добавляете фичу, отключаете падающие от изменений тесты, пока их не актуализируют, пишите новые тесты на фичу, а тем временем фича релизится без тестирования на прод?
0

Обычно сценарии поломанных тестов проверяют вручную, непротестированные фичи ни в коем случае не деплоятся в продакшен.
Важная функция блокировки — дать возможность отложить запуск новых тестов, написанных на фичу, до ее релиза. Блокировка старых тестов бывает не так часто, и, как правило, команды актуализируют код тестов параллельно изменениям в сервисе. Отключаются только тесты на минорную функциональность, и под ответственность команды, которая релизит компонент.

0

Яндекс.Деньги? Скажите, вы когда-нибудь дадите возможность оплачивать штрафы с карты, прикреплённой к ящикам Почты для домена?!

0

Спасибо за увлекательную статью! Интересны подробности :)


  1. Сколько у вас приемочных тестов? Какова стабильность?
  2. Какие классы приемочных сценариев вы покрыли тестами, а какие — нет? Интересуют не сценарии продукта, а категории типа "совместимость нового компонента с данными старой версии" или "сценарии отката релизас
  3. Если команды разработки сами пишут приемочные тесты, то почему они не разбирают их падения и почему гоняют тесты только перед релизом? Могли бы делать это раньше, например до своего ручного тестирования :)
  4. Я правильно понял, что при деплое нового компонента на стенд, версии других на стенде сбрасываются до релизных? Если нет, то на какой версии всего продукта гоняются тесты?
  5. Как у вас релизятся фичи, в которых надо согласованно обновить несколько компонентов от разных команд?
0
  1. Какие требования вы предъявляете к пулл-реквестам в проект с тестами?
0

Code review осуществляем в bitbucket, в соответствии с successfull git branching model.
Изменения должны быть оформлены в соответствии с нашим Coding Convention. Для merge обязателен аппрув от члена команды интеграционного тестирования.


У нас автоматизирована логика назначения ревьюеров на созданный PR, а также автоматическая проверка бранча на предмет соответствия минимальным требованиям — но это, возможно, тема для отдельной статьи.

0
  1. Приемочных тестов на данный момент около 1500, они покрывают end-2-end сценарии разной степени сложности: иногда в сценарии участвуют 2 компонента, иногда 22. Компонентные тесты на сервисы, unit тесты — запускаются отдельно. Стабильность зависит от множества факторов, например, от того, задействован ли web-браузер в тесте, сколько компонентов затрагивает сценарий, как нагружены тестовая среда и CI-инструментарий. Перепрогоны в jenkins pipeline позволили снизить частоту откровенно случайных падений почти до 0.


  2. Проверка сценариев отката, как и совместимость существующих данных с новой версией компонента, находится в зоне ответственности команд. Наша задача — провести интеграционное тестирование работоспособности бизнес-сценариев на окружении, приближенном к боевому максимально возможно.


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


  4. Каждую ночь версии всех компонент на тестовых средах синхронизируются с продакшен-средой. В течение дня релизы тестируются на свободных схемах, выбранных рандомно. Таким образом, к концу дня имеем разной степени обновленности схемы. Ночью — снова синк. Как показала практика, жить так можно. При тестировании зависимых сервисов приходится вручную накатывать их на все стенды.


  5. Здесь без вмешательства человека не обходится. О таких коллизиях нас предупреждают команды, и мы уже самостоятельно разрешаем все зависимости.


Only those users with full accounts are able to leave comments., please.