Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

"Какие тесты автоматизировать" – неверный вопрос

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

Учитывая это, неверно говорить о том, "какие тесты автоматизировать" – такой вопрос предполагает, что мы автоматизируем то, что уже делаем вручную.

Городские легенды

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

• "Автоматизируйте скучную часть тестирования".

Нет такого понятия, как "скучная часть тестирования". Если вам скучно тестировать, почему вы все еще этим занимаетесь? У вас просто-напросто не хватает внутренней мотивации, и ни один инструмент, ни один фреймворк не решат эту проблему.

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

• Тестирование, основанное на риске
• Тест-фрейминг
• Сессионное тестирование
• Тест-туры
• Тест-эвристики
• "Автоматизируйте повторяющиеся задачи".

Тут тоже есть внутренняя проблема – почему вы повторяете тесты? Потому, что вы хотите убедиться, что результат какого-либо действия стабилен после N повторений, или потому, что вы понятия не имеете, что вы тут, черт возьми, делаете?

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

• "Автоматизируйте регресс"

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

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

Правильный вопрос – "Как я могу помочь тестированию?"

Если мы отвлечемся от городских легенд, то правильной задачей автоматизации теста станет помощь (себе или коллегам-тестировщикам) с задачей, которую трудно выполнить вручную. Итак, как мы узнаем, что беспокоит наших коллег? Да просто пойдем и спросим! Сотрудничество – основа успеха. В статье про отсутствующее звено между тестированием и автоматизацией я говорил о том, что нам совершенно необязательно превращать всех и каждого в исследовательского тестировщика или автоматизатора, но нам сильно поможет, если тестировщики и автоматизаторы будут разговаривать друг с другом и делиться идеями о том, как они могут принести друг другу пользу. В любом проекте тысячи небольших автоматизируемых задач, с которыми автоматизаторы могут помочь, создав для них инструментарий и облегчив жизнь своих товарищей:

• Создание тестовых данных.
• Автоматическая настройка окружения.
• Автоматизированный деплой.
• Улучшение тестируемости продукта.
• Создание предусловий в продукте.

Как можно отметить, все это имеет мало отношения к тестированию как таковому, но очень ему помогает.

А что насчет тестов?

Я сказал, что автоматизация полезна для тестирования, так чем же именно?

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

Переменные:

• Полученная информация.

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

• Вложения денег, времени и сил.

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

• Краткосрочная выгода.

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

• Долгосрочная выгода.

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

• Стабильность.

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

Визуализация

Как выглядит плохой тест, представленный в разрезе этих переменных?

Плохой тест

Хорошим примером плохого теста будет то, что я называю скромной демонстрацией. Такие тесты обычно занимают много времени на разработку, потому что выглядят как длинные сценарии с переключением экрана и всякими подобными штуками. У них есть некоторая краткосрочная ценность, но на длинной дистанции выгода почти нулевая – они недостаточно агрессивны, чтобы упасть. Мы не получаем почти никакой информации, однако они крайне стабильны – они никогда не упадут, у них просто нет шанса на падение.

Нестабильный тест

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

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

Хороший тест

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

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

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