Что обязательно есть у тест кейса

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

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

Источник

Что обязательно есть у тест кейса

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

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.

Где: Кострома / онлайн

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

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

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

Blogposts:

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

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

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

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

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

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

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

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

Шаги

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

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

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

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

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

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

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

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

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

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

Шаги:

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

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

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

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

Шаги:

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

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 частей, то есть 5 атрибутов тест кейса:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Что обязательно есть у тест кейса

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

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

Проверенный шаблон

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

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

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

Углубиться в проект мало, или Кому поручить написание тест-кейсов

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

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

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

Пишем тест-кейсы – что дальше?

А дальше отправляем их на ревью, после чего – либо на автоматизацию, либо в план ручного тестирования.

Рис.:Пример оформления тест-кейсов

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

Каких результатов ждать?

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

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

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

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

Рекомендации в помощь

В завершение нам остается разве что поделиться парой хороших советов:

Источник