Меню

Что такое ситуационный кейс тест



Пример кейс-теста при приеме на работу

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

Что такое ситуационный кейс-тест

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

Иногда case тесты даются с примерами ответов, а иногда ответы придется находить самостоятельно. Такой формат помогает оценить уровень профессиональных и коммуникативных навыков кандидата, его честность, открытость, умение принимать решения.

С помощью case test предсказывают поведение будущего сотрудника на должности и оценивают, соответствует ли оно принятому стилю и политике компании.

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

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

Сфера применения

Решение кейс-ситуаций используются в практике подбора персонала с середины ХХ века. В России метод получил распространение 10-15 лет назад, до сих пор используясь при собеседованиях на руководящие должности.

Тестирование используется в составе ассессмент-центров таких компаний, как:

  • Сбербанк;
  • ВТБ;
  • Почта Банк;
  • Danone;
  • Tinkoff;
  • Пятерочка;
  • Магнит;
  • Газпром.

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

Примеры тест-кейсов

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

Пример тест кейса №1.

Верно
Скажу руководству, что собираюсь менять работу, продолжу работать как раньше.

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

Если говорить о других вариантах ответа, то:

— Первый ответ говорит о неспособности работать под руководством, ненадежности, склонности ставить свои интересы выше интересов компании.

— Третий ответ говорит об отсутствии трудовой этики, недобросовестности, неумении работать в команде.

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

Образец кейс теста №2.

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

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

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

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

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

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

Упражнения по анализу кейсов (case study)

Кроме ситуационного тестирования, работодатели на ассессменте используют формат case study. Эти задания гораздо сложнее и трудозатратней ситуационных, причем как для кандидата, так и для работодателя. Соискателю дают папку с документами (если это упражнение формата in-tray) или файлы в электронном виде (формат e-tray). Для расчетов может потребоваться калькулятор.

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

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

«Соискателю дают 20 минут на ознакомление с материалами и подготовку доклада. Ему предстоит проанализировать деловую переписку, цели, стратегии, проекты компании»

После изучения информации — подготавливается ответ. Как правило, решение представляют:

  • в устной форме;
  • в виде презентации со слайдами и устным пояснением;
  • в виде произвольных пояснений к тесту.

Упражнения по case-анализу определяют:

  1. умение ориентироваться в больших объемах информации;
  2. способность определять главные и второстепенные проблемы;
  3. умение концентрироваться;
  4. умение правильно распределять усилия, приоритизировать задачи ;
  5. уровень интеллектуального развития;
  6. соответствие стиля кандидата политике компании;
  7. наличие профессиональных навыков для должности.

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

«При устном ответе, если тема недостаточно раскрыта, комиссия задает уточняющие вопросы. При подготовке презентации на слайды помещают только базовые факты, а все обоснования и комментарии рассказывают устно. В пояснительной записке к заданию, как правило, указывается пример оформления ответа тест кейса»

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

Читайте также:  СЛОВО ЕСТЬ – ПРЕДМЕТА НЕТ РЕЙТИНГ СПОСОБОВ ПРОВЕРКИ МИКРОФОНА ПЕРЕД ПЕНИЕМ А КАКИМИ СЛОВАМИ ПРОВЕРЯЕТЕ МИКРОФОН ВЫ

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

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

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

Заключение

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

Источник

Все о тест кейсах

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

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

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

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

  • Описание – отражает цель проверки.
  • Предусловие (предварительные шаги) – содержит список шагов, которые необходимо выполнить до начала теста.
  • Шаги – метод выполнения теста, описанный по шагам.
  • Ожидаемый результат – предусмотренное поведение системы после прохождения по шагам.
  • Статус кейса – проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому.

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

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

  • Отсутствие зависимостей друг от друга. Поскольку тесты могут дополняться, меняться, терять свою актуальность и удаляться – как в таком случае поступать с тестами, на которые ссылались эти кейсы? Кроме того, взаимосвязь может ввести в заблуждение, будто работа продукта соответствует ожиданиям.
  • Четкие формулировки и высокая вероятность обнаружения ошибки.
  • Наличие детальной, но не избыточной информации. Если проверке подлежит процесс авторизации, тест-кейс должен содержать логин и пароль.
  • Легкая диагностика ошибок. Обнаруженная ошибка должна быть очевидной.
  • Исследование соответствующей (непосредственно той, что нужно) области приложения, выполнение нужных действий.

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

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

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

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

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

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

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

