Home

Автор: Андрей Козлов

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

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

Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.

Введение

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

Юз-кейс – сценарий использования. Последовательность действий, которую мы можем осуществлять с помощью приложения или системы. (http://ru.wikipedia.org/wiki/Сценарий_использования)

Тест-кейс – тестовый сценарий. Последовательность действий (юз-кейс) с определёнными входными данными.

Приоритет – сравнительная оценка важности юз-кейса или тест-кейса для процесса тестирования.

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

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

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

Функциональные требования естественным образом можно поделить на части. Для начала на отдельных приложений или крупные компоненты, а затем на юз-кейсы. Наши требования – не исключение. Приложение у нас ровно одно, а в нём ы можем выделить два юз-кейса: фильтрацию и добавление. Можно сказать, что кроме этого приложение должно корректно запускаться, корректно закрываться, и это тоже будут юз-кейсы, но мы их пока в расчёт не берём из-за их неспецифичности.

Часть первая. Юз-кейсы и тест-кейсы

Для начала зафиксируем наши юз-кейсы:

1. Фильтрация
2. Добавление

Сейчас же искушённый читатель должен заметить то, чем грешат в своих тест-планах новички - отсутствие конкретных действий и конкретных данных. Уточним:

1. Выбираем в комбо-боксе вид животного, вписываем в текст-бокс его имя, нажимаем «Найти»
2. Нажимаем «Добавить», выбираем в комбо-боксе вид животного, вписываем в текст-бокс его имя, нажимаем «Сохранить»

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

Предположим, что исходная точка, - это 5 записей: собака Тузик, попугай Тузик, кошки Васька, Мурка, Матроскин.

В юз-кейсе 1 мы варьируем как входные данные вид животного (комбо-бокс) и его имя (текст-бокс). Для каждого из вариантов имеется определённый ожидаемый результат. Для удобства составим таблицу данных. Не буду вдаваться в правила использования типов данных и граничных значений, так как большинство читателей с ними знакомо.

1. Фильтрация

Часть вторая. Приоритеты.

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

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

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

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

Подведение итогов

Основной тезис: тест-кейсы – это юз-кейсы, дополненные входными и выходными данными.

---

Итоги:

• Тест-план состоит из двух частей: списка юз-кейсов и таблиц данных
• Каждая запись в таблице данных является тест-кейсом
• Все юз- и тест-кейсы имеют приоритеты
• Таблицы неприхотливы и удобны в использовании

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

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