Тест кейсы что это такое
Пишем максимально эффективный тест-кейс
Что такое тест-кейс?
Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату.
Набор тест-кейсов называют тест-комплектом. Иногда тест-набор путают с тест-планом. Тест-план описывает какие работы, как и когда должны быть проведены в рамках тестирования продукта, а так же что необходимо для их выполнения.
Зачем нужны тест-кейсы?
Атрибуты тест-кейса
Любой тест-кейс обязательно включает в себя:
Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.
Что еще необходимо знать, перед созданием тест-кейса?
Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:
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.
Заголовок: Проверить ввод на недопустимые значения.
Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.
Шаги:
Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.
Итоги: тестирование тест-кейса
Итак, мы разобрали основы написания тест-кейсов. Совет напоследок: чтобы проверить, насколько хорош ваш тест-кейс, покажите его человеку, который ничего не знает о проекте, над которым вы работаете. Вопросы, которые вы услышите, помогут определить слабые места вашего тест-кейса. Обратите внимание на эти моменты и постарайтесь внести изменения как можно скорее, иначе в будущем для поддержки тест-кейсов потребуется гораздо больше времени и усилий.
Пример кейс-теста при приеме на работу
При трудоустройстве на управленческие должности сотрудники отдела кадров оценивают поведение и рабочий стиль соискателя на новом месте. Для этого используются кейс-тесты, в которых кандидату придется представить себя в роли сотрудника компании и показать, как он справится с поставленной проблемой. Изучив и проанализировав пример тест кейса, кандидаты заметно повышают шансы получить работу.
Что такое ситуационный кейс-тест
Кейс-тест – это один из методов отбора персонала, при использовании которого анализируется поведение соискателей в конкретных ситуациях. Тестирование проходит в устном, письменном или электронном виде. Кандидату предлагается описание вымышленной рабочей ситуации, или ситуации взятой из практики компании.
Иногда case тесты даются с примерами ответов, а иногда ответы придется находить самостоятельно. Такой формат помогает оценить уровень профессиональных и коммуникативных навыков кандидата, его честность, открытость, умение принимать решения.
С помощью case test предсказывают поведение будущего сотрудника на должности и оценивают, соответствует ли оно принятому стилю и политике компании.
Кейс-тесты достоверней психологических опросников и тестов профессиональных качеств. Каждый вопрос оценивает определенные качества и стиль кандидата, в то время как опросники оценивают психологический профиль в конкретный момент времени. А это не всегда правильно: даже открытый мотивированный человек на новом рабочем месте бывает замкнутым, некоммуникабельным или неинициативным из-за своей скромности.
Пример вопроса (сценария) из кейс-теста
Ситуационные тесты оценивают не качества, а умение применять их на практике для разрешения конкретных проблем.
Сфера применения
Решение кейс-ситуаций используются в практике подбора персонала с середины ХХ века. В России метод получил распространение 10-15 лет назад, до сих пор используясь при собеседованиях на руководящие должности.
Тестирование используется в составе ассессмент-центров таких компаний, как:
Чаще всего подобные испытания проходят кандидаты на руководящие должности: директора магазинов, филиалов, администраторы, главные бухгалтеры. Но иногда с ними сталкиваются претенденты на рядовые должности, например, кассиры, консультанты, операторы колл-центра, менеджеры по продажам.
Примеры тест-кейсов
Сценарии тестов разрабатываются консалтинговыми компаниями под конкретную вакансию. Например, для кандидатов на управленческие должности, сценарии связаны с взаимоотношением с подчиненными. Для массовых должностей кейс тесты, как правило, применяются устно и описывают ситуации с клиентами или посетителями. В таком формате они напоминают ролевые деловые игры.
Пример тест кейса №1.
| Верно |
|---|
| Скажу руководству, что собираюсь менять работу, продолжу работать как раньше. |
Этот вариант свидетельствует о добросовестности, готовности отвечать за свои действия, ответственно относиться к работе. Такой ответ характеризует кандидата с положительной стороны. В сложившейся ситуации правильным решением будет предупредить руководство о скором уходе, чтобы начальник начал поиск сотрудников на замену, и продолжить добросовестно работать, не принося ущерб фирме.
Если говорить о других вариантах ответа, то:
— Первый ответ говорит о неспособности работать под руководством, ненадежности, склонности ставить свои интересы выше интересов компании.
— Третий ответ говорит об отсутствии трудовой этики, недобросовестности, неумении работать в команде.
— Четвертый вариант свидетельствует о пассивной позиции, неумении отвечать за свои поступки, отсутствии самоуважения и моральных ценностей.
Образец кейс теста №2.
| Наиболее эффективно | Наименее эффективно |
|---|---|
| Поблагодарю подчиненных за работу, пообещаю, что премия будет выплачена, когда появятся деньги. | Скажу, что подчиненные неблагодарны, укажу на ошибки. |
Третий вариант решает проблему, поднимает дух в отделе. Проявляются организаторские качества, сочувствие, поддержка. Лидер всегда должен проявлять лояльность к подчиненным и вышестоящему руководству, поддерживать сотрудников, снижать влияние сложившейся ситуации на работу отдела.
Пятый вариант не решает проблему, не дает подчиненным надежду на улучшение ситуации. Непонимание недовольства сотрудников, отсутствие поддержки ухудшит ситуацию, снизит показатели продаж.
Первый вариант не решает проблему, т.к. не отражается на подчиненных.
Второй вариант временно успокоит сотрудников, но проблема не решается, ведь возмущения повторятся.
Четвертый вариант не решает проблему, разлагает обстановку, снижает мотивацию сотрудников.
Упражнения по анализу кейсов (case study)
Кроме ситуационного тестирования, работодатели на ассессменте используют формат case study. Эти задания гораздо сложнее и трудозатратней ситуационных, причем как для кандидата, так и для работодателя. Соискателю дают папку с документами (если это упражнение формата in-tray) или файлы в электронном виде (формат e-tray). Для расчетов может потребоваться калькулятор.
Как правило, задачу или проблему кейса кандидату приходится определять самостоятельно, из тех документов, что он получил.
Эти документы содержат информацию о компании (вымышленной или той, в которую устраивается человек). Таким образом, имитируется рабочая обстановка, когда сотрудник, имея на руках распечатку звонков, электронную почту, отчеты и уставные документы компании решает определенную задачу. Так рекрутер оценивает уровень подготовки будущего сотрудника, ход его мышления, мотивацию, умение решать поставленные задачи.
«Соискателю дают 20 минут на ознакомление с материалами и подготовку доклада. Ему предстоит проанализировать деловую переписку, цели, стратегии, проекты компании»
После изучения информации — подготавливается ответ. Как правило, решение представляют:
Упражнения по case-анализу определяют:
Решение задачи начинается с анализа проблемы и поиска зацепок в документации. Также выделяют приоритетные задачи, чтобы начать работу с них. Это поможет уложиться в отведенное на испытание время и дать конкретные ответы на вопросы.
«При устном ответе, если тема недостаточно раскрыта, комиссия задает уточняющие вопросы. При подготовке презентации на слайды помещают только базовые факты, а все обоснования и комментарии рассказывают устно. В пояснительной записке к заданию, как правило, указывается пример оформления ответа тест кейса»
Ситуационные тесты и упражнения по анализу кейсов разрабатываются для каждой должности и компании. Как правило, этим занимаются консалтинговые и рекрутинговые агентства. Из-за сложности создания кейса, такого разнообразия вопросов, как, например, в тестах способностей у работодателей нет. При этом задания держат в секрете, чтобы избежать утечки информации.
На этом фоне подозрительно выглядят предложения скачать или купить кейсы с решениями в Сбербанк, ВТБ, и международные компании. Чаще всего это обман, поскольку рекрутеры следят за чистотой тестирования и если испытания попадают в сеть, меняют их на ассессменте.
Единственный способ пройти собеседование и подготовиться к кейсам – решать похожие задания, читать комментарии, советы, руководства к бизнес кейсам с решением. Такая тренировка учит определять приоритет, понимать, какие решения считаются правильными, как подходить к решению тех или иных проблем.
В комментариях к каждому вопросу в тренировочных тест-кейсах описывается правильный ход мыслей и обосновывается каждый ответ. Так кандидаты учатся давать правильные ответы на ассессменте и отстаивать принятую точку зрения.
Заключение
Ситуационные тесты – второй по сложности этап собеседования, где проверяются лидерские качества, умение работать в команде, лояльность к компании, мотивация и рабочий стиль кандидата. Кроме того, результаты кейс-тестов важнее результатов других испытаний на собеседовании. Исходя из этих результатов, работодатель принимает решение о найме, ведь подобная симуляция позволяет оценить на кандидата «в деле», а не на бумаге.
Тестовая документация. Тест кейс
Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Высокоуровневый тест-кейс — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполнению тест-кейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, поскольку прописать все данные подробно намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса — документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).
Цель написания тест-кейсов:
Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне, в зависимости от множества факторов). Наличие же тест-кейсов позволяет:
Жизненный цикл тест-кейса
В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь идёт о наборе состояний, в которых он может находиться.
Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения.
Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
Выполняется (work in progress) — если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
Пройден успешно (passed) — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
Требует доработки (not ready) — как видно из схемы, в это состояние (или из него) тест-кейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
Структура тест кейса
Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например, UR216_S12_DB_Neg).
Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля является не обязательным.
Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам.
Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса.
Общие рекомендации по написанию шагов таковы:
Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.
Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
Преимущества последовательных наборов:
К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии (или сценарии использования), представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.
Классификация наборов тест-кейсов
Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).
Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего.
Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также то, что при провале какого-то тест-кейса (приложение не пришло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять.
Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же принципам в набор включаются тесты, обладающие подходящими свойствами.