Стандартные ошибки при оформлении тест кейсов

Автор: Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков.

Тест-кейс — это проверка. «Выполни тест-кейс по вводу отрицательных значений» = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

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

Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план —  это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)

Стандартные атрибуты тест-кейса

1. Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
2. Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов («Элемент создан»).

Пример оформления (один ожидаемый результат)

Есть внутренний сайт компании компании, которая проводит интернет «Самый_лучший_в_своем_роде» — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru.
Примечание: www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему . Приводится здесь, чтобы показать ошибки в написании тест-кейсов.

На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди «извне», с логином и паролем test / test.

Тест-кейс № 1. Создание жильца без ФИО.

Шаги

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы».
4. Нажать на кнопку «Создать карточку жильца».
5. Нажать на кнопку «Сохранить», не заполняя никакие данные.

Ожидаемый результат

Появляется сообщение об ошибке «Заполните обязательные поля, отмеченные *», карточка не сохраняется.

Преимущества и недостатки тест-кейсов

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

Недостатки (вытекают один из другого):

1. Очень много копипасты много копипасты копипасты. В примере выше заполняется поле «ФИО». Тест-кейсы «ввести в поле только символы, только числа, строку нулевой длины и т. д.» будут очень похожи друг на друга, первые шаги одинаковые и, положа руку на сердце, будут копипаститься. Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему.
2. Сложно поддерживать. Представьте, что вкладку «Жильцы» переименовали в «Заказчики». Чтобы актуализировать тест-кейсы, надо внести изменения в сотни сценариев, что утомительно даже в режиме «Ctrl + C, Ctrl + V«.
3. Неактуальное состояние. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.

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

Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать… Это отнимает очень много времени и сил.

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

Примеры оформления (несколько ожидаемых результатов)

Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).
Когда говорят о нескольких ожидаемых результатах, это может означать:

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

Несколько вариантов вводимых данных

Тест-кейс № 2. Создание жильца, проверка поля «ФИО».

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, , пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Заполнить поле ФИО (см «Ожидаемый результат»)
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

Вводимое значение	Ожидаемый результат
Киселева Ольга Евгеньевна	Ок, карточка сохраняется
<Оставить поле пустым>	Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется
2*4*6*8*11*14*17*20*23*26*29*32*35*38*41*	Ошибка – «Максимальная длина поля – 40 символов, введено — 41», карточка не сохраняется. (Такую строчку легко сформировать с помощью инструмента perlclip)
&*%#(^$@*&;	Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
Kiseleva Olga Evgenievna	Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
…	…

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!

Результаты для нескольких шагов из кейса

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

Тест-кейс № 3. Создание жильца с худым полным ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные».
2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись «Здравствуйте, admin». Открыта главная страница сайта.
4. Открылась страница «Создание нового жильца» с полями «Фамилия», «Имя» и «Отчество» и кнопкой «Сохранить».
6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Несколько проверок после одного сценария

Тест-кейс № 4. Создание жильца с самым полным ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, , пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Области применения

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы».
В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни «ДЕДЛАЙН!», только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:

1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.

Тест-кейсы не нужны:

1. Простые системы (веб-сайты, мобильные приложения и т. п.).
2. Ситуации, когда в команде всего один или два тестировщика, знающие свой продукт. Время, потраченное на создание и поддержку тест-кейсов никогда не окупится.

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

Стандартные ошибки при оформлении тест-кейсов

Читать теорию — одно, делать на практике — другое. Обычно в теории все понятно, а на практике получаем примерно такой кейс (все совпадения случайны, тест-кейс написан как агрегация различных ошибок):

Тест-кейс № 01. Создание жильца.

Шаги:

1. Зайди на сайт www.test.ru.
2. Нажми на кнопку «Войти» в правом верхнем углу экрана.
3. Залогинься с правами администратора.
4. Перейди на вкладку «Жильцы».
5. Нажми на кнопку «Создать карточку жильца».
6. Введи корректные ФИО, например, «Иванов Иван Иванович» и сохрани карточку.

Ожидаемый результат — карточка создана.

Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя 

Разберем ошибки кейса 01.

1. Абстрактное название
На первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Но! Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название.
В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?
Всегда помните про «кратко, но емко«. По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. Так что дополняем название — Создание жильца без отчества, Создание жильца, цифры в поле «Имя» и т.д…

2. Повелительное наклонение
Чтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — «Выполнить, загрузить»…

3. PROD
В данном примере идет ссылка на PROD.
Никогда нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы . Тестовый набор для этого создается отдельно и тщательно выверяется.
ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и … или сломает что-то, или испортит реальные данные.

4. Нет ссылки на сайт
Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить… Гораздо лучше было бы просто нажать на него!

5. Слишком детализировано
Пункт «Нажми на кнопку «Войти» в правом верхнем углу экрана» содержит много подробностей про пользовательский интерфейс. Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс. Чем меньше в документации зависимость от UI (user interface, пользовательский интерфейс), тем лучше.
Перепишем данный шаг: Войти под учетной записью администратора (admin/1)
Описание шага не стало менее понятным, и мы избавились от привязки к интерфейсу. Если вместо кнопки сделают ссылку или человек просто Enter нажмет, то суть шага не изменится: мы же в данном кейсе не логин проверяем, а создание жильца.

6. Нет нужной информации — непонятно, как авторизоваться
Есть пункт «Залогинься с правами администратора» — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль.
Если такой пользователь присутствует всегда (или создается каждый раз для тестирования), то есть его логин и пароль «статические» (не меняются), то их всегда надо прописывать, чтобы не возникало дополнительных вопросов.
Тест-кейсы составляются тогда, когда нужно, чтобы любой человек со стороны, не знающий проекта, мог присоединиться и помочь, выполнить тест-кейсы. Не задавая коллегам при этом дополнительные вопросы.
Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация.

7. Нет описания проверки
«Карточка создана» — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.
Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?

Поправим тест-кейс по всем замечаниям. Вот что получилось:

Тест-кейс № 02. Создание жильца с корректными ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru.
2. Войти под учетной записью администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Уже хорошо, но можно ли еще улучшить этот тест-кейс?

Сейчас снова попробуйте, не смотря ответ, найти проблемные зоны в этом тест-кейсе. А потом проверите себя 

Итак, ошибки кейса 02:

1. Абстрактное название.
Слова «корректный», «правильный» ит.д. в названии тест-кейса такой же маркер, как «ошибка» в названии бага. Таких слов надо избегать.

Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс.
Поэтому забудьте про слова «корректный», «некорректный» и т.п., пытайтесь писать понятнее. И всегда помните принцип «кратко, но емко«. А разделение кейсов на смысловые группы (негативные тесты, позитивные тесты, тесты на особые случаи) сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов.

2. Нет нужной информации
Зайти на сайт www.dev_test.ru
Ок, я открываю этот сайт, а там авторизация. Как мне туда попасть?
Никак! Идти и узнавать логин/пароль. А зачем, если это легко было исправить указанием логина/пароля в скобках или ссылкой на страницу со всеми логинами и паролями (они все же могут меняться и лучше менять в одном месте)?
Исправленная версия тест-кейса:

Тест-кейс № 03. Создание жильца с полным ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учетной записью администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Определения из книг по тестированию

Ron Patton. Software Testing.

Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.

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

Lee Copeland. A Practitioner’s Guide to Software Test Design.

The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:

• Test case specification identifier — A unique identifier so that this document can be distinguished from all other documents.
• Test items — Identifies the items and features to be tested by this test case.
• Input specifications — Specifies each input required by this test case.
• Output specifications — Specifies each output expected after executing this test case.
• Environmental needs — Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
• Special procedural requirements — Defines any special setup, execution, or cleanup procedures unique to this test case.
• Intercase dependencies — Lists any test cases that must be executed prior to this test case.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

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

Гленфорд Майерс, Искусство тестирования программ

Любой тест должен включать две составляющие:

• описание входных данных программы;
• точное описание корректных выходных данных для каждого набора входных данных.

На этом, пожалуй, все 

PS — Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!

PPS — Уже скоро стартует мой курс Онлайн-интенсив для начинающих тестировщиков, в котором мы будем практиковаться составлять тест-кейсы, более полезные чек-листы и прочими полезными вещами! 
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 на курс 1-7 сентября.

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

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

Что такое чек-лист в тестировании?

Чек-лист (checklist) представляет собой список проверок, которые планируется провести для оценки качества цифрового продукта. Хотя нет единых жёстких правил по оформлению документа, любой хороший артефакт структурирован и разбит на смысловые блоки и секции. Каждый инженер составляет чек-лист в комфортном для себя формате или согласно требованиям компании.

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

Что важно при составлении чек-листа?

Создание качественногоартефакта – это уже половина успеха. При написании этого документа важно следовать нескольким рекомендациям:

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

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

Чек-лист: как избежать ошибок?

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

1. Чек-лист – это не развёрнутая и досконально проработанная инструкция

Это только лаконичное напоминание, черновик для QA-процесса. Пункты списка касаются только основных этапов тестирования.

1. Чек-лист стоит рассматривать не как план работы, а как эффективнейший инструмент экономии времени

Данный артефакт служит отличной подсказкой, которая направит процесс оценки качество в верное русло.

1. Пункты чек-листа могут и должны корректироваться

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

Что такое тест-кейс?

Тест-кейс (test case) – это детальное описание проверки работоспособности программного решения. Совокупность подобных документов называется тестовым набором (test suite).

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

Какие ошибки допускаются тестировщиками при составлении чек-листов?

К типичным недочётам и недоработкам тест-кейсов можно отнести следующее:

• Чрезмерное упрощение документа. Иногда тестировщик настолько сильно увлекается сокращением излагаемой информации, что артефакт начинает походить на конспект. А ведь документ должен содержать исчерпывающий объём информации для инженеров, которые не работали над его составлением.
• Ссылки или копирование пунктов. Недопустимо на каком-либо шаге ссылаться на другой шаг(например, «повторить пункты под номерами 5 и 6 для реализации шага 10»). Такую проверку нужно либо исключить, либо скорректировать.
• Введение подразделов внутри одного пункта. Помните, каждый пункт – это одно конкретное действие.

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

Почему чек-лист и тест-кейс являются очень важными инструментами в руках тестировщика?

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

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

1. Зайти на сайт.
2. Открыть раздел «Книги: новинки».
3. Выбрать книгу.
4. Поместить книгу в корзину.
5. Перейти в корзину.

Чек-лист в аналогичной ситуации будет содержать один-единственный пункт – «Поместить книгу в корзину». Здесь уже не нужно пошагово описывать последовательность переходов, нажатий кнопок.

Заключение

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

Как не допустить ошибок при создании артефактов, какие пункты они должны содержать, как эффективно использовать инструмент в работе – всё это объяснят преподаватели на курсах по тестированию программного обеспечения.

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

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

Что такое тест-кейс

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

Словарь терминов некоммерческой организации, занимающейся сертификацией в области тестирования (ISTQB), предлагает следующее определение тест-кейса: «… набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию».

Комплект из нескольких тест-кейсов принято называть тестовым набором (test suite). Не путайте с понятием тест-плана. Оно обозначает именно планирование работы: что, когда, зачем, как и т.д.

Атрибуты тест-кейса

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

• Уникальный идентификационный номер, состоящий из комбинации букв и цифр.
• Заголовок. Описывает цель тест-кейса. К примеру, тест-кейс для тестирования страницы входа может иметь заголовок «Проверка входа пользователя с верными данными».
• Предусловия. Шаги, предваряющие реализацию тест-кейса. При определенных условиях требуется ввод учетных данных.
• Шаги. Изложение действий, составляющих проверку.
• Постусловия. Список действий, необходимых для восстановления системы до исходного состояния. Указываются, если есть необходимость.
• Ожидаемый результат. Предполагаемый результат, к которому мы придем после реализации тест-кейса.
• Фактический результат. Состояние системы после совершения всех действий тест-кейса(не является обязательным).
• Статус. Успех (Success)/ провал (Failed)/ блокировка (Blocked). Отмечается не всегда, если требуется.

Скачать файл

К некоторым формам тест-кейсов добавляют и другие атрибуты. Среди них:

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

Отличия тест-кейсов от чек-листов

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

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

Плюсы и минусы тест-кейсов

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

Минусы такого типа тестирования тесно взаимосвязаны.

• Заполнение требует долгой монотонной работы. Например, при тестировании корректного ввода ФИО надо выполнять простейшие одинаковые шаги: «ввести только символы, «ввести только числа» и т.д. Это особенно заметно, если посмотреть несколько тест-кейсов на один и тот же функционал.
• Затратное по времени редактирование. Малейшее изменение содержания сайта требует коррекции сотен сценариев тест-кейса. Не самое увлекательное и довольно выматывающее занятие.
• Некорректность тест-кейсов. Возникает из-за того, что при создании нового берутся элементы старого, которые не поменяли.

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

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

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

Виды тест-кейсов

Тест-кейсы делят на несколько групп в зависимости от входных данных, действий и предполагаемого поведения системы.

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

Пример.

Надо проверить требование к системе записи клиентов в салон красоты: «В систему нужно добавлять новые филиалы и мастеров».

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

При проведении негативных тест-кейсов тестировщик проверяет, как реагирует система при некорректном введении данных. Например, при вводе неполного адреса салона или одного и того же мастера дважды.

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

Правила разработки тест-кейсов

При разработке тест-кейсов учитывают следующие требования для каждого из его атрибутов.

Заголовок

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

Предусловие

• подробно описывает состояние объекта или системы, требуемое для выполнения шагов тест-кейса;
• список источников информации (описание системы, инструкции), которые тестировщик должен прочитать перед тем, как начать выполнение тест-кейса;
• если тестируемая информационная система обладает несколькими средами (прод, тест, препрод…), предусловие не должно включать ссылки на нее. Информацию о ресурсе следует разместить в инструкции, а ссылку добавить в предусловие.
• не прописываются данные для авторизации, их размещают в инструкции, оставляя ссылку в поле тест-кейса для предусловия;
• не должно включать ожидаемый результат и выполняемые шаги. Если есть необходимость держать открытой главную страницу сайта перед тем, как приступаем к шагам проверки, в предусловии отмечается: «открыта главная страница сайта»;
• не должно описывать ожидаемый результат.

Шаги проверки

• ключевые качества: доступность, четкость, последовательность;
• важно избавляться от чрезмерной подробности в описании. Например, вместо «первый шаг — нажать на клавиатуре цифру 2, второй шаг — нажать на клавиатуре цифру 5», следует писать «ввести число 25 в данном поле»;
• применяются только глаголы в неопределенной форме: ввести, нажать, удалить и т.д. Недопустимо: введите, нажмите, удалите;
• если требуется добавить комментарии или пояснения, они размещаются в виде инструкции в базе знаний, а в предусловии размещаем ссылку на нее;
• не допускаются конкретные статистические данные (названия файлов, логины и пароли) и примеры, во избежание эффекта пестицида.

Ожидаемый результат

• описывается у каждого шага проверки;
• содержит внятное и краткое описание состояния, в которое приходит программа или объект после реализации конкретного шага;
• не допустимы лишние описания.

Общие требования к тест-кейсам

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

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

Ошибки при создании тест-кейсов

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

• Слишком обобщенное название тест-кейса

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

Неправильно: Уведомление пользователя об отсутствии интернет-соединения.
Правильно: Уведомление пользователя о потере Wi-Fi сигнала вручную.

• Употребление повелительного наклонения в тест-кейсе

Дело не в практической целесообразности, а в элементарной вежливости.

Неправильно: перейди на страницу; введи значение и т.д.
Правильно: перейти на страницу; ввести значение и т.д.

• Некликабельные ссылки

Это касается как гиперссылок внутри программы, так и внешних ресурсов. Каждую ссылку надо делать кликабельной с помощью Ctrl + K.

• Слишком подробные описания действий

Формулировки шагов тест-кейса не должны вызывать вопросов, но при этом не надо писать очевидные вещи.

Неправильно: Наведите мышку и нажмите на зеленую кнопку внизу страницы посередине с надписью «Согласен».

Правильно: Нажмите на кнопку «Согласен».

• Слишком краткое описание действий

Правильный тест-кейс лаконичен, но при этом не требует дополнительных объяснений.

Неправильно: Открыть меню «Дополнительные возможности».
Правильно:

• Нажать на иконку «Профиль».
• Перейти во вкладку «Настройки».
• Выбрать пункт «Дополнительные возможности».

Приоритет тест-кейсов и чек-листов заключается в том, что они делают процесс тестирования программного обеспечения структурированным и доступным для неспециалистов. В чек-листах прописываются объекты проверки, а в тест-кейсах — пошаговый алгоритм.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры 

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

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

Номер	1
Заголовок	Отправка сообщения через форму обратной связи на странице “Контакты”
Предусловие	Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru
Шаг	Ожидаемый результат
В верхнем меню сайта нажать на ссылку “Контакты”	Открылась страница “Контакты”
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы	В поле “Ваше имя” отображается введённое имя
Ввести корректный email в поле “Ваш e-mail”	В поле “Ваш e-mail” отображается введённый email
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел	В поле “Тема” отображается введённый текст
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел	В поле “Сообщение” отображается введённый текст
Ввести в поле капчи требуемое капчей значение	В поле капчи отображается введённое значение
Нажать под заполняемой формой на кнопку “Отправить”	Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.” Все заполненные поля очищены.
Проверить почту администратора сайта	На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5.

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

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

Номер	1
Заголовок	Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?)
Предусловие	Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага)
Шаг	Ожидаемый результат
Нажать на ссылку “Контакты” (Где она находится?)	Открылась страница (Какая?)
Ввести имя в поле “Ваше имя” (Какие символы вводить?)	(Ничего не указано в ожидаемом результате, что должно произойти?)
Ввести email в поле “Ваш e-mail” (корректный или некорректный?)	В поле отображается email (Какой? Введённый? В каком поле отображается?)
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?)	В поле “Тема” отображается текст (Какой?)
Ввести в поле “Сообщение” текст (Какие символы вводить?)	Видим в поле “Сообщение” введённый текст (Видим или отображается?)
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести).	В поле капчи будет введённое значение (Что будет делать? Танцевать?)
Нажать под заполняемой формой на кнопку (На какую?)	Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?)
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)

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

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

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

Привет! Я QA Automation Engineer в Scalable Solutions. Наша компания, как и многие другие, предлагает после устного собеседования сделать тестовое задание. Как человек, который два года назад делал похожее задание при трудоустройстве, решила разобрать основные ошибки тестировщиков при его выполнении, а также поделиться спецификой наших (и не только) ожиданий в ходе найма. 

Да кому нужны эти ваши тестовые

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

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

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

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

Чего ожидает наниматель

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

Хорошо показать знание стандартных тестовых методологий и принципов: проверку граничных значений и классов эквивалентности, атомарность и независимость тестов и другие.

Кроме того, может быть полезно уточнить требования к коду у нанимателя: кому-то может быть важнее оптимизация, кому-то – читаемость. Хотя по моему скромному мнению, если мы говорим о тестовых на должность QA, читаемость предпочтительнее. Код будет смотреть незнакомый человек, которому лично объяснить свой подход не получится, не говоря уже о том, что в первую очередь будет оцениваться качество самих тестов. И этому человеку должно быть понятно, что и как в тесте проверяется. Впрочем, читаемость полезна и в повседневной жизни, ведь это позволяет в дальнейшем в любой момент легко вернуться к тесту и что-то при необходимости подправить.

Разбор ошибок на примере теста Scalable

В тестовом задании нашего QA отдела предлагается написать тесты для REST API серверного приложения. Спецификация к нему прилагается. API содержит POST, GET и DELETE запросы, манипулирующие с некой сущностью (в задании, конечно, сущность не абстрактная, а из нашей области работы, но ниже в примерах будет присутствовать как entity). Также есть запрос снапшота, который возвращает все неудаленные сущности в их текущем состоянии. 

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

Однако независимо от задания есть набор типичных ошибок, которые допускают кандидаты. Разберем их ниже. (Примеры взяты из тестовых заданий кандидатов. Названия некоторых переменных и методов изменены, все остальное сохранено.)

1. Один позитивный тест на метод

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

Из менее очевидного: часто пропускаемый тест с получением пустого результата в ответ на GET-запрос. Какое-то время назад нам подобные тесты как раз очень пригодились, пока проверяли, не потерялась ли совместимость между проектами.

2. Много проверок разного поведения в одном тесте

Есть вечное противостояние: «хочу, чтобы тесты были атомарными, и каждый проверял что-то одно» и «не хочу делать сложную и долгую подготовку окружения много раз, сделаю ее один раз и все нужные вещи сразу проверю». Ответа, что из этого лучше, у меня по-прежнему нет, но, например, для проверки REST API в нашем негромоздком тестовом задании сложная подготовка окружения не нужна. Так что можно смело разделить тест, который проверяет а) невалидное создание сущности, б) валидное создание сущности, в) последующий GET-запрос с полной проверкой тела ответа, на три отдельных теста.

Пример из тестового задания одного соискателя:

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

3. Ничего не проверяющие или проверяющие не то проверки

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

Но, например, в одном из тестовых кандидат сделал следующее:

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

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

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

4. Отсутствие проверки состояния хранилища

Часто при проверке запросов опускается последующая проверка состояния хранилища (БД, например):

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

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

5. Отсутствие проверки граничных значений

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

6. Рандомизация тестов

Все еще загадочное для меня, но все еще периодически появляющееся в выполненных заданиях явление. Кандидат создает случайный генератор входных данных и передает в тест. Вроде изначальная идея понятна: какие-то из рандомно сгенерированных входных данных могут внезапно отловить какую-то ошибку, да и вообще такое поведение как будто бы ближе к реальному. На другой чаше весов лежит абсолютная непредсказуемость теста. Мы запустили его десять раз, и нам повезло, а на одиннадцатый он вдруг упал. Сколько раз потребуется его перезапустить, чтобы снова это воспроизвести? Неужели и на CI надо запускать тест 11 раз? Или больше? Как точно определить, что мы в итоге проверяем в тесте? 

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

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

7. Стремление показать как можно больше своих навыков

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

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

8. Совет со звездочкой 

Это не является ошибкой, скорее, что-то вроде правила хорошего тона. Хорошо читаемый код – это всегда приятно, к тому же сильно упрощает и ускоряет проверку. Поэтому здорово, когда в нем есть комментарии, переменные названы не одной буквой, у аргументов методов есть аннотации, а у assert-ов указано сообщение с ошибкой. А еще когда тест зовут не “test_code_400”, а, например, “test_get_entity_invalid_id”.

А что ещё

Тестовое задание – один из трех китов, на которых строится представление о кандидате (помимо резюме и устного собеседования). Поэтому выполнять его спустя рукава не стоит, даже если собеседование прошло блестяще. У нас в Scalable мы смотрим не на конкретное число допущенных или не допущенных ошибок в тестовом задании. Если 80% (условно) из перечисленного выше нет, то в целом неплохо. Куда важнее общее впечатление:

• Насколько кандидат рационален и логичен – как он строит мысли, как строит кейсы; 

• Как оформлен код, насколько он читаем, как структурирован; 

• Умеет ли кандидат думать за рамками ТЗ. Как он уточняет (и делает ли это вообще) задание и конкретизирует требования. 

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

---

Ещё по теме:

Тестирование финтех бэкенда: как мы дошли до 20 тыс. тест-кейсов

Телеграм-канал Scalable Insights, где мы делимся аналитикой и инсайтами в new fintech

Тест-кейс — это проверка. «Выполни тест-кейс по вводу отрицательных значений» = проведи проверку такую-то и проверь, что результат будет такой-то.

См также: Тест-кейс проверяет, а не доверяет!

Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

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

Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план —  это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)

Стандартные атрибуты тест-кейса

1. Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
2. Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов («Элемент создан»).

Пример оформления (один ожидаемый результат)



Есть внутренний сайт компании, которая проводит интернет «Самый_лучший_в_своем_роде» — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru.
Примечание: www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему . Приводится здесь, чтобы показать ошибки в написании тест-кейсов.

На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди «извне», с логином и паролем test / test.

Тест-кейс № 1. Создание жильца без ФИО.

Шаги

1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
2. Войти под учеткой администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы».
4. Нажать на кнопку «Создать карточку жильца».
5. Нажать на кнопку «Сохранить», не заполняя никакие данные.

Преимущества и недостатки тест-кейсов



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

Недостатки (вытекают один из другого):

1. Очень много копипасты много копипасты копипасты. В примере выше заполняется поле «ФИО». Тест-кейсы «ввести в поле только символы, только числа, строку нулевой длины и т. д.» будут очень похожи друг на друга, первые шаги одинаковые и, положа руку на сердце, будут копипаститься. Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему.
2. Сложно поддерживать. Представьте, что вкладку «Жильцы» переименовали в «Заказчики». Чтобы актуализировать тест-кейсы, надо внести изменения в сотни сценариев, что утомительно даже в режиме «Ctrl + C, Ctrl + V«.
3. Неактуальное состояние. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.

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

Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать… Это отнимает очень много времени и сил.

Области применения

Разберем ошибки кейса 01.

1. Абстрактное название

На первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Но! Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название.

В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?

Всегда помните про «кратко, но емко«. По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. Так что дополняем название — Создание жильца без отчества, Создание жильца, цифры в поле «Имя» и т.д…

2. Повелительное наклонение

Чтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — «Выполнить, загрузить»…

3. PROD

В данном примере идет ссылка на PROD.

Никогда

нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы . Тестовый набор для этого создается отдельно и тщательно выверяется.

ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и … или сломает что-то, или испортит реальные данные.

4. Нет ссылки на сайт

Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить… Гораздо лучше было бы просто нажать на него!

5. Слишком детализировано


Пункт «Нажми на кнопку «Войти» в правом верхнем углу экрана» содержит много подробностей про пользовательский интерфейс. Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс. Чем меньше в документации зависимость от UI (user interface, пользовательский интерфейс), тем лучше.

Перепишем данный шаг: Войти под учетной записью администратора (admin/1)

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


6. Нет нужной информации — непонятно, как авторизоваться

Есть пункт «Залогинься с правами администратора» — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль.

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

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

Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация.

7. Нет описания проверки


«Карточка создана» — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.

Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?



Поправим тест-кейс по всем замечаниям. Вот что получилось:

Тест-кейс № 02. Создание жильца с корректными ФИО.

Шаги:

1. Зайти на сайт www.dev_test.ru.
2. Войти под учетной записью администратора (логин — admin, пароль — 1)
3. Перейти на вкладку «Жильцы»
4. Нажать на кнопку «Создать карточку жильца».
5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
6. Нажать на кнопку «Сохранить».

Определения из книг по тестированию



Ron Patton. Software Testing.

Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.

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

Lee Copeland. A Practitioner’s Guide to Software Test Design.

The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:

• Test case specification identifier — A unique identifier so that this document can be distinguished from all other documents.
• Test items — Identifies the items and features to be tested by this test case.
• Input specifications — Specifies each input required by this test case.
• Output specifications — Specifies each output expected after executing this test case.
• Environmental needs — Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
• Special procedural requirements — Defines any special setup, execution, or cleanup procedures unique to this test case.
• Intercase dependencies — Lists any test cases that must be executed prior to this test case.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

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

На этом, пожалуй, все 

PS — Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!

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

Заходите к нам на огонек! Там мы будем практиковаться составлять тест-кейсы, более полезные чек-листы и прочими полезными вещами ツ