для чего в тест кейсе нужны шаги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Для чего в тест кейсе нужны шаги

Без какой части тест-кейс никак не может обойтись?

Вопрос номер 2

Для чего в тест-кейсе нужны шаги?

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

Вопрос номер 3

Два вида исхода исполнения тест-кейса. К какому исходу мы, как тестировщики, стремимся?

Каждый завершенный тест-кейс дает один из двух исходов (результатов):
Положительный исход (PASS), если фактический результат исполнения тест-кейса равен ожидаемому.
Отрицательный исход (FAIL) если фактический результат исполнения тест-кейса НЕ равен ожидаемому.

Вопрос номер 4

Вопрос номер 5

Вопрос номер 6

УНИКАЛЬНЫЙ ID(Unique ID)
ID должен быть уникальным в пределах не только документа, содержащего тест-кейс, но и всего департамента качества. Необходим для ведения статистики по тест-кейсам, обновления, удаления или переноса в другой документ. Что бы ничего не путалось.

ПРИОРИТЕТ ТЕСТ-КЕЙСА (Test Case Priority)
Используется для определения важности тест-кейса. Помогает определить очередность выполнения тест-кейсов.

ИДЕЯ (IDEA)
Это описание конкретной вещи, проверяемой тест-кейсом.

ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ(SETUP and ADDITIONAL INFO)
Все данные, которые могут понадобиться при выполнении тест-кейса, собранные в одном месте.

Вопрос номер 7

Вопрос номер 8

Вопрос номер 9

Вопрос номер 10

Вопрос номер 11

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

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

Вопрос номер 12

Вопрос номер 13

Ожидается ли, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО?
Никто не ожидает, что тест-кейсы будут на 100% «работать» сразу после написания. Дело в том, что они создаются на основании опека (или, как это часто бывает, на основании устного пожелания начальника), и так как мы физически не видим функциональностей этого опека (код еще не написан), то многие вещи нужно в буквальном смысле представить себе. Кроме того, как мы уже видели, сами спеки имеют баги и спек может быть изменен без ведома тестировщика.

Ответ из коментариев
Да, ожидается, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО.

Вопрос номер 14

Вопрос номер 15

Приведите атрибуты шапки тест-комплекта.
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека.
Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека.
Producer — продюсер, написавший спек.

Developer — программист, пишущий код в соответствии со спеком.

Добавленно из комментариев
Overview — вкратце рассказывается, чему посвящен этот тест-комплект.
GLOBAL SETUP and ADDITIONAL INFO — здесь мы говорим о повторяющихся вещах, которые будем использовать в более чем одном тест-кейсе, и вообще о любой другой полезной информации для всего тест-комплекта.

Вопрос номер 16

Состояния тест-кейса.

состояние — «Новый» (New).
Это первая редакция тест-кейса:
«Created on: 11/17/2003 by 0. Тарасов».

состояние — «Измененный» (Modified).
Модификации, как правило, связаны с изменением спека, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке:
«Modified on: 11/26/2003 by И.Новикова».

состояние — «Более недействителен» (Retired).

Вопрос номер 17

Вопрос номер 18

Вопрос номер 19

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

Источник

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

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

Источник

Как писать тест-кейсы: полное руководство

Во время тестирования 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 минут.

Фишка в чем? Если у меня уже есть яйца, я могу их не покупать. Но взбивать их мне все равно придется. Даже если я неделю назад взбивала яйца с сахаром, я не могу их взять сейчас (они же уже протухли!). То есть шаги я выкинуть не могу, сделав их заранее. А вот предварительные — вполне.

Также и в ИТ мире. Не надо радостно перетаскивать в предварительные шаги вообще все. Например:

Кликнуть на кнопку «Войти»…

Что? Какая кнопка? Где мне ее искать? На рабочем столе? Шаги должны быть независимыми. Если говорить про веб-сайт, я должна открыть новую вкладку в режиме инкогнито и там пройтись по всем шагам и у меня все получится. Поэтому выкидывать ссылку на сайт в предварительные шаги не надо, она важна для выполнения теста.

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

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

Регистрация на сайте, пополнение баланса и подготовка файлов — предварительные шаги, они не имеют прямого отношения к тесту загрузки файла, это так, подготовка. Как они будут выглядеть? Допустим, мы хотим обработать файл-образец (есть такой в системе).

На что обратить внимание при написании предварительных шагов? Давайте разберемся с правилами их написания.

Правила их составления

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

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

Итого

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

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

Источник