Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи

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

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

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

Продуктовая стратегия

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

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

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

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

То, что будет автоматизировано, и то, как именно, будет разным в каждом из этих трех случаев.

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

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

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

Оценка рисков

Тестировщики, рассуждая о выгодах автоматизации, часто концентрируются на количестве багов, которые она находит, или на сбереженном для разработки времени. Мы говорим о выгодах, значимых именно для нас, но это необязательно верно для менеджера.

Согласно отчету World Quality Report за 2016 год,  главная причина для инвестиций в тестирование – это защита корпоративного имиджа. Тестирование – это одна из форм страхования репутации. Это способ снизить риски.

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

В сети множество ресурсов, которые помогут вам обсудить риски проекта. У Джеймса Баха есть целая статья, Heuristic Risk-Based Testing, описывающая подход к оценке рисков. Она содержит список вопросов, которые имеет смысл задавать. Я сама использую ее, когда обсуждаю риски.

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

Как же решить, что автоматизировать, на техническом уровне?

Объективные критерии

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

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

Когда же дело касается субъективных метрик, очень трудно сформулировать точные критерии для принятия решений. Представьте, что вы стоите перед построенным домом и решаете, достоин ли он звания "Дом года". Процесс принятия решений в этом случае (как минимум частично) субъективен.

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

Распространенный способ, помогающий упростить выявление объективных критериев – это синтаксис Gherkin, создающий примеры при помощи вводных слов "Если… Когда… Тогда…".  Команда, разрабатывающая такие сценарии совместно через BDD или Three Amigos, получит более устойчивые автотесты, нежели человек, идентифицирующий сценарии в одиночку.

Повторяющиеся задачи

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

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

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

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

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

Альтернативные издержки

Автоматизация всегда внедряется за счет еще чего-нибудь, что вы могли бы в это время сделать. В 1998 году Брайан Мэрик написал статью "В каком случае тест нужно автоматизировать?". В заключении этой статьи говорится следующее:

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

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

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

Организационные изменения

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

Продуктовая стратегия меняется вслед за изменениями рынка. Риски появляются и исчезают. Характеристики продукта меняются – и вместе с ними изменятся объективные характеристики и повторяющиеся задачи. Доступное вам время и альтернативные издержки – тоже величины непостоянные.

Решая, что именно автоматизировать, учитывайте темп и природу грядущих изменений.

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

А может, они внезапны, как погода? Вы предполагаете, что будет дождь, но понятия не имеете, насколько сильный, и когда именно он пойдет (а может и вообще не пойти).

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

Сотрудничество

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

Очень важно прийти к консенсусу насчет масштаба автоматизации вместе со всеми.

Сотрудничество не означает, что вам нужно созывать совещания для того, чтобы изложить свои мысли. Это не односторонний процесс. Не только предлагайте свое мнение, но и позволяйте другим высказаться. Явно донесите, что, с вашей точки зрения, подходит для автоматизации, а что нет. Уверенно объясните ваши резоны, но будьте готовы к иным мнениям и новой информации.

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

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