Тест-кейс тест-кейсу рознь!

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

Доработка кейсов своими силами (силами автотестеров) в процессе автоматизации – это сизифов труд.

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

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

По отзывам самих ручных тестировщиков, им стало намного легче «въезжать» в работу, как с нуля, так и после перерыва, вызванного переходом на проверку другой функциональности. Тест-кейсы стали настолько понятными и легкими для восприятия, что их мог успешно пройти даже человек, далекий от тестирования.

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

Итак, начнем урок.

Автоматизированное тестирование (automated testing, test automation) — набор техник, подходов и инструментов, позволяющий исключить человека из выполнения некоторых задач в процессе тестирования.

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

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

Но автотест – это программа и в отличие от человека она не обладает способностью к интуитивному пониманию формулировок. А разработчики автотестов обоснованно предпочитают не расходовать свое время, чтобы додумывать тест-кейс в разрезе технической составляющей, а зачастую и гадать, что же тут (в тест-кейсе) имелось ввиду? У них полно своих задач.

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

Нюансы тест-кейсов под автоматизацию

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

• Выше сказанное относится и к тестированию на различных платформах.

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

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

• Также, не допускается ветвление в шагах или ожидаемом результате (трактовка должна быть однозначной).

Данные для тестирования, а именно способы их получения — это одна из отличительных черт автотестов. Если для ручного прогона тестов 3-10 раз можно обойтись ручной подготовкой данных, то при автоматизации, когда требуется многократное выполнение (50-500 раз) с различными входными параметрами ручная генерация становится затруднительной.

В подобных обстоятельствах источником данных может выступать:

• набор данных, извлекаемых случайным образом;

• алгоритмически сгенерированные данные;

• данные, полученные из внешнего источника (база данных, веб-сервис и пр.);

• данные, собранные в ходе использования системы реальными пользователями;

• ручное создание данных (если требуется небольшое количество и писать алгоритм генерации не с руки).

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

Соответственно, в тест-кейсах необходимо указывать критерии для поиска (подготовки) тестовых данных с нужными свойствами.

Требования к тест-кейсам

Формальные требования:

• Форма глаголов – использовать безличную форму глаголов (например: «нажать» вместо «нажмите»);

• Именование элементов – применять технически верные названия элементов;

• Терминологическая единообразность – называть одни и те же элементы одинаково;

• Оформление – следовать принятому на проекте стандарту оформления тест-кейсов;

Структура и содержание:

• Название тест-кейса – формулировать заголовок информативно и относительно уникально, чтобы четко понимать, какую ситуацию отражает тест-кейс и не путать с другими;

• Данные для тестирования – готовить исходные данные без использование тестируемого приложения;

• Критерии данных – указывать критерии для поиска или создания тестовых данных, желательно с примерами подходящих значений;

• Избегание «харкодинга» – не использовать жёстко заданные значения (логины, пароли, названия файлов и пр.);

Выполнение тест-кейса:

• Целевая направленность – каждый шаг должен соответствовать основной цели тест-кейса (во-избежание ситуации, когда проверяешь не то, что требуется в действительности);

• Детализация шагов – подробно описывать шаги с указанием конкретных названий полей, кнопок, операций и пр.;

• Нумерация шагов – присваивать порядковые номера всем шагам независимо от их количества (иначе возрастает вероятность в будущем случайно пришпандорить описание этого шага к новому тексту);

• Автономность – недопустимо ссылаться на другие тест-кейсы;

Результаты и документация:

• Ожидаемый результат – указывать ожидаемый результат для каждого шага;

• Визуализация – допустимо добавлять скриншоты для демонстрации ожидаемого отображения;

• Линейность — исключать ветвления в шагах и результатах;

• Атомарность – каждый тест-кейс должен проверять только один сценарий.

Пример

1) Необходимо проверить успешный вход пользователя в систему, к примеру, под ролью «Администратор».

ПЛОХО:

ХОРОШО:

2) Необходимо проверить вход пользователя в систему с невалидными учетными данными. Для примера можно использовать роль «Администратор».

ПЛОХО:

ХОРОШО:

3) Необходимо проверить отображения ошибки при некорректном заполнении полей на странице «Регистрация»

ПЛОХО:

ХОРОШО:

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

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

Идеал недостижим, но хочется верить, что в его направлении был сделан шаг!