Советы для молодых тестировщиков или как составлять тест - кейс =)

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

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

В тест – кейсе желательно избегать зависимостей от других тест – кейсов.

Тест кейс в основном состоит из

*Основных параметров

- id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).

- Автор – имя и фамилия тестировщика, который написал тест – кей.

- Название — краткое описание сути проверки.

- Предусловие – предварительные шаги.

- Шаги – что нужно сделать, чтобы что-то получить.

- Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =).

- Фактический результат – то, что получилось в итоге действия в шаге.

- Постусловия – заключительные шаги.

- Статус (pass/ fail/ block) – проставляется после прохождения тест – кейса.

            * Дополнительных

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

- Критичность – это атрибут, характеризующий влияние на работоспособность приложения.

- Итерация/сборка/проект.

- Тег.

- Ссылка на тест-сьют, юзерстори и тд.

- Вложения.

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

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

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

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

Хороший тест должен удовлетворять следующим критериям:

- существует обоснованная вероятность выявления тестом ошибки

           Описывая тест – кейсы, проанализируйте все возможные  варианты сбоя программы или ее неправильного поведения. Удобнее сначала составлять чек-лист, а потом описывать шаги.

- набор тестов не должен быть избыточным

- тест должен быть наилучшим в своей категории

- он не должен быть слишком простым или слишком сложным

       Но не стоит составлять огромный и сложный тест. Его трудно понять, выполнить, а главное тяжело определить ошибку.

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

В процессе формулирования целей тестирования следует пользоваться следующими рекомендациями:

• Четко сформулировать назначение каждого теста.

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

• Указать, что должен делать тест, но в то же время не следует объяснять, как это достигается — это должно быть указано в тестовом случае.

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

Используйте методы тестового проектирования:

   ·       Методы тестирования черного ящика

- Тестирование класса эквивалентности

- Тестирование граничных значений

- Паровое тестирование

- Тестирование таблицы принятия решений

- Тестирование состояния

- Тестирование анализа домена

    ·       Методы тестирования белого ящика

- Тестирование потока управления

- Тестирование потока данных

    ·       Основанный на опыте: предугадывание ошибок

    ·       Используйте эвристику и мнемонику

- Использование эвристики тестирования

- Использование контрольной мнемоники

- Использование матриц

- Использование матрицы рисков

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

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

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