Тест кейсы для тестирования

Тест кейсы для тестирования

У нас есть масштабный проект, который нужно тестировать.

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

В статье расскажем и покажем на примерах,

  • как mind maps помогают лучше тестировать,
  • как писать тест-кейсы для масштабного проекта,
  • как оценить, хороши тест-кейсы или нет.

Вот что умеет наш проект:

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

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

У пользователя помимо основной роли есть ограничения со стороны системы бронирования (например, принадлежность к тому или иному сообществу). В итоге для услуги «оформление багажа» в получается около 30-ти конечных веток функциональности.

Проблема: нужна методология, как вести тестовую документацию на проектах подобного масштаба.

Наш подход:

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

Mind map
В составлении карты приложения хорошо себя показал метод исследовательского тестирования.

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

Что ж, посмотрим, как этот метод нам поможет.

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

Раскручиваем. С какими внешними сервисами мы интегрируемся? На что это влияет в нашей системе? Какую функциональность мы предоставляем пользователю? Давайте разбивать функциональность на части.

Давайте возьмем одну функцию нашей системы — продажа багажа. Что нужно сделать, чтобы её оформить?

  • Нужен клиент, которому мы продаём.
  • Ещё нам надо понять тип: со скидкой или без мы продадим этот багаж.
  • Вспоминаем про то, что в системе две роли, и услуга должна быть доступна для обеих.

Самое главное — отдавать себе отчет в том, какую часть функциональности мы сейчас описываем.

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

Получается примерно так:

Для интереса можно также рассмотреть интеграционные ветки:

Что ещё хорошо: в процессе составления наглядно видно, как мы будем группировать тест-кейсы по сьютам. И если какая-то группировка окажется неудачной, то можно оперативно перегруппировать.

Какие ограничения
К сожалению, mind map недостаточно по трем причинам:

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

Все эти проблемы решаются написанием тест-кейсов.

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

Если в mind map упор был на описание, а в тест-кейсе упор уже будет на проверку.

Тест-кейсы на практике

Чего мы хотим от тест-кейсов?

  1. Чтобы из названия было понятно, что именно мы проверяем. Мы составляем отчет о тестировании в формате Excel. В отчете по названию тест-кейса должно быть понятно, что работает, а что нет.
  2. Чтобы они были атомарными, то есть одно действие пользователя/системы равнялось одному тест-кейсу.
  3. Чтобы оставалось место для человеческого фактора и творчества. Этим мы автоматически обезопасим себя от «парадокса пестицида».
  4. Чтобы тестировщик понимал, что он проверяет и почему должно работать именно так (воспитание критического взгляда).

Как написать хороший тест-кейс. Первый пример.
Давайте посмотрим на тест-кейсы более пристально. Начнём с первого и главного — авторизации в систему. Внимательно смотрим на эту картинку:

Что с ней не так? А вот что.

  • Если в итоге тестирования этот тест-кейс упадёт, то что это будет означать? Что для вас значит фраза «Авторизация в систему не работает»? Страница авторизации не открылась? Ошибка «Пользователь не найден»? Сервис авторизации «прилег» и на все запросы отвечает кодом 500? Пользователь авторизовался, но элементы на UI не прорисованы? Пользователь авторизовался, но видит «не свой» интерфейс? Получается, мы увидели проблему, но не поняли причину и при каких условиях она возникает.
  • Сценарий не атомарен. Всё смешано всё в кучу: и определение роли, и проверка на наличие доступа, и кнопка логаута.
  • Допустим, что тестировщик авторизовался всеми указанными пользователями и увидел, что открылся один и тот же UI. Это потому, что наша система сломалась, или потому, что такие данные пришли извне? Неясно.
Читайте также:  Почему телефон сам по себе выключается lenovo

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

Мы узнаём о роли пользователя из тех данных, что приходят извне. Соответственно, напрашивается уже другое название тест-кейса: «Определение роли пользователя при авторизации». Переименовываем его.

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

Исправим всё это и получим вот что:

Здесь есть корректное название тест-кейса, описание механизма определения, какой UI показывать пользователю и откуда взять логины с паролями для доступа.

Аналогично создаем следующий сценарии: «У пользователя нет роли в системе», «Логаут из приложения». Да, сценариев станет больше, зато проверки будут более осмысленными.

Второй пример
Давайте посмотрим, как описывать тест-кейсы для функциональных проверок на примере продажи багажа. В теории mind map выглядел просто, а на практике только на определение типа услуги построено вот сколько веток:

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

А можно подумать и задать себе вопрос:«Что именно мы сейчас проверяем-то?» Правильность определения типа услуги. В нашем случае этот сценарий одинаков для обеих ролей. Значит, не так уж важно, под какой ролью мы его проверим. Одним вопросом мы сэкономили время на тестирование.

Третий пример
Вот сценарий оформления услуги на рейс «Туда-Обратно», написанный до mindmap и вопросов о смысле наших действий. Давайте посмотрим на него свежим взглядом.

Итак, мы оценили первый шаг и задали наводящие вопросы менеджеру проекта: «Автоматически выбран ближайший рейс, а почему? Какие варианты выбора у нас есть ещё?» Узнали, что нюансы дефолтного выбора рейса для оформления услуги довольно обширны, и рейс «туда-обратно» — это только частность.

Сделали вывод для себя: имеет смысл вынести проверку «Принцип автоматического выбора рейса» в отдельный тест-кейс, где и рассказать, по какому принципу вообще происходит этот выбор. Мы не успокоились на этом и проанализировали все четыре шага. Не будем вдаваться в подробности, надеемся, что смысл происходящего вы уже поняли.

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

В процессе осознания подхода к написанию тест-кейсов незаметно родились такие вещи как:

  • методология составления тест-кейсов: всем понятно, откуда брать сценарии, как их писать и как их ревьюить,
  • база знаний, где есть не только логины, но и «как поменять курс валют в БД», «как внести изменения в файл настроек», «какие классы эквивалентности используются в проекте» и т.д.,
  • максимальная локализация потенциального бага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из классических заданий ассессмента считается тест «Сценарии», способный безошибочно оценить управленческие навыки кандидата при небольших временных и денежных затратах. Подобный формат удобен как для соискателя, так и для HR: время, затрачиваемое на проверку и оценку способностей, сводится к минимуму. Помимо собеседований, тестирование используется при отборе кандидатов на престижные стажировки или проекты, а также при повышении в должности или во время очередной проверки квалификации.

Какие управленческие стили определяет «Сценарий» тест

Тест управленческих стилей оценивает главные навыки руководителей и их управленческий потенциал. Главные преимущества тестирования – объективность и достоверность при оценке трех базовых компонентов управленческого анализа:

Читайте также:  Не входит в биос ноутбук acer

Управленческие стили в тест Сценарии

Базовый навык Описание Возможные варианты управленческого стиля
Расстановка приоритетов Умение планировать время, распределять усилия, учитывая все аспекты сложившейся ситуации и использовать адаптивный подход к решению проблем. — Панорамный подход;
— Делегирование полномочий.
Управление людскими ресурсами Навыки работы с людьми и способность поддерживать необходимый уровень мотивации у подчиненных. Способность построения команды, рабочей группы и забота о подчиненных. — Командная работа;
— Стиль одиночки.
Сохранение авторитета Понимание принципов управления и создания репутации. Готовность работать в интересах компании. — Стремление к признанию собственных заслуг;
— Соблюдение корпоративных интересов.

Формат Сценарий тестов и Кейс тестов

Тесты сценарии и кейс тесты (case test) разрабатываются международными консалтинговыми или кадровыми агентствами под нужды работодателя. Однако в отличие от сложных и объемных упражнений по анализу кейсов тестирование более стандартизировано. Вопросы, варианты ответов и профиль оцениваемых навыков могут отличаться, но структура испытания, как правило, остается неизменной.

В задании теста описывается жизненный или гипотетический сценарий, сообщается вводная информация. Соискатель выбирает из нескольких вариантов ответа (от 3 до 5), как бы он поступил в подобной ситуации.

Как правило, встречаются три типа вопросов:

  1. Выбор одного правильного варианта;
  2. Оценка каждого варианта по шкале от 1 до 5;
  3. Расстановка ответов по эффективности .

Время на прохождение задания ограничено. В среднем упражнение занимает 40 минут и включает 15-20 сценариев-вопросов.

Преимущества ситуационных заданий

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

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

Для кого предназначен тест

Ситуационные сценарии и личностные испытания используются в практике HR для подбора персонала на руководящие должности. Они часто встречаются на многоэтапных отборах на престижные стажировки или конкурсы для управленцев, например, на конкурс «Лидеры России». Благодаря тестированию выявляются слабые места человека. Результаты теста используются в качестве основания для прохождения курсов или семинаров по повышению квалификации.

Сложности

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

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

Как готовиться к «Сценарий» тестам

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

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

  • Легко находить в них различия;
  • Понимать, о наличии или отсутствии каких навыков идет речь;
  • Знать, как они характеризуют претендента.

Результаты

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

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

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

Ссылка на основную публикацию
Телефон леново включается но не запускается
Бывает, что пользователь включает свой смартфон, процесс доходит до заставки (логотипа) и дальше не грузится. Сразу начинается паника, ведь телефон...
Сфера деятельности интернет провайдера
Может предоставлять услуги: Однако самыми распространенными являются услуги виртуального хостинга, регистрации доменов и VDS. Технические аспекты Задача хостинговой компании —...
Сфинкс вижн форум пользователи
Здравствуйте. Сделал поиск по фильмам. Все работает, но почему то не могу сделать ранжирование поиска. Через апи поставил $sphinx->SetFieldWeights(array ('item_runame'...
Телефон леново инструкция для чайников
Большинство из нас чувствует себя неуверенно, когда приходится знакомиться с новой операционной системой. И несмотря на то, что Андроид сегодня...
Adblock detector