Comments 10
создали утренние и вечерние прогоны автотестов на разных окружения
А почему не на пул-реквесты?
Надо уходить от такого флоу, кажется, так не удобно и сложно найти, причину в случаи падения теста
Приветствую Алексей!
Изначально такой флоу и был - каждый раз автоматический запуск тестов после каждой сборки. Но как оказалось на практике - когда тот же офис в день пересобирается больше 10 раз - на падающие тесты просто не остается времени, чтобы отсеять реальное падение теста с ошибкой от всех остальных ситуаций.
Мы пришли к такой схеме:
Получается дважды в день контролируем работоспособность основного тестового набора (утром проверяем готов ли офис/стейдж и не поломали ли чего за вчера, а вечером проверяем прод). При этом, при проверке переданных задач, QA-инженеры запускают автотесты и по сути контролируют выполнение тестов в течение дня.
на падающие тесты просто не остается времени, чтобы отсеять реальное падение теста с ошибкой от всех остальных ситуаций.
О каких остальных ситуациях речь?
Вообще, странно, конечно. Если я что-то запушил и оно падает с ошибками, то разобраться здесь и сейчас всяко проще чем потом, когда там уже нальют кучу изменений. К тому же, проще будет сказать что то в духе "задача уже принята, вроде работает, на правку тестов пару дней нужно, может ну их, эти тесты?"
Поддержу. У некоторых команд есть правило, если на пул-реквест тест не прошел, то вмерджить не получится в дев.
Подозреваю, речь идёт о нестабильных тестах. Здесь имеет смысл в приёмочные тесты добавлять исключительно стабильные для запуска по хуку в гитхабе/гитлабе
Очевидное решение, на мой взгляд :)
А что за "стабильные тесты"? Как их определять? Может стоит с ними что то сделать?)
А то так можно любой тест отключить с мотивацией, что "он нестабильный".
Понятно, что можно писать такие тесты, которые будут очень хрупкие, но их нужно править, а не отключать на приёмке и включать потом. Это какая то двойная (тройная etc) работа
Про стабильные/нестабильные тесты - померить это можно на временной дистанции по кол-ву падений прогонов тестов. Если говорить про наши автотесты, то мы считаем, что текущие API-автотесты стабильные, как для прод-сервера, так и для stage. Тесты падают крайне редко и по примерной оценке падения не превышают 1-2% от всех совершенных прогонов.
Извиняюсь за довольно поздний ответ, но все же прокомментирую, что имелось ввиду. У нас в компании изначально так сложилось, что автотестов не было и при внедрении были сложности организационные, касающиеся встраивания во флоу работы, понимания зон ответственности, ускорения исправления падающих тестов и ряд других проблем, которые мешали встроить в пул реквесты. Оповещений о том, что упал тест или прошли тесты было крайне много в каналах оповещения и потому реакция на исправление была долгой. Решение, которое в итоге предложили для этого проекта связано еще и с архитектурой самого проекта - ему больше 8 лет в продакшене, проект на микросервисной архитектуре, довольно много неоптимизированных участков кода со стороны бэка.
Варианты запуска автотестов с пул реквестами отлично работают на меньших по масштабу проектах в компании.
Как мне кажется совсем не раскрыта тема почему вы все же выбрали JS.
мы остановились на JavaScript из-за простоты и наиболее низкого порога входа для начинающего специалиста
Со стороны больше читается, что в компании есть/был специалист, а точнее фронтендер, который сильно топил за JEST, поэтому вы его и выбрали. А этот специалист, скорее преследывал реализацию своих амбиций.
На самом деле нет. Со стороны фронтендеров не было ребят, которые высказывали свои предложения.
Как я уже говорил самым главным фактором для нас был минимальный уровень необходимых знаний и сил, чтобы запустить автоматизацию QA специалистами. Кроме того, мы изначально постарались заложить единообразие API и e2e автотестов. Единообразие в части языка программирования.
Хочу отметить, что в статье главной задачей было поделиться тем опытом, который накопился за полгода работы, не пытаясь никого агитировать на использование стека технологий. Каждый, конечно же, вправе сам принять решение и выбрать фреймворк и стек технологий в зависимости от той ситуации, что есть на проекте, его стадии и имеющихся QA-специалистах.
Изи-пизи автотесты на JavaScript