tестирование dot com

• есть еще и четвертые, и пятые случаи.

Вот концептуальная вещь:

• тест-кейс нужен для сравнения фактического результа-

та с ожидаемым результатом;

• тест-комплект — это логическая оболочка для хране-

ния тест-кейсов;

• тест-план — это документ, обобщающий и координи-

рующий тестирование.

Исполнение тестирования. Стадия 1: тестирование новых фича

267

Я обычно ограничиваюсь тест-комплектами и создаю тест-план,

если возглавляю проект с участием других тестировщиков.

Давайте рассмотрим элементы, которые вы можете использовать

в тест-планах.

Кстати, вовсе не обязательно использовать все элементы:

1. Вы можете взять элементы (и/или идеи из них) и интегрировать их

в свои тест-комплекты;

2. Вы можете использовать тест-план в усеченном виде.

Итак...

ЭЛЕМЕНТЫ ТЕСТ-ПЛАНА

1. Название тест-плана, имя автора и номер версии.

Например

«Тест-план проекта "Новые алгоритмы для поиска"». Автор Т. Чере-

мушкин. Версия 2.

2. Оглавление с разделами тест-плана:

Например

Введение

стр. 2

Документация с требованиями к ПО стр. 3 и

т. д.

3. Введение, в котором мы приводим информацию о сути и исто-

рии тестируемого проекта.

4. Документация с требованиями к ПО — здесь мы перечис-

ляем имена, номера и приоритеты спеков и/или другой докумен-

тации, определяющей тестируемые фича.

5. Фича, которые будут тестироваться, перечисляем и, если

нужно, комментируем. Каждой фича назначается приоритет.

6. Фича, которые НЕ будут тестироваться, перечисляем и объ-

ясняем, почему НЕ будут тестироваться.

Например,

частью спека #9172 "Улучшение безопасности платежных транзакций"

являются требования к скорости работы веб-сайта (performance). До-

пустим, у нас нет ни специалиста, ни ПО для тестирования скорости

работы, и если мы не собираемся их нанять и приобрести, то указываем,

что перформанс тестироваться не будет, так как нет ресурсов.

268

Тестирование Дот Ком. Часть 3

7. Объем тестирования — виды тестирования, которые мы бу-

дем проводить, и разъяснения к ним.

Например

"Системное тестирование будет исполняться для проверки всего флоу

оплаты, начиная от добавления книги в корзину и заканчивая про-

веркой значений базы данных и подтверждением от тест-машины

вендора".

8. Тест-документация — перечисление тест-документации, ко-

торая должна быть создана для данного проекта

Например

"Тест-комплект по тестированию опека #1288.

Тест-комплект по тестированию спека #3411".

9. Тест-тулы — функциональности тест-тулов, которые должны

быть созданы для тестирования проекта.

10. Критерий начала/завершения — те самые критерии, о кото

рых мы говорили минуту назад:

• критерий начала подготовки к тестированию;

• критерий завершения подготовки к тестированию;

• критерий начала исполнения тестирования;

• критерий завершения исполнения тестирования.

11. Допущения — список допущений, которые мы сделали при

составлении данного тест-плана и которые сделаем при тестиро

вании.

Например,

мы допускаем (предполагаем), что код будет заморожен в срок, без

задержки.

12. Зависимости — список вещей (с пояснениями), от которых

зависит та или иная часть тестирования.

Например,

покупка новых тест-машин,