что такое предусловие в тест кейсе

Что такое тест кейс: пример и чек-лист тест кейсов для начинающих тестировщиков, которые подойдут каждому

Вы хотите узнать, по какой форме писать тест кейсы и увидеть пример правильного тест кейса? Мы собрали чек-лист из примеров и формы, как написать грамотный тест кейс по шаблону.

В этом материале о тест кейсах вы узнаете:

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

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

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

Вот пример тест кейса:

Тест кейс №1
Название тест кейса: Уведомление пользователя о снижении заряда аккумулятора вручную
Предусловия тест кейса: статус самоката: в аренде
Шаги тест кейса:

Логин — test, пароль — test

Появляется сообщение об успешном выполнении тест кейса «Пользователь уведомлен о снижении заряда»

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

Существуют 6 правил проведения тест кейсов:

Типичные ошибки при написании тест кейсов

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

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!

Источник

Пишем максимально эффективный тест-кейс

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

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

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

Зачем нужны тест-кейсы?

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

Любой тест-кейс обязательно включает в себя:

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

Что еще необходимо знать, перед созданием тест-кейса?

Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:

1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.

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

Чего не должно быть в тест-кейсе

1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.

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

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

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

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

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

Источник

Правила написания предварительных шагов в тест-кейсах

Содержание

Что такое предварительные шаги тест-кейса

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

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

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

Это как когда готовишь. Скажем, шарлотку

Шарлотка

Вкусная шарлотка! Которую родные уминают за 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 шага и запихали в раздел «предварительные шаги» непонятно зачем.

Шаги
Ввести логин такой-то, пароль сякой-то

Итого

Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация в системе. Или покупка ингредиентов для шарлотки ツ

Правила описания предварительных шагов:

Источник

Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Продолжу хвастаться статусом книги.

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Что такое предварительные шаги тест-кейса

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

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

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

Это как когда готовишь. Скажем, шарлотку

Шарлотка

Вкусная шарлотка! Которую родные уминают за 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 шага и запихали в раздел «предварительные шаги» непонятно зачем.

Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация в системе. Или покупка ингредиентов для шарлотки ツ

Правила описания предварительных шагов:

Источник