Home

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Уровень 0. Автоматизация прогоняется по запросу

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

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

Иногда мы шутим, что это не «автоматизация» - всегда, всегда есть некий уровень ручного труда, связанный с ее запуском. Ручной труд при падениях. Ручной труд при успехе. Перемотка ряда промежуточных действий при помощи автоматизации.

Уровень 1. Ночная тест-автоматизация

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

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

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

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

Уровень 2. Тест-автоматизация при слиянии с мастер-веткой

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

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

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

Уровень 3. Тест-автоматизация на кончиках пальцев разработчика

Цель, к которой мы теперь стремимся – это перемещение всей тест-автоматизации в инструментарий производительности разработчика. Это нельзя сделать без наличия некоторого качества (разного уровня), и если у нас есть релевантная обратная связь – нам нужен контроль над запуском автоматизации и соглашения о ее прогоне, оптимизированные так, чтобы разработчики могли с пользой эту обратную связь применить.

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

За последние два года я работала со множеством команд. Одна, уровня 0, переехала на уровень 1. Одна команда уровня 2 переехала на уровень 3. Большинство команд как находилось на уровнях 1 и 2, так и остались там. А одна команда была на минус первом уровне (ноль автоматизации), но за последние месяцы прошла нулевой уровень и сейчас дошла до первого.

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