Зачем всегда запускать все UI тесты?

Эта статья не для вас, если время прогона вашего полного набора тестов меньше 1 часа, и все тесты всегда проходят, за исключением тех, которые не работают по известным вам причинам. Если же у вас не так все гладко, то давайте, базируясь на примере, разбираться как же можно ускорить запуск тестов и уменьшить затраты времени на запуск «лишних» тестов.

Возьмем ситуацию, когда у вас есть 1000 UI тестов, предположим они гоняются 100 минут (у кого-то это может быть и 10 часов, так как UI тесты медленные по определению). Так же предположим, что только 10% тестов падают, из которых только 5% падают всегда, остальные - время от времени (не всегда все так стабильно как хотелось бы).

Итак, у нас есть:

1. 900 тестов, которые всегда проходят
2. 50 нестабильных
3. 50 поломанных

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

Итого, мы тратим 100 минут на запуск, делаем ~3 перезапуска упавших тестов, чтобы убедиться, что нестабильные проходят тоже, и что 50 падают постоянно. Далее тратим ~3 часа, проверяя вручную упавшие тесты, чтобы найти 5 реальных багов. При этом мы не закладываем время на починку 45 тестов, падающих по причине их поломки.

100 + 3 * 10 + 3*60 = 310 минут = ~ 5 часов чистого времени (в реальных условиях – это целый рабочий день)

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

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

1. Анализируйте историю

Если вы не храните историю запусков тестов, то советую начать это делать, так как вы удивитесь, обнаружив, что половина ваших тестов не падает вообще. А значит, нет необходимости запускать их каждый раз.

Замечание: Выделите нестабильные тесты и постарайтесь их починить, так как на них тратится львиная доля вашего внимания и времени.

2. Анализируйте изменения

Проводите тщательный анализ изменений в приложении перед запуском тестов. Вам не всегда понадобится запускать полный набор, если поменялись лишь некоторые ссылки или всего одна форма в приложении. Получится, что вместо 1000 тестов, можно запустить всего 100 или даже меньше.

3. Разделяйте тестовые наборы

Разработайте гибкую систему конфигурации тестовых наборов. Например:

1. Полный тест (это все что у вас есть – напоминает стрельбу из пушки по воробьям)
2. Смоук тест (только поверхностная проверка важнейшей функциональности)
3. Тесты на отдельную функциональность (формируется каждый раз перед запуском и покрывающий все, что затрагивает конкретная функциональность, а не только саму функцию)
4. Только успешные (если уже там что-то падает, то это явный косяк)
5. Нестабильные (гэмблинг 50/50 – не пройдут, перетестируем руками)
6. Постоянно падающие (запускаем на всякий случай)

4. Приоритезируйте запуски тестовых наборов

Нет смысла гонять полный тест каждый день – лишняя трата времени и ресурсов. Нет смысла в первую очередь гонять нестабильные или постоянно падающие тесты. Могу предложить вам следующую последовательность и периодичность для запуска тестов:

1. Смоук тест – запуск после каждой сборки на всех ветках.
2. Тесты на отдельную функциональность – перед слиянием в основную ветку (прошли – мержим, не прошли - исправляем)
3. Только успешные – раз в неделю на основной ветке продукта.
4. Нестабильные запускайте каждый день на основной ветке продукта и старайтесь их чинить. При этом ведите историю запусков и со временем переводите исправленные в «только успешные».
5. Постоянно падающие исключите из всех тестовых наборов, создайте таски на их починку и после исправления переводите их в соответствующую группу.
6. Полный тест запускайте по необходимости и во время тестирования релизных версий.

5. Держите тестовые наборы в актуальном состоянии

Очень важно содержать основной набор тестов в работающем состоянии, так как именно он показывает состояние вашего приложения и тестового набора. Чем больше неработающих тестов, тем сложнее его понять. Если у вас появляются неработающие тесты, починить которые невозможно в силу серьезных причин (таких как блокирующий баг приложения, недостаток инструмента, необходимость переработать сценарий или что-то подобное), то незамедлительно переводите их в «постоянно падающие». Большое количество падающих тестов может стать свидетельством того, что в приложении много багов или тесты не поддерживаются в актуальном состоянии. Первая причина показывает, что не справляются разработчики, вторая – тестировщики.

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