Какая тестовая документация бывает

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

Есть два основных вида тестовой документации: тест-кейсы и чек-листы. Одностраничному веб-сайту или команде, в которой один или два тестировщика, хватит и чек-листов. Большим командам лучше использовать тест-кейсы, чтобы информация не терялась.

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

1. Оформление подписки.
2. Просмотр витрины фильмов.
3. Запуск продолженного просмотра.
   

А тест-кейс — детализированный план того, как проверить определённое требование к программе. Например, когда проверяем оформление подписки, шаги тест-кейса могут выглядеть так:

1. Авторизоваться в приложении Кинопоиска как пользователь без подписки.
2. Нажать на кнопку «Оформить подписку».
3. Ввести данные карты и код из смс.
4. Подтвердить оформление подписки.

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

Тест-кейсы бывают:

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

Зачем описывать тесты

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

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

Из чего состоит тест-кейс

• ID — уникальное сочетание букв и цифр. Инженеры по тестированию используют ID, чтобы группировать тесты в наборы. В современных системах управления тестированием это происходит автоматически.
• Заголовок — наименование тест-кейса. Описывает то, что должно быть проверено.
  
• Предусловия, или входные данные, — действия, которые надо выполнить до начала проверки, и/или инструменты, которые надо использовать.
  
• Шаги — описание последовательных действий, которые необходимо выполнить для проведения теста.
  
• Ожидаемый результат — описание того, как система должна реагировать на шаги теста.
  

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

Когда тестовая документация не нужна

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

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

Даниил Скляров, инженер по тестированию в Яндексе