3.2. Тестовые объекты и тестовые данные

Вышеприведенный тесткейс должен проверять редактирование телефона пользователя. Однако же первые три шага не относятся к редактированию телефона. Это вспомогательные шаги по созданию пользователя - мы создаем тестовый объект, объект, который мы будем использовать в тестах. Целесообразно вынести эти шаги в отдельную секцию "Setup", и описать более кратко:

Setup:

Создать пользователя.

Шаг 1. Открыть список пользователей.

Шаг 2. Выбрать пользователя в списке, кликнув на его логин.

Шаг 3. Нажать кнопку "Редактировать"

шаг 4. Ввести номер телефона в поле "Домашний телефон"

шаг 5. Нажать кнопку ОК

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

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

Часто один и тот же тесткейс следует выполнять с разными тестовыми данными. Например, если программа должна уметь показывать файлы в формате BMP, JPG и GIF, логично написать один тесткейс и указать в специальной секции, что выполняться он должен с использованием трех файлов разного формата. По аналогии с программированием - мы выносим название формата в параметр процедуры. Такой тесткейс называется data-driven - управляемый данными.

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

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

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

3.3. Идентификатор тесткейса, приоритет, время прохождения

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

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

Целесообразно также указывать планируемое время прохождения тесткейса (при его создании) - для оценки трудозатрат на тестирование. Это время может быть скорректировано с учетом реальной истории прохождения. Например, если первоначально планируемое время составляло 10 минут, а реально кейс был пройден за 30 минут, это повод узнать у тестировщика, в чем была загвоздка и по результатам либо попросить его работать в 3 раза быстрее, либо скорректировать оценку.