Home

Автор: Сергей Морет (Serghei Moret)

Оригинал статьи: http://www.waysoftesting.com/2017/06/05/often-run-automation/

Перевод: Ольга Алифанова

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

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

Ночные билды

Судя по моему опыту, ночные билды – очень распространенное решение, использующееся в большинстве проектов. Почему? Да потому, что этот подход покрывает, плюс на минус, большую часть того, что необходимо компании от автотестов. К тому же это наиболее простое решение, не требующее особых ресурсных затрат. Можно не изобретать велосипед, а пользоваться готовым решением.

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

Это очень хороший метод, но чуть дальше я продемонстрирую, почему он не всегда достаточен.

Релизные билды

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

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

Ручной запуск

Этот подход не сильно отличается от прогона тестов для релизных билдов. Однако если релизный прогон подразумевает некоторую автоматизацию процесса запуска, в этом случае вы просто стартуете тесты вручную, когда вам это необходимо. Подходит для очень маленьких проектов с редкими релизами.

Запуск автотестов по пулл-реквесту

Вот мы и добрались до части статьи, в которой я объясняю, почему прогон тестов для ночных билдов недостаточен для ряда компаний, включая ту, где я работаю сейчас. Почему же мы особенные, и почему ночные прогоны не срабатывают для нас?

Одна из причин – это большое количество команд и разработчиков, трудящихся над одним и тем же приложением, что создает проблемы для автоматизации.

1. Автотесты начинают ломаться. При 10-20 мержах в день становится трудно разобраться, что именно привело к падению тестов. Все, чья зона ответственности посыпалась, начинают копаться в автоматизации и теряют время, потому что виноватыми в падении могут быть совершенно другие люди.
2. Разработчики заливают все в последний момент, прямо перед код-фризом. Это стало реальной проблемой, потому что каждый код-фриз ведет к куче работы по исправлению тестов до начала релизного тестирования.

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

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

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

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

Заключение

Я попытался рассмотреть проблему с разных сторон и дать вам представление о трудностях, с которыми вы можете столкнуться, и том, как мы решали их в нашей компании.

Обсудить в форуме