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

Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.

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

Тест-кейс

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

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

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

1.ID — уникальный номер.
Обычно проставляется автоматически в системах хранения тест-кейсов.

2. Краткое описание тест-кейса (Name).
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.

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

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

Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.

3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.

4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс.

5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять.

6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс.

7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу.

8. Шаги (steps) — точная последовательность действий для выполнения проверки.

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

9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов.

10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.

Тест-кейс для авторизации на сайте

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

1.ID
Пусть будет №1, так как это наш первый тест-кейс

2. Краткое описание тест-кейса (Name)
Авторизация существующего пользователя.

Если бы нам на выбор было предложено несколько способов регистрации (Телефон, E-mail, ВКонтакте, Фейсбук и т.п.), то название могла бы выглядеть вот так “Авторизация существующего пользователя через ВКонтакте”.

3. Ссылка на требования
В нашем случае требований нет. Значит поле оставляем пустым

4. Автор тест-кейсы (Author)
Иванов И.

5. Приоритет (Priority)
Высокий, так как функциональность важная. В двух словах, чем важнее объект тестирования и проверки, тем выше приоритет.

6. Название/модуль/версия продукта (Component/Version)
Кейс относится напрямую к авторизации, следовательно этот модуль и укажем.

7. Предварительные условия (pre-condition)
Во-первых, нужно зайти на сайт по адресу https://msk.farfor.ru. Во-вторых, пользователь должен существовать и быть не залогинен.

8. Шаги (steps)
1) Вводим в поле телефона “+7 900 000-00-00”,
2) Вводим в поле password пароль “123”,
3) Нажимаем кнопку “Вход”.

9. Ожидаемый результат (expected result)
Авторизация прошла успешна, пользователь остался на странице https://msk.farfor.ru

10. Приложения (attachments)
В этот раз файлы нам не нужны, поэтому обойдемся без них.

Для наглядности соберем все это в таблицу.

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

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

Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.

Теперь давайте немного поговорим о чек-листах в тестировании.

Чек-лист

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

Можно сказать, что чек-лист — это упрощенный тест-кейс без шагов и прочего описания. Просто список того, что необходимо проверить. Более того, иногда список тест-кейсов является своего рода чек-листом, если смотреть просто на названия тест-кейсов. Например, чек лист «Авторизация пользователя» может выглядеть следующим образом:
1. Авторизация пользователя через E-mail
2. Авторизация пользователя через ВКонтакте
3. Авторизация пользователя с пустым E-mail
4. Авторизация пользователя с неверным паролем и так далее

________________________________
Чек-лист экономит время тестировщика и упрощает поддержку тестовой документации, но, с другой стороны, многие вещи при проверки остаются на совести тестировщика. Например, какой е-mail вводим, какой неправильный пароль и так далее
________________________________

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

***

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

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