Пример тест-кейса

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

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

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

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

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

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

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

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

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

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

Источник

Все о тест кейсах

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

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

Читайте также:  Анти Тестдрайв Mercedes Benz W140 Жорик Ревазов

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

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

  • Описание – отражает цель проверки.
  • Предусловие (предварительные шаги) – содержит список шагов, которые необходимо выполнить до начала теста.
  • Шаги – метод выполнения теста, описанный по шагам.
  • Ожидаемый результат – предусмотренное поведение системы после прохождения по шагам.
  • Статус кейса – проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому.

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

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

  • Отсутствие зависимостей друг от друга. Поскольку тесты могут дополняться, меняться, терять свою актуальность и удаляться – как в таком случае поступать с тестами, на которые ссылались эти кейсы? Кроме того, взаимосвязь может ввести в заблуждение, будто работа продукта соответствует ожиданиям.
  • Четкие формулировки и высокая вероятность обнаружения ошибки.
  • Наличие детальной, но не избыточной информации. Если проверке подлежит процесс авторизации, тест-кейс должен содержать логин и пароль.
  • Легкая диагностика ошибок. Обнаруженная ошибка должна быть очевидной.
  • Исследование соответствующей (непосредственно той, что нужно) области приложения, выполнение нужных действий.

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

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

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

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

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

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

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

Пример тест-кейса

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

  • Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
  • Заголовок — краткое, понятное и ёмкое описание сути проверки.
  • Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
  • Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
  • Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.
Читайте также:  Хочется сырого дрожжевого теста

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

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

  1. Заголовок:
    • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
    • не может содержать выполняемые шаги и ожидаемый результат.
  2. Предусловие:
    • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
    • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
    • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
    • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
    • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
    • не может содержать ожидаемый результат.
  3. Шаги проверки:
    • должны быть чёткими, понятными и последовательными;
    • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
      Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»;
    • должны использоваться безличные глаголы.
      Правильно: нажать, ввести, перейти.
      Неправильно: нажмите, введите, идите;
    • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
    • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
  4. Ожидаемый результат:
    • должен быть у каждого шага проверки;
    • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
    • не должно быть избыточного описания.
  5. Общие требования к тест-кейсам:
    • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
    • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
    • тест-кейсы группируются в функциональные блоки по их назначению;
    • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.

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

Примеры

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

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

Номер 1
Заголовок Отправка сообщения через форму обратной связи на странице “Контакты”
Предусловие Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru
Шаг Ожидаемый результат
В верхнем меню сайта нажать на ссылку “Контакты” Открылась страница “Контакты”
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы В поле “Ваше имя” отображается введённое имя
Ввести корректный email в поле “Ваш e-mail” В поле “Ваш e-mail” отображается введённый email
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел В поле “Тема” отображается введённый текст
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел В поле “Сообщение” отображается введённый текст
Ввести в поле капчи требуемое капчей значение В поле капчи отображается введённое значение
Нажать под заполняемой формой на кнопку “Отправить” Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.”
Все заполненные поля очищены.
Проверить почту администратора сайта На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5.

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

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

Номер 1
Заголовок Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?)
Предусловие Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага)
Шаг Ожидаемый результат
Нажать на ссылку “Контакты” (Где она находится?) Открылась страница (Какая?)
Ввести имя в поле “Ваше имя” (Какие символы вводить?) (Ничего не указано в ожидаемом результате, что должно произойти?)
Ввести email в поле “Ваш e-mail” (корректный или некорректный?) В поле отображается email (Какой? Введённый? В каком поле отображается?)
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?) В поле “Тема” отображается текст (Какой?)
Ввести в поле “Сообщение” текст (Какие символы вводить?) Видим в поле “Сообщение” введённый текст (Видим или отображается?)
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести). В поле капчи будет введённое значение (Что будет делать? Танцевать?)
Нажать под заполняемой формой на кнопку (На какую?) Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?)
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)

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

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

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

Источник