Когда смотришь на специалистов по тестированию, которые пишут тест-кейсы, то понимаешь, что многие из них даже не имеют представления как это правильно делается. Я не буду приводить множество примеров, которые показывают вопиющие ошибки, а постараюсь озвучить основные принципы того, как надо писать тест-кейсы.
Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор.
Обязательные атрибуты для заполнения
- Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
- Заголовок — краткое, понятное и ёмкое описание сути проверки.
- Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
- Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
- Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.
В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д.
Правила написания тест-кейсов
- Заголовок:
- должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
- не может содержать выполняемые шаги и ожидаемый результат.
- Предусловие:
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
- не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
- не может содержать ожидаемый результат.
- Шаги проверки:
- должны быть чёткими, понятными и последовательными;
- следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; - должны использоваться безличные глаголы.
Правильно: нажать, ввести, перейти.
Неправильно: нажмите, введите, идите; - не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
- не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
- Ожидаемый результат:
- должен быть у каждого шага проверки;
- должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
- не должно быть избыточного описания.
- Общие требования к тест-кейсам:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
- в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
Примеры
Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.
Тест-кейс №1. Корректный
Номер | 1 |
Заголовок | Отправка сообщения через форму обратной связи на странице “Контакты” |
Предусловие | Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru |
Шаг | Ожидаемый результат |
В верхнем меню сайта нажать на ссылку “Контакты” | Открылась страница “Контакты” |
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы | В поле “Ваше имя” отображается введённое имя |
Ввести корректный email в поле “Ваш e-mail” | В поле “Ваш e-mail” отображается введённый email |
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Тема” отображается введённый текст |
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел | В поле “Сообщение” отображается введённый текст |
Ввести в поле капчи требуемое капчей значение | В поле капчи отображается введённое значение |
Нажать под заполняемой формой на кнопку “Отправить” | Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.” Все заполненные поля очищены. |
Проверить почту администратора сайта | На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5. |
Тест-кейс №2. Некорректный
В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения.
Номер | 1 |
Заголовок | Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?) |
Предусловие | Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага) |
Шаг | Ожидаемый результат |
Нажать на ссылку “Контакты” (Где она находится?) | Открылась страница (Какая?) |
Ввести имя в поле “Ваше имя” (Какие символы вводить?) | (Ничего не указано в ожидаемом результате, что должно произойти?) |
Ввести email в поле “Ваш e-mail” (корректный или некорректный?) | В поле отображается email (Какой? Введённый? В каком поле отображается?) |
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?) | В поле “Тема” отображается текст (Какой?) |
Ввести в поле “Сообщение” текст (Какие символы вводить?) | Видим в поле “Сообщение” введённый текст (Видим или отображается?) |
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести). | В поле капчи будет введённое значение (Что будет делать? Танцевать?) |
Нажать под заполняемой формой на кнопку (На какую?) | Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?) |
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи) |
Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:
Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.
Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.
Мой путь в нормальное IT начался с того, что я изучал работу jira на вашем сайте, недавно я перешел в отдел тестирования и по иронии судьбы, я снова здесь.
Здраствуйте. Подскажите пожалуйста, мне нужно зайти вот на этот сайт:
1) обучение профессии рф
2) Провести Исследовательское тестирование.
3) Написать тестовыми сценариями важнейший функционал сайта.
4) Найденные ошибки описать в отчете об ошибках.
Подскажите, с чего начать? Нужно составить Чек-лист, а по нему делать Тест-кейс?
Затем, найти ошибки и описать их в отчете об ошибках.
Помогите!
1. Изучить функционал сайта.
2. Составить функциональную карту сайта (описывающую функции сайта) — https://victorz.ru/20160822290
3. Составить чек-лист проверок на основании карты — https://victorz.ru/202005021160
4. Провести тестирование по чек-листу.
5. Зафиксировать ошибки — https://victorz.ru/201911011064
2. В ходе тестирования, составления карт и чек-листов поймёте какой функционал важный.
3. Написать тест-кейсы на этот функционал.
Здравствуйте! А в поле «Результат тестирования: » что-то надо писать? Спасибо
Всё зависит от вашей компании.
У нас если всё успешно, то ничего не пишем. Если провалено, то описываем проблему.
Добрый вечер!
подскажите, пожалуйста, к какому виду тестирования функционала формы регистрации можно отнести то, что обязательные поля для заполнения не помечены *?
Тестирование удобства использования.
Функциональное тестирование.
Добрый день!
Подскажите, пожалуйста, как наиболее корректно отразить в тест-кейсе ввод логина/пароля? Очевидно, при наличии тестового набора пар этих самых логинов/паролей. Спасибо!
В предусловии указываем ссылку на документ с логинами и паролями. В шаге пишем «Ввести логин и пароль из предусловия в поля ввода логина и пароля»…
Привет! на что обратить внеманиє когда надо написать тест кейс на корзину в інтернет магазине
Надо учесть всё описанное в статье.
Добрый день, есть ТЗ (1. На панели поиска должна быть создана кнопка «Сбросить», по нажатию на которую происходит очищения всех полей панели поиска от введенных данных в них.
2. На панели поиска должна быть создана кнопка «Найти», по нажатию на которую должна происходить проверка заполнения хотя бы одного поля и:
a. Если результат проверки не успешен, то выводится предупреждающее сообщение с текстом «Необходимо заполнить хотя бы одно поле»
b. Если результат проверки успешен, то:
• Осуществляется поиск в базе данных по введенным данным
• Если пользователь производит поиск по полю «ФИО», то поиск должен осуществляться по Фамилии, Имени и Отчеству. Приложение должно считывать входные данные таким образом: первое значение – фамилия, после первого пробела – имя, после второго пробела – отчество (как в быстром поиске клиентов на странице Оформления заказа).
• При поиске с помощью поля «Номер карты лояльности» если клиент привязан к нескольким картам лояльности, то поиск ведется по всем привязанным картам лояльности.
• Если есть результаты по заданным параметрам, то результаты поиска постранично выводятся в таблице результатов.
• Если нет результатов по заданным параметрам, то в правом нижнем углу выводится информационное сообщение с текстом «Результаты не найдены», а на экране на месте надписи «Воспользуйтесь поиском, …» должна появиться надпись «К сожалению, по вашему запросу клиенты не найдены».)
по первым двум пунктам не могу понять как написать тест кейс, или это уже получается баг?
Или здесь есть ошибки в самом ТЗ
Панель поиска судя по всему как в интернет магазине с выбором ряда параметров. В ТЗ должна быть информация о составе всех полей панели поиска.
Здравствуйте, хотелось бы внести ясность в свои начиная в области тестирования, как я понял нам выдают требования (которые как я понял не всегда бывают) по ним мы составляем тест кейсы по тестированию функционала сайта, к примеру регистрации, в начале мы проводим позитивное тестирование, а потом негативное с применениями техник тест дизайна по типу граничных значений, все верно? Или все же как то другому? Или же мы просто можем провести сплошные позитивные тесты, в роли пользователя и на этом закончить?
Меня просто смущают всегда в вакансиях слова по типу проведение регрессионное тестирование, интеграционного тестирования, я знаю как бы их определения, но на каком этапе их применять? Спасибо заранее за ответ)
На ваш вопрос одним комментарием не ответить. Поэтому отвечать буду кратко:
— Позитивные проверки также создаём через техники тест дизайна.
— Негативные проверки в крупных компаниях получается делать только если есть время, так как там большая скорость разработки и задач и времени хватает только на позитивные проверки.
— Регрессионное: в момент тестирования задачи — ввели новый способ оплаты, проверили основную доработку и что другие способы оплаты не сломали (регресс); перед выходом релиза проводим регрессионное тестирование ранее работающих функций системы, тут количество проверок часто ограничено из-за нехватки времени.
— Интеграционное тестирование: тестируем в процессе тестирования задач.
Виктор, добрый день.
Я хочу навести порядок в тестировании нескольких взаимосвязанных АС.
Тестирование я провожу на своём личном стенде.
Хочу в одном пространстве управлять следующими сущностями:
АС
| —> описание базового функционала (фич)
. | —> тесты для старых фич
| —> Релиз № N
. | —> описание новых фич
. | —> тесты для новых фич
Новый релиз — ввожу новые фичи, отключаю выбывшие фичи, пишу тест-кейсы для новых фич.
Делаю тестирование (НФ и регресс).
Жму кнопку — получаю отчёт о тестировании.
Подскажите, пожалуйста, есть ли какое-нибудь готовое (желательно — открытое) решение для моей задачи, чтобы оно не стоило, как самолёт?
Вы сумбурно написали. Непонятно, какое решение вам нужно и для чего.
Здравствуйте. Хотелось бы узнать что пишут в поле модуль в тест кейсе? Видел примеры с тем что в модуль пишут компоненты. Так же были примеры с сервисами например электронная почта, или служба отправки сообщений.
Всё зависит от правил компании.
Могу только догадываться, что туда могут писать компоненты или функциональные блоки системы, к которым относятся тест-кейсы.
У меня на практике данное поле не встречалось. У нас используется поле «Секция», в которой указываем функциональный модуль системы.
Добрый день. Как понять сколько тест кейсов я должна написать для функции? Вот у меня сейчас задача написать тест кейсы к APP Installation. Спасибо.
Если есть требования, то писать столько тест-кейсов чтобы они покрыли все описанные требования.
Если нет требований, то тут только экспертно оцениваем полноту (количественно) написания тест-кейсов.
Здравствуйте
Помогите пожалуйста, не совсем понимаю : дано задание написать тест кейс на поиск по названию товара в онлайн магазине. я написала так…
Предусловие:
База товаров онлайн магазина Wildberries состоит из множества разных категорий вещей и товаров. Каждый товар имеет свой ярлык и входит в определенную категорию, из этих категорий выходят подкатегории.
Например: обувь — категория, босоножки или туфли — подкатегория. Для примера выбирается товар из доступных в базе товаров онлайн магазина Wildberries. Для данного тест кейса взят пример “туфли женские”.
Шаги:
1. Зайти на сайт Wildberries (URL)
Открылась главная страница сайта онлайн магазина товаров Wildberries
2. Ввести в поле «я ищу» (посередине сверху) слово «туфли женские» и нажать поиск.
Обновляется страница и выдаёт по запросу «туфли женские» определенное количество товара в наличии на данный момент и только женские. Поиск по названию работает, так как ищет сугубо по заявленным параметрам. В выдаваемом результате показывается только тот, товар который подходит под заданный ярлык (параметр), а именно “туфли” и “женские”
Что в нём можно ещё добавить или убавить, не понимаю корректный ли он вообще. тема тест-кейсов оказалась слишком дремучей.
Посмотрите видео, в котором пошагово описан процесс написания тест-кейсов.
Доброе утро, старшие товарищи, прошу дать консультацию по поводу написания смоук-тесты, каким образом они пишутся? это что-то сокращенного вида тесты по выполнению обязательных шагов и полей, верно?
Пишутся обычные тест-кейсы.
Т.е. вы пишите тест-кейсы и в определённый момент времени из них выбираете набор тест-кейсов, которые вы будете выполнять при дымовом тестировании (Smoke testing).
раньше я не встречала разбиения на смоук и санити тесты, вот и интересуюсь) Спасибо
Здравствуйте!
Скажите, могут ли разные тест-кейсы иметь одинаковый заголовок. Например: тестируем функцию «Редактировать фото», и, согласно требованиям, тестируем фото разных форматов (jpg, jpeg, bmp…) и разного размера. Для каждого формата свой кейс. Как в таком случае быть с заголовками?
Тест-кейсы должны по разному именоваться чтобы из сотни кейсов вы по названию могли определить какой из них за какую проверку отвечает.
Примеры вариантов именований:
1. Редактирование фотографии. Формат: jpg. Размер: 100*100 пикселей.
2. Редактирование фотографии. Формат: png. Размер: 100*100 пикселей.
3. Редактирование фотографии. Формат: png. Размер: 200*200 пикселей.
или
1. Редактирование фотографии в формате jpg размером 100*100 пикселей.
2. Редактирование фотографии в формате png размером 100*100 пикселей.
3. Редактирование фотографии в формате png размером 200*200 пикселей.
и так далее.
Добрый день, не подскажете, что писать в графу Поле для кейсов? Это на анкете
О какой анкете вы говорите?
Если пишем тест кейсы по документации, мы должны четко следовать документации? Или надо негативные тесты писать тоже? Чтобы покрыть все возможные сценарии поведения пользователя? Спасибо.
1. При создании тест-кейсов по ТЗ пишем тест-кейсы опираясь на имеющуюся информацию в ТЗ. Негативные тест-кейсы можно писать, если есть время, желание и знание того, что надо описать.
3. Покрыть все возможные сценарии поведения пользователя можно только имея очень подробное ТЗ.
Добрый день, позволю себе задать один маленький вопрос: если поле имеет выпадающий список значений и из него нужно выбрать необходимое, как это лучше прописать?
например: «Выбрать значение из списка» или «Заполнить поле значение из списка»? Спасибо
«Выбрать из выпадающего списка».
спасибо
Добрый день, хотела у Вас уточнить: Если карточка состоит из нескольких 10-тков полей, то в тест-кейсах прописываем все этим поля отдельной строкой?
Уточните, что вы хотите конкретно написать в шаге.
Например у меня есть на форме несколько полей, сейчас я пишу вот в таком виде(увы таблицу не удалось вставить):
шаг
Ввести в поле «Максимальное количество людей на борту» целое числовое значение
ожидаемый результат:
В поле «Максимальное количество людей на борту» отражается введенное значение
шаг:
Ввести в поле «Максимальная площадь парусов (кв. м)» корректное значение (при необходимости)
ожидаемый результат:
В поле «Максимальная площадь парусов (кв. м)» отражается введенное значение
шаг:
Выбрать из выпадающего списка значение в поле «Тип двигателя»
ожидаемый результат:
В поле «Тип двигателя» отражается выбранное значение
И так расписываю все поля для заполнения
Вы правильно пишите на мой взгляд.
Есть вариант, когда пишут всё в одном шаге, когда полей много десятков и шагов столько же:
Шаг:
— Ввести в поле «Максимальное количество людей на борту» целое числовое значение.
— Ввести в поле «Максимальная площадь парусов (кв. м)» корректное значение.
— Выбрать из выпадающего списка значение в поле «Тип двигателя»
Результат:
— В указанных полях отражаются введённые\выбранные данные.
Вариант выбираете сами в зависимости от того как вам удобно.
спасибо
Я использую иной подход. С оглядкой либо на автоматизцию, либо на исключение нескольких вариантов развития одного кейса. Постораюсь на примерах объяснить.
*Я всегда использую «предусловие». Если его грамотно использовать, то это позволит убрать лишнюю инфу из конструкции кейса, ну, и вопросы от программиста (с уточнениями)*
КЕЙС1:
Предусловие:
1. Поля с ЗАПОЛНЕНИЕМ значений: поле1, поле2;
2. Допустимые значения для полей с ЗАПОЛНЕНИЕМ:
— поле1: целые числовые;
— поле2: числовые;
4. Поля с ВЫБОРОМ значений — поле 3;
Шаги:
Как указал Виктор.
не совсем поняла, простите
ооооо!!!! так можно?! это же гениально 😍
Здравствуйте! Есть такая задача:
Условие. К нам обратился заказчик: у него есть сайт на устаревшем движке, он хочет
чтобы разработали новый сайт на современном движке и заодно сделали редизайн.
Мы завершили работы и теперь остался последний этап: перенести все новости со
старого сайта на новый. Программисты разработали скрипт, переносящий новости со
старого сайта на новый. Теперь тестировщику необходимо проверить правильно ли перенеслись новости. Каждая новость содержит: заголовок, подзаголовок, текст,
обязательную картинку-миниатюру, опциональное видео, опциональную галерею
картинок. Каждая новость относится к одному из 5 разделов.
Задача. Напишите сценарий тестирования (тест-кейсы) для скрипта переноса новостей.
Критерии оценки. Тестовый сценарий должен предусмотреть, как можно больше
возможных проблем, которые могут возникнуть при миграции
Как написать тест кейсы?
> Тестовый сценарий должен предусмотреть, как можно больше возможных проблем…
Всё предусмотреть в одном тест-кейсе не получится и не стоит. Стоит сосредоточиться на корректность переноса, т.е. если условие описанное в тест-кейсе не соблюдено, то это уже проблема.
Необходимо написать тест-кейсы:
1. Для проверки новости без галереи картинок и видео.
2. Для проверки новости с видео.
3. Для проверки новости с галереей картинок.
4. Для проверки новости с галереей картинок и видео.
Можно объединить все в один тест-кейс. Вариантов создания тест-кейсов в данном случае множество.
попарное тестирование?
Хорошая статья, но я бы добавил еще немного внимания разделу «Ожидаемый результат». Часто начинающие да и с опытом тестировщики пишут: «Открывается страница регистрации» (например), вместо «Открыта страница регистрации». Типа нам важен процесс открытия страницы, а не конечный результат
Так же очень большая ошибка (на мой взгляд) писать в ожидаемом результате несколько вариантов. Например: 1. Картинка отображена 2. Если картинка не отображена, отображается заглушка 3. При отсутствии соединения с интернетом отображается заглушка «Проверьте соединение». Опять же на мой взгляд это три отдельные проверки, которые надо все проверить, а не выполнять одну проверку и смотреть какой результат подошел
Поддерживаю ваши дополнения. Выделю как-нибудь время, чтобы дополнить статью.
Отличная стаття
А что в результате писать? «Все пашет»?)
В последнем шаге в результате написано «На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5». Мы же проверяем «Отправка сообщения через форму обратной связи на странице “Контакты”.
Виктор, очень понравилась статья, спасибо!
А вот если бы еще шаблон для скачивания приложили, было бы совсем круто)
А как тикеты распологать. Друг под другом? Тикет 1, Тикет 2 — это все таблички, которые идут вниз?
Приложил в конце статьи.
Добрый вечер.
Скажите пожалуйста, как верно написать шаги тест-кейса в случае тестирования с пустыми окнами.
Например, форма есть с полями Имя и Телефон и кнопкой «позвоните мне»
Делается негативный тест-кейс с пустыми полями, для определения обязательных полей ввода.
Вариант 1
1) поле Имя оставить пустым
2) поле Телефон оставить пустым
3) нажать кнопку Позвоните мне
Вариант 2
1) нажать кнопку Позвоните мне
1. Поля Имя и Телефон не заполнять (очистить, если заполнены).
2. Нажать кнопку «Позвонить мне».
Steps
1. поля Имя и Телефон не заполнять — мы это в степах пишем.
а что в Expected Results заполнять?
То что у Виктории происходить должно.
Помогите пажалуйста создать тест-кейс Оплачу
Спасибо за предложение, однако я не пишу тест-кейсы за деньги.
А деньги тебе за что платят?)))