Пишем максимально эффективный тест-кейс
Что такое тест-кейс?
Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату.
Набор тест-кейсов называют тест-комплектом. Иногда тест-набор путают с тест-планом. Тест-план описывает какие работы, как и когда должны быть проведены в рамках тестирования продукта, а так же что необходимо для их выполнения.
Зачем нужны тест-кейсы?
Атрибуты тест-кейса
Любой тест-кейс обязательно включает в себя:
Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.
Что еще необходимо знать, перед созданием тест-кейса?
Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:
1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.
Во-вторых, одним тест-кейсом проверяется одна конкретная вещь, и для этой вещи должен быть только один ожидаемый результат.
Чего не должно быть в тест-кейсе
1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.
Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки.
Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов.
Со вторым думаю все ясно. Если описание шагов или ожидаемое результата будет не четким, то это блокирует прохождение тест-кейса.
В тест-кейса должно быть вся информация, которая необходима для его прохождения. Например, если мы проверяем окно логина на сайте, значит нам понадобится логин и пароль, иначе прохождение этого сценария будет невозможно.
Так же не следует слишком детализировать кейс. Например, если мы проверяем возможность создания комментария, то не стоит писать в каком угле экрана должно быть окно логина. Избыточная информация только затрудняет прохождение тест-кейса.
Как писать тест-кейсы: полное руководство
Во время тестирования QA-инженер работает с большим количеством документации. Чеклисты, наборы тестов, тестовые сценарии, планы тестирования, отчеты о тестировании, анализ тестирования — это лишь часть списка документов, которые должны уметь создавать тестировщики. В этой статье мы расскажем вам, как создавать тест-кейсы для ручного тестирования.
Что такое тест-кейс и зачем он нужен
Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.
Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.
Чем отличаются тест-кейс и чеклист
Тест-кейсы используются для сложных проектов. Например, когда от поведения системы зависит человеческая жизнь. Это могут быть проекты, связанные с пожарной безопасностью, здравоохранением, финансами и т. д. В таких случаях все нужно тестировать очень тщательно.
Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.
Обычно при работе с простыми системами — сайтами, мобильными приложениями и т. д. — нет необходимости в тест-кейсах. Часто в команде бывает только один-два тестировщика, которые хорошо знают свой продукт. В таком случае время, потраченное на создание и поддержку тест-кейсов, никогда не окупится. Лучше создать чеклист со списком функций, которые нужно проверить — это будет более рационально.
Позитивные, негативные и деструктивные тест-кейсы
В позитивных тест-кейсах используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.
В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.
Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.
Негативные тест-кейсы используют некорректные входные данные и проверяют, не делает ли программа того, чего не должна делать. Негативное тестирование призвано гарантировать, что при получении некорректных входных данных система не будет работать по нормальному сценарию (например, выбросит ошибку).
Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.
Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.
Для деструктивного тестирования QA-специалисты могут применять следующие методы:
Атрибуты тест-кейса для ручного тестирования
Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:
Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:
Характеристики хорошего тест-кейса
Прежде всего, тест-кейс не должен быть зависимым или связанным с другими тест-кейсами. Он должен быть полным и самодостаточным. Следует избегать расплывчатых описаний шагов или ожидаемых результатов. Любые ограничения, отсутствие необходимой информации или чрезмерное количество деталей делают тест-кейсы менее эффективными.
Короче говоря, хороший тест-кейс:
Best practices в написании тест-кейсов
Под best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:
Формирование тест-кейсов
Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.
Примеры тест-кейсов для ручного тестирования
Позитивный тест-кейс
Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.
ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).
Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).
Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).
Шаги:
Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.
Деструктивный тест-кейс
Еще один пример — деструктивный тест-кейс.
ID: FWSF-2.
Заголовок: Проверить устойчивость поиска к SQL-инъекциям.
Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.
Шаги:
Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.
Негативный тест-кейс
Наконец, вот вам негативный тест-кейс.
ID: FWSF-3.
Заголовок: Проверить ввод на недопустимые значения.
Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.
Шаги:
Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.
Итоги: тестирование тест-кейса
Итак, мы разобрали основы написания тест-кейсов. Совет напоследок: чтобы проверить, насколько хорош ваш тест-кейс, покажите его человеку, который ничего не знает о проекте, над которым вы работаете. Вопросы, которые вы услышите, помогут определить слабые места вашего тест-кейса. Обратите внимание на эти моменты и постарайтесь внести изменения как можно скорее, иначе в будущем для поддержки тест-кейсов потребуется гораздо больше времени и усилий.
Что такое тест кейс: пример и чек-лист тест кейсов для начинающих тестировщиков, которые подойдут каждому
Вы хотите узнать, по какой форме писать тест кейсы и увидеть пример правильного тест кейса? Мы собрали чек-лист из примеров и формы, как написать грамотный тест кейс по шаблону.
В этом материале о тест кейсах вы узнаете:
Что такое тест кейс
Тест кейс — это проверка работоспособности программы или проекта.
Написать тест кейс — значит создать текстовое описание процесса тестирования какой-то части или функции проекта.
Тест кейсы нужны, чтобы члены команды могли проверить программу и познакомиться с ней, не читая весь код, а изучив только тест кейс.
Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!
Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах
У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:
Вот пример тест кейса:
Тест кейс №1
Название тест кейса: Уведомление пользователя о снижении заряда аккумулятора вручную
Предусловия тест кейса: статус самоката: в аренде
Шаги тест кейса:
Логин — test, пароль — test
Появляется сообщение об успешном выполнении тест кейса «Пользователь уведомлен о снижении заряда»
Как написать хороший тест кейс: правила и форма хороших тест кейсов
У тест кейса может быть 3 вида результатов:
Существуют 6 правил проведения тест кейсов:
Типичные ошибки при написании тест кейсов
Абстрактное название тест кейса
Тест кейсы на одном проекте часто похожи друг на друга. Чтобы в них не было путаницы, названия должны быть конкретными и однозначными.
Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную
Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.
Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку
Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.
Лишние детали в тест кейсе
Тест кейс должны быть однозначно понятным, но и перегружать его лишними деталями не нужно.
Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»
Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.
Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»
Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!
Как правильно написать тест кейс
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Тест-кейс — это проверка. «Выполни тест-кейс по вводу отрицательных значений» = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.
Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план — это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)
Стандартные атрибуты тест-кейса
Пример оформления (один ожидаемый результат)
На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди «извне», с логином и паролем test / test.
Шаги
Ожидаемый результат
Появляется сообщение об ошибке «Заполните обязательные поля, отмеченные *», карточка не сохраняется.
Преимущества и недостатки тест-кейсов
Недостатки (вытекают один из другого):
Последний недостаток перечеркивает достоинства. Тестировщик, который уже год как работает на проекте, поймет и неактуальный кейс, тем более если выполняет их подряд, начиная с первого. А тестировщик, который ничего о проекте не знает и получил пару кейсов из середины тестового набора, не сможет понять, о чем в них идет речь.
Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать. Это отнимает очень много времени и сил.
Чтобы упростить этот процесс, могут быть использованы тест-кейсы с одним сценарием выполнения, но несколькими входными параметрами и разными ожидаемыми результатами. Фактически мы получаем мини чек-листы с предварительными шагами.
Примеры оформления (несколько ожидаемых результатов)
Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).
Когда говорят о нескольких ожидаемых результатах, это может означать:
Несколько вариантов вводимых данных
Шаги:
Ожидаемый результат
| Вводимое значение | Ожидаемый результат |
| Киселева Ольга Евгеньевна | Ок, карточка сохраняется |
| Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется | |
| 2*4*6*8*11*14*17*20*23*26*29*32*35*38*41* | |
| &*%#(^$@*&; | Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется |
| Kiseleva Olga Evgenievna | Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется |
| . | . |
Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!
Результаты для нескольких шагов из кейса
Другой вариант записи тест-кейса с несколькими ожидаемыми результатами — когда результаты пишутся на разные пункты шагов выполнения проверки, то есть на разные этапы сценария.
Шаги:
Ожидаемый результат
1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные».
2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись «Здравствуйте, admin». Открыта главная страница сайта.
4. Открылась страница «Создание нового жильца» с полями «Фамилия», «Имя» и «Отчество» и кнопкой «Сохранить».
6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».
Несколько проверок после одного сценария
Шаги:
Ожидаемый результат
1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».
Области применения
Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы».
В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни «ДЕДЛАЙН!», только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.
Тест-кейсы нужны:
Тест-кейсы не нужны:
Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее — творческие чек-листы, формальные тест-кейсы или микс из этих подходов.
Стандартные ошибки при оформлении тест-кейсов
Шаги:
Ожидаемый результат — карточка создана.
Разберем ошибки кейса 01.
1. Абстрактное название
На первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Но! Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название.
В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?
Всегда помните про «кратко, но емко «. По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. Так что дополняем название — Создание жильца без отчества, Создание жильца, цифры в поле «Имя» и т.д.
2. Повелительное наклонение
Чтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — «Выполнить, загрузить».
4. Нет ссылки на сайт
Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить. Гораздо лучше было бы просто нажать на него!
7. Нет описания проверки
«Карточка создана» — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.
Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?
Поправим тест-кейс по всем замечаниям. Вот что получилось:
Шаги:
Ожидаемый результат
1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».
Уже хорошо, но можно ли еще улучшить этот тест-кейс?
Итак, ошибки кейса 02:
1. Абстрактное название.
Слова «корректный», «правильный» ит.д. в названии тест-кейса такой же маркер, как «ошибка» в названии бага. Таких слов надо избегать.
Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс.
Поэтому забудьте про слова «корректный», «некорректный» и т.п., пытайтесь писать понятнее. И всегда помните принцип «кратко, но емко «. А разделение кейсов на смысловые группы (негативные тесты, позитивные тесты, тесты на особые случаи) сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов.
2. Нет нужной информации
Зайти на сайт www.dev_test.ru
Ок, я открываю этот сайт, а там авторизация. Как мне туда попасть?
Никак! Идти и узнавать логин/пароль. А зачем, если это легко было исправить указанием логина/пароля в скобках или ссылкой на страницу со всеми логинами и паролями (они все же могут меняться и лучше менять в одном месте)?
Исправленная версия тест-кейса:
Шаги:
Ожидаемый результат
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.
Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения.
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:
Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:
Гленфорд Майерс, Искусство тестирования программ
Любой тест должен включать две составляющие:
Правила написания предварительных шагов в тест-кейсах
Содержание
Что такое предварительные шаги тест-кейса
Тест-кейс — это подробное описание проверки. Такое, которое можно будет дать человеку с улицы и он все поймет. В тест-кейсе есть название, предварительные шаги, шаги и результат. И куча других примочек, которые будут зависеть от стандартов оформления на вашей работе. В этой статье я хочу поговорить о предварительных шагах.
Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация.
Скажем, чтобы поставить лайк под фото, мне нужно войти в систему. Вот чтобы я смогла войти в систему, мне сначала надо зарегистрироваться, если я не делала этого раньше. Но, если я подготовилась заранее, этот предварительный шаг можно выкинуть.
Это как когда готовишь. Скажем, шарлотку
Шарлотка
| Сходить в магазин и купить: |
| Вкусная шарлотка! Которую родные уминают за 5 минут. |  |
Фишка в чем? Если у меня уже есть яйца, я могу их не покупать. Но взбивать их мне все равно придется. Даже если я неделю назад взбивала яйца с сахаром, я не могу их взять сейчас (они же уже протухли!). То есть шаги я выкинуть не могу, сделав их заранее. А вот предварительные — вполне.
Также и в ИТ мире. Не надо радостно перетаскивать в предварительные шаги вообще все. Например:
Кликнуть на кнопку «Войти»…
Что? Какая кнопка? Где мне ее искать? На рабочем столе? Шаги должны быть независимыми. Если говорить про веб-сайт, я должна открыть новую вкладку в режиме инкогнито и там пройтись по всем шагам и у меня все получится. Поэтому выкидывать ссылку на сайт в предварительные шаги не надо, она важна для выполнения теста.
А вот если я уже заранее зарегистрировалась, то хоть в новой вкладке, хоть в новом окне открою все и пройдусь по шагам. Авторизация то будет работать, если вы укажете, под кем входить. А регистрация прямого отношения к тесту не имеет.
Какие еще могут быть предварительные шаги? Посмотрим на примере Дадаты. Тестируем функционал обработки файла. Он доступен только авторизованному пользователю → надо зарегистрироваться. И он небесплатный → нужно пополнить баланс. И, конечно, у нас должен быть на руках файл для загрузки.
Регистрация на сайте, пополнение баланса и подготовка файлов — предварительные шаги, они не имеют прямого отношения к тесту загрузки файла, это так, подготовка. Как они будут выглядеть? Допустим, мы хотим обработать файл-образец (есть такой в системе).
На что обратить внимание при написании предварительных шагов? Давайте разберемся с правилами их написания.
Правила их составления
1. Писать лучше обезличено
Повелительное наклонение неприятно читать: пойди, открой, сделай, нажми. Фи.
Превращаем в нейтральные глаголы: пойти, открыть, сделать, нажать…
2. Писать нужно в едином стиле
Все предложения должны быть в едином стиле, а то читаешь потом такой текст и недоумеваешь:
3. Можно ссылаться на другие тест-кейсы
Так как предварительные шаги прямого отношения к тесту не имеют → мы не расписываем их подробно. Если надо уточнить, как выполнить действие, дайте ссылку на другой кейс:
Зарегистрироваться с именем «Д`Артаньян» (см. тест-кейс «Регистрация»).
Зарегистрируйся с таким-то именем. Если не знаешь как — welcome to тест-кейс регистрации.
Только помните, зачем делается отсылка на другой тест → чтобы, если у нас что-то поменяется в том действии (например, в регистрации), чтобы мы изменили это в ОДНОМ месте, в ОДНОМ тесте, а не в 100500.
Поэтому не надо писать «Зарегистрироваться в системе: зайти по ссылке А, нажать кнопку «Регистрация» в правом верхнем углу сайта, ввести в поле «имя» такое-то значение…». Завтра название кнопки изменится, вы во всех кейсах будете исправлять? А зачем?
4. Но не доходя до маразма ツ
Вот у нас в Дадате студенты пишут тест-кейсы на загрузку и обработку файлов. Чтобы им было проще, первый тест-кейс тренер сделал сам. Тест-кейс — на обработку файла-образца. Того, который система предоставляет для демонстрации своих возможностей.
Предварительные шаги выглядят так:
А потом студент тестирует, скажем, обработку файла в формате CSV. Угадайте с трех раз, как выглядят его предварительные шаги? Правильно!
Вот и как я тут должна понять, что за файл я должна скачать? В формате CSV? С одной строкой и одной колонкой, с 10000 колонок? С разным форматом дат рождения? С весом в 5 Мб? Какой? ЧТО именно тестируется?
Некоторые студенты учитывают этот момент и пишут так:
Но тут возникает новый вопрос — откуда скачать? Из тест-линка, внутри которого написан тест? Из какого-то общего хранилища? И что это за тест-кейс такой магический на скачивание файла, на который идет отсылка? Это ведь явная копипаста из примера. Там написано «тест-кейс на скачивание», значит, и я также напишу!
Почему в моем примере написано «скачать»? Потому что файл-образец в системе уже есть! И если мы хотим его протестировать, нам надо именно скачать то, что находится по ссылке «образец», а не какой-то свой прошлогодний файл в систему запихивать. Иначе какой смысл в этом тесте?
Отдельный тест-кейс на скачивание образца тоже сделан не просто так. Ведь нам надо убедиться в том, что по ссылке «образец» скачивается ровно то, что нам нужно. Что написано в ТЗ. Ведь в образце не какие-то абстрактные данные, они подобраны специальным образом, чтобы что-то показать, какие-то возможности системы.
Отдельный тест-кейс на скачивание образца:
В этом случае нам не важно наполнение файла. Мы просто хотим загрузить точно-работающий файл. И образец в этом случае идеален! Ведь если система не в состоянии обработать собственный образец — какое к ней может быть доверие? Тест на обработку образца идет первым в приоритете тестировщика.
А дальше мы уже исследуем, как реагирует система на разные форматы, разный вес, разное количество столбцов и колонок… И для этих тестов файлы придется готовить самостоятельно. Скачать то неоткуда!
Поэтому в предварительных шагах мы пишем о том, какой именно файл надо подготовить. Так и пишем: «Подготовить такой-то файл, см пример в аттаче».
Подготовить файл формата doc с данными из файла-примера (см аттач «Пример.doc»)
Подготовить файл с разными форматами дат рождения (см аттач «Даты рождения.xls»)
Подготовить файл картинкой внутри вместо текста (см аттач «Картинка. xls»)
Еще раз: не скачать. Подготовить. И никаких отсылок на мифический тест-кейс «Скачивание файла», что это за тест-кейс? Что он проверят в рамках нашей системы? И зачем нам на каждый тест-кейс писать отдельный тест-кейс на подготовку файла? Просто чтобы сослаться ради ссылки? Не надо.
Заметьте, как описан подготовительный шаг — мы готовим файл. Не скачиваем аттач, а готовим файл. И написано, что это за файл — вдруг аттач испарится завтра, случайно удалим? Все равно понятно, какой именно файл надо готовить )
А еще аттач может устареть — изменили функционал системы, файлы в старом формате уже не грузятся. Но если описано, ЧТО это за файл, тестировщик сможет его обновить!
5. Выкидывать текст ради текста нужно
«Кратко, но емко!» — главное правило оформления текстов. Будь то баг-репорт, тест-кейс или письмо Заказчику.
Текст ради текста всегда выкидываем. Сравните:
Что лучше? Лучше первый вариант, так как там меньше текста. У нас ведь все тесты на сайт https://www.example.com/, зачем тогда лишний раз писать ссылку? Тем более что потом придется продублировать ее в основных шагах.
А если разработчик решит поменять URL ссылки? Зачем нам вносить лишние правки? Когда надо поменять в 10 местах, всегда есть шанс хоть одно продолбать → а в итоге у нас будет неактуальная тестовая документация.
Мы потому и выносим регистрацию в предварительные шаги. Чтобы не исправлять сотни кейсов, если что-то изменится. Поправить в одном месте, в одном кейсе.
Ок, а если выбирать из таких вариантов, что будет лучше? Подумайте сами, прежде чем прочитать ответ:
Правильный ответ — все зависит от контекста. Если нам важно зарегистрироваться именно с таким именем (проверяем женские имена, или имена с апострофом, или что-то еще) — это нужно указать в предварительном шаге с регистрацией.
А если нам неважно, будет email «xxx@gmail.com» или «olala@gmail.com» — зачем об этом писать? Если я умею регистрироваться, я как-нибудь справлюсь с придумыванием email. Если не умею — пойду в тест-кейс регистрации и пройду по нему.
Поэтому, если нам важен сам факт регистрации, будет лучше вариант 1. Если важны данные — вариант 2.
6. Предварительных шагов может и не быть — это нормально
Не надо высасывать их из пальца там, где они не нужны. Именно так и получаются тесты, в которых просто отсекли первые 2-3 шага и запихали в раздел «предварительные шаги» непонятно зачем.
Шаги
Ввести логин такой-то, пароль сякой-то
Итого
Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация в системе. Или покупка ингредиентов для шарлотки ツ
Правила описания предварительных шагов: