Пользовательские истории, Тестовые случаи, Тестовые Наборы и Планы тестирования

Всем привет!

Сегодня мы поговорим о таких рабочих элементах как Пользовательские истории, Тестовые случаи, Тестовые Наборы и Планы тестирования.

Требования (Пользовательские истории, User Story)

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

План тестирования (Test Plan)

В моем словаре понятие «План тестирования» имеет два определения – в широком и узком смысле. Далее в своих статьях я буду использовать это понятие в его узком смысле и, кроме того, в контексте используемого инструмента – Microsoft Test Manager (и Test Hub в составе TFS).

План тестирования (Test Plan) связан с конкретным командным проектом и состоит из одного или нескольких Наборов тестов (Test Suite); каждый такой набор, в свою очередь, состоит из одного или нескольких Тестовых случаев (Test Case).

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

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

MTM позволяет настаивать некоторый фильтр (запрос), согласно критериям поиска которого из всего множества Тестовых случаев выбираются лишь удовлетворяющие конкретным условиям Тестовые случаи (например, статус автоматизации которых равен «Автоматический»). Тестовые случаи, удовлетворяющие условиям фильтрации, и будут включены в Набор тестов на основе запроса.

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

Как видно из рисунка, основным компонентом Плана тестирования является Тестовый случай.

Тестовый случай (Test Case)

В своем словаре я уже приводила определение понятия Тестового случая.

Шаг тестового случая представляет из себя структуру вида:

Action → Expected Result → Test Result

Например, «Нажать на кнопку «Войти» → «Осуществляется вход в систему под текущим Windows-пользователем» → Passed (Пройдено)

Структура тестового случая, как правило, имеет вид:

Precondition → Steps → Post Condition

Каждый для себя определяет свои принципы проектирования тестовых случаев. В Интернете можно найти немало статей на эту тему.

При проектировании тестовых случаев я придерживаюсь следующей структуры:

Precondition	·        Инициализация приложения и тестовых данных ·        Перевод системы в требуемое состояние
Steps	·        Шаги теста и их ожидаемые результаты
Post Condition	·        Корректное завершение работы приложения

Структура Плана тестирования (как Рабочего элемента)

Если говорить о структуре Плана тестирования, то я использую следующий подход:

Тестируемое приложение (точнее, его функциональность) разбивается на части (модули). Наши приложения имеют несколько разделов, поэтому чаще всего я провожу разбиение функциональности приложения именно по его разделам. Таким образом, в моем Плане тестирования совершенно естественно появляются Наборы тестов, каждый из которых соответствует разделу приложения. А каждый такой набор содержит Тестовые случаи, проверяющие функциональность в рамках соответствующего раздела. По этим же соображениям становятся понятными и причины используемой мной структуры Тестового случая. Чтобы добраться до проверяемой функциональности в каждом тесте, необходимо запустить приложение, перейти в соответствующий раздел, привести приложение в состояние, пригодное для проведения тестирования целевой функциональности (это блок Precondition), далее выполняются непосредственные шаги теста (блок Steps), далее осуществляется корректное завершение работы приложения (блок Post Condition).

Как это выглядит в разделе Plan инструмента Microsoft Test Manager:

Всем добра и до скорой встречи!