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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB: 

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

Определение тест-кейса языком обывателя: 

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат. 

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

Обязательные атрибуты для заполнения 

  • Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс. 
  • Заголовок — краткое, понятное и ёмкое описание сути проверки. 
  • Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке. 
  • Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки. 
  • Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге. 
Похожее:  Steam 社区 :: 指南 :: Включение Steam Guard.

В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д. 

Правила написания тест-кейсов 

  1. Заголовок:
    • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
    • не может содержать выполняемые шаги и ожидаемый результат.
  2. Предусловие:
    • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса; 
    • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…); 
    • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»; 
    • не может содержать ожидаемый результат. 
  3. Шаги проверки: 
    • должны быть чёткими, понятными и последовательными; 
    • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
      Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; 
    • должны использоваться безличные глаголы.
      Правильно: нажать, ввести, перейти.
      Неправильно: нажмите, введите, идите; 
    • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё; 
    • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида. 
  4. Ожидаемый результат: 
    • должен быть у каждого шага проверки; 
    • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага; 
    • не должно быть избыточного описания. 
  5. Общие требования к тест-кейсам: 
    • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц; 
    • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще); 
    • тест-кейсы группируются в функциональные блоки по их назначению; 
    • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм. 

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

Примеры 

Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь. 

Тест-кейс №1. Корректный

Тест-кейс №2. Некорректный 

В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения. 

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов. 

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