Home

Автор: Пол Меррил (Paul Merrill)

Оригинал статьи: https://techbeacon.com/5-ways-simplify-your-automated-test-cases

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

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

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

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

1. Сокращайте объемы

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

Объем тест-кейса должен зависеть от его предназначения. В исследовательском тестировании (термин введен Кемом Кейнером в 1984 году, концепция объяснена Элизабет Хендриксон в книге Explore it!) сначала определяется чартер для сессии ручного тестирования. Чартер может быть ограничен фичей или набором фич, которые вы хотите исследовать. Так как это исследовательское тестирование, вы экспериментируете с фичами: длинные последовательности экспериментов, различные последовательности действий и их вариаций помогают исследовать приложение и искать проблемы.

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

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

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

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

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

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

2. Тест должен падать по одной и только одной причине.

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

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

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

3. Определите, что за что отвечает, и придерживайтесь этого.

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

4. Спросите себя, какая наиболее простая штука, возможно, сработает?

Уорд Каннигам и Кент Бек говорили о прогрессе в программировании, но мне нравится эта цитата в приложении к автоматизации тестирования: "Учитывая все, что мы уже знаем, какая наиболее простая штука, возможно, сработает?"

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

5. Избегайте ненужных зависимостей

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

Будьте проще

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

Эти простые шаги неоднократно помогали мне. Они могут помочь и вам тоже.

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