Автор: Энджи Джонс (Angie Jones)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

1. Сотрудничайте с другими участниками

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

Бизнес

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

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

Тестировщики

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

Разработчики

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

Этот мокап служит контрактом между разработчиком и инженером-автоматизатором.

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

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

2. Автоматизируйте стратегически

Если разрабатываемая фича относится к UI, вполне естественно автоматизировать ее на уровне UI, чтобы убедиться, что UI ведет себя так, как должен.

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

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

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

1. Поиск продукта.
2. Нахождение продукта среди результатов поиска.
3. Клик на продукте.
4. Клик на кнопке "Добавить в корзину".
5. Клик на корзине.
6. Клик на кнопке "Удалить" для продукта.
7. Проверка корзины.

Автоматизация шагов 1-5 через навигацию по UI не нужна. Используя API для добавления продукта в корзину, вы пропустите шаги 1-4. А если приложение будет стартовать прямо на странице корзины, то можно пропустить и шаг 5.

Сценарий станет таким:

1. Вызов API для добавления продукта в корзину.
2. Открытие страницы корзины.
3. Клик на кнопке "Удалить" для продукта.
4. Проверка корзины.

Это куда быстрее автоматизировать, чем первый вариант. Чем меньше кода вам нужно писать, тем выше шанс, что вы успеете это завершить в текущем спринте.

3. Работайте постепенно.

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

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

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

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

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

К примеру, допустим, что в первом спринте стоит задача создать UI для редактируемого профиля, но кнопка "Создать профиль" еще ничего не делает.

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

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

Улучшенный критерий готовности

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

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

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