Как должен выглядеть хороший тест-кейс?
С тем, что тест-кейсы призваны помочь установить соответствие тестируемого функционала заявленным требованиям, мы уже разобрались в прошлой статье. Теперь самое время понять, что же представляют из себя подобные тестовые сценарии.
Проверенный шаблон
Наша практика показывает, что сценарии должны быть написаны по определенному шаблону. Это позволяет облегчить процесс работы с ними по проекту. Хороший тестовый сценарий обязательно включает в себя:
- Описание – отражает цель проверки.
- Предусловие (предварительные шаги) – содержит список шагов, которые необходимо выполнить до начала теста.
- Шаги – метод выполнения теста, описанный по шагам.
- Ожидаемый результат – предусмотренное поведение системы после прохождения по шагам.
- Статус кейса – проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому.
Перечисленные пункты – обязательный минимум. Однако в некоторых случаях целесообразно расширение набора составляющих. Так, в сценариях могут появляться такие пункты, как глубина покрытия ТК, приоритет проверки, флаг включения в автотесты, id обнаруженных багов, связанных с проверкой и прочее.
Обязательные требования к тест-кейсам
- Отсутствие зависимостей друг от друга. Поскольку тесты могут дополняться, меняться, терять свою актуальность и удаляться – как в таком случае поступать с тестами, на которые ссылались эти кейсы? Кроме того, взаимосвязь может ввести в заблуждение, будто работа продукта соответствует ожиданиям.
- Четкие формулировки и высокая вероятность обнаружения ошибки.
- Наличие детальной, но не избыточной информации. Если проверке подлежит процесс авторизации, тест-кейс должен содержать логин и пароль.
- Легкая диагностика ошибок. Обнаруженная ошибка должна быть очевидной.
- Исследование соответствующей (непосредственно той, что нужно) области приложения, выполнение нужных действий.
Углубиться в проект мало, или Кому поручить написание тест-кейсов
Создание тест-кейсов – довольно сложный процесс, который требует не только основательного углубления в проект, но и определенных навыков. И потому тест-дизайнеры, в чью компетенцию входит эта работа, должны:
- Налаживать эффективную коммуникацию с разработчиками, менеджерами и пользователями для сбора данных по проекту и проведения QA-анализа.
- Правильно расставлять приоритеты, отделять более важное от менее значимого.
- Одинаково легко видеть систему в целом и проводить декомпозицию, чтобы была проверена каждая отдельная фича.
- Точно формулировать мысли и уметь их донести до коллег и заказчика.
- Умело применять техники тест-дизайна.
Выбор правильной техники тест-дизайна (способа создания тестов) особенно важен, ведь именно от этого зависит эффективность самих тестов.
Можно создать огромное количество тест-кейсов, которые мы будем даже не в состоянии выполнить или которые помогут нам выявить лишь тривиальные проблемы. Только правильно выбранная техника позволит свести к минимуму количество тестов, которые необходимо пройти, чтобы выявить серьезные ошибки. Это ключевой момент в написании сценариев, и мы непременно расскажем о техниках тест-дизайна подробнее в будущих статьях.
Пишем тест-кейсы – что дальше?
А дальше отправляем их на ревью, после чего – либо на автоматизацию, либо в план ручного тестирования.
Рис.:Пример оформления тест-кейсов
Имейте в виду, что автоматические тесты требуют более полного описания, включая, скажем, зависимые значения для проведения расчетов. Для ручной же проверки такая детализация не имеет смысла, равно как и для небольших по объему проектов; особенно для стабильных компаний с небольшой текучкой кадров, где большое количество досконально описанных тест-кейсов – лишние затраты на обслуживание тестирования.
Каких результатов ждать?
1. Положительного, когда ожидаемый результат совпал с фактическим.
2. Отрицательного, когда ожидаемый результат не совпал с фактическим, выявлена ошибка.
Однако существует и третий вариант, когда прохождение теста блокируется каким-либо дефектом.
Так что, по сути, результата может быть всего два. Кстати, каждый конкретный тест-кейс призван решить конкретную задачу, проверить конкретный элемент «цепочки» и ожидаемый результат для этого элемента всегда один. Прочего быть не должно.
Рекомендации в помощь
В завершение нам остается разве что поделиться парой хороших советов:
- Приступайте к тестированию как можно раньше, ещё до выхода первого билда.
- В первую очередь проводите позитивные тесты и только потом переходите к негативным.
- Начинайте с простых проверок. Используйте типовые пользовательские данные для ввода в систему. Если тест не пройдет даже на таких значениях, существование проблемы станет очевидным.
- Сложные и негативные сценарии запускайте только после проверки простых. Если продукт хорошо справляется с очевидными задачами, испытайте его реакцию на неочевидные.
- Раскладывайте приложение на отдельные модули и для каждого из которых составляйте список проверок (чек-лист).
- Не забывайте обновлять тесты, как только была обнаружена ошибка или изменена функциональность.
Успехов!
Полезно прочитать: