Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Конечно, нет! Наша автоматизация должна прогоняться за секунды, или хотя бы менее, чем за десять минут. Ведь верно? Ведь правильно? Вставьте сюда мем с Падме и Анакином. 45 минут – это явно антипаттерн и всегда плохая идея, правда же?

Все вы знаете, не так ли, что бывает, когда я задаю подобные абсолютные вопросы, да?

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

• «Быструю» обратную связь насчет того, что скрипт проверяет;
• Возможность запускать тесты небольшими группами, чтобы напрямую целиться в конкретные функциональности или исправления;
• Упрощение параллельного запуска независимых скриптов;
• И, уверен, многое другое.

Если это возможно, то это здорово! Я бы не отказался пожить в таком окружении разработки, как, полагаю, и многие из вас.

К сожалению, не все так привилегированны. Множество команд пытается развиваться в экосистеме, в которой отсутствует тестируемость и, безусловно, автоматизируемость. Во многих подобных экосистемах команды не хотят достигать ситуации, когда автоматизируемость станет ценностью. Они думают, что изменения в коде приложения – это риск, и они правы! Добавление тестируемости и автоматизируемости, то есть изменений в код приложения, это риск… и затраты! Итак, если мы не можем организовать автоматизацию «быстрого потребления», то что же делать?

Мы приносим пользу изо всех сил!

Как-то у меня был клиент, производящий компьютерное железо. Физический процесс поставки компонентов проходил через ряд «рабочих станций», каждая из которых выполняла определенный набор производственных задач, но эти задачи зависели от успешности выполнения задач предыдущей станции. Задача N+1 не могла, и не должна была начаться, если задача N провалена.

Их лид автоматизации была очень умным человеком. Она была самоучкой, но создала отличный набор автоматизированных тестов. Она использовала фреймворк с открытым исходным кодом для создания набора, и ее компания обнаружила, что эти тесты приносят пользу. Автоматизированные скрипты проталкивали «тикет» ПО через разные рабочие станции, чтобы убедиться, что в идеальном сценарии все сработает; другой тестировщик занимался более «хитроумным» тестированием.

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

Я предложил им другой подход – поработать с API приложения, чтобы хоть немного сократить время прогона. Возможно, мы сможем загрузить данные для станции 3 и напрямую перепрыгнуть к станции 4. Но нет. Их приложение этого не позволяло. Я предложил изменить приложение, чтобы оно стало тестируемым и автоматизируемым. Снова нет. По ряду причин (как валидных, так и не особенно) это было невозможным (помните, я выше сказал – команды не хотят попадать в эту ситуацию).

Итак, их лид приносила пользу изо всех сил; она нашла способ ее приносить.

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

Итак, ужасно ли, если прогон теста занимает 45 минут? Для ответа на такой вопрос надо изучить контекст. В этом случае было бесспорно, что в этом конкретном контексте иначе поступить нельзя. Конечно, параллельно ее подходу я, она и ее руководитель работали с командой разработки, убеждая их внедрить интерфейсы, позволяющие автоматизации начинаться на станции Х и затем переходить к Х+1, но это заняло бы месяцы. Тем временем часть их тестов теперь прогонялась за десятки минут, а не десятки часов.

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

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