Создание тест кейсов в excel

Обновлено: 02.07.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

ТЕСТ КЕЙС (TEST CASE) – это комплекс исходных данных, условий и ожидаемых результатов, разработанный с целью проверки требуемого свойства продукта. Test cases, собранные в последовательность для достижения некоторой цели образуют test suite (набор тестов).

Содержание

Чтобы больше прояснить ситуацию с терминами и определениями, давайте сопоставим некоторые термины касательно этой темы:

Тест-кейс и тест = синоним
Не путаем чек-лист и тест. Отличие тест кейса от чек-листа заключается в том, что чек-лист это всего лишь идея будущего теста, а тест кейс, как мы говорили выше, набор данных и ожидаемых результатов. Часто чек лист становится хорошим началом атрибута Test description в тест-кейсе.
Не путаем тест план и тест кейс. Что касается мы уже определились, а вот тест план это фундаментальный документ, который описывает разные аспекты процесса тестирования. Подробно о тест плане мы поговорим в отдельной статье.
Тест сценарий и тест кейс, также неравны. Тестовый сценарий (test scenario) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Хороший тестовые сценарии и тест кейсы в нем всегда следуют некоторой логике, например: типичному использованию приложения, удобству тестирования, распределению функций по модулям и т.д.

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

В чем сложность написания тест кейсов?

Признаться честно, разработка тест кейсов не совсем приятное для многих тестировщиков занятие. И эта неприязнь легко поддается объяснению, ведь их создание требует от Software Testing Engineer следующего:

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

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

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

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

Зачем нужно написание тест кейсов?

Как мы отмечали выше создание тестов не простое занятие для большинства нестировщиков. Тем не менее, позитивные свойства качественных тест кейсов заключаются в том, что они позволяют:

Найти проблемные места в требованиях. Если требование не понятно и не тестируемо в принципе, то написание тест кейса это проявит. Вместе с тем, здесь нужно быть предельно ответственным, нельзя копипастить требования в ТК.
Структурировать всю информацию. Логика и структура дадут нам больше шансов тратить меньше времени на вникание в сам тест кейс (одно будет вытекать из другого). Кейсы, максимально замапленные на требования, позволяют потом не искать, откуда же эта информация взята.
Ускорить регрессию. Чтобы провести качественный регресс, надо выбрать правильные тест кейсы smoke test, высокоуровневый тест кейсы и тд. Помимо этого, тест кейсы, содержащие максимум вспомогательной информации: логины, пароли – тем самым экономим время.
Хранить и собирать информацию. Все сложные настройки должны быть описаны в тест кейсах (логины, пароли, валидация полей, сертификаты, данные карт и тд.). Всегда можно приатачить к кейсам дополнительные файлы с нужной инфой или даже какое-то важное письмо.
Отслеживать процесс тестирования. Тут важно отметить следующие особенности, что одна ячейка таблицы=один тест, так четко и без проблем ставим статус. Можно создаем статистику (пройдено /не пройдено, не протестировано)

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

Как писать тест кейсы?

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

Подробный или общий?
Позитивный или негативный?
Простой или сложный?
Независимый или объединенный?

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

Подробный или общий тест кейс?

Пример оформления 1

2.In the field B, type 3

3.Click Add button.

Плюсы и минусы

Проходящий все время будет вбивать одно и тоже и не проверит другие значения
Если тест-кейс слишком общий, то можно не так понять (без примеров) и ввести не то
Более подробные кейсы требуют много времени на создание
Новичку не подробный тест будет тяжело проходить

Пример оформления 2

1.In the field A, enter valid integer

2.In the field B, enter valid integer

3.Click Add button.

Плюсы и минусы

Мы не привязаны к точным значениям
Время на поддержку теста сокращается
Мы перечисляем конкретные цифры, которые должны быть проверены в тесте

Позитивные или негативные тест кейсы?

Что касается этого вопроса, то здесь следует помнить несколько простых принципа:

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

Помня эти принципы, тестировщику проще не совершить крен в ту или иную сторону будь-то при написании тест кейсов игры или use case testing.

Простые или сложные тест кейсы?

Начиная разработку ТК сотруднику необходимо помнить, следующую последовательность разработки, а потом и выполнения тестов:

Простые позитивные
Простые негативные
Сложные позитивные
Сложные негативные

Такая очередность позволяет оптимизировать процесс написания и в дальнейшем легче определять приоритет тест кейса.

Независимые или объединенные тест кейсы?

В данной ситуации нет однозначного ответа да этот вопрос, все зависит от конкретного проекта. Поэтому просто перечислим типичные характеристики данных тест кейсов

Независимые:

Независимые тесты быстро и легко проходим
Можно продолжать тестирование, если один тест упал
Проходить тесты можно в любом порядке

Объединенные:

Сценарии повторяют поведения пользователя
Эффективны, когда в 1 шаге у нас по 10 подшагов
Мы не создаем каждый раз новые данные, а используем созданное на предыдущем шаге
Характерны для интеграционного и системного тестирования

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

Best practices тест кейсы:

Используйте простой разговорный язык
Всегда используйте полное описание и наименование элементов
Не объясняйте Windows basics
[button], (?), “field name”, ‘label’
“Open”, а не “go”

Теперь пришло время поговорить про поля тест кейса и характерные атрибуты.

Что может являться атрибутом тест кейса?

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

Названия атрибутов тест кейса
ID	Priority	Req. ID	Module	Sub-Module	Test description	Expected result	Result	Comment

Следует отметить, что атрибуты тест кейса могут отличаться в зависимости от компании и инструмента, с помощью которого данные тесты создаются, поэтому мы перечислим наиболее распространенные атрибуты тест кейса:

Написание тест кейсов: примеры

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

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

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

Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

Чек-листы vs Тест-кейсы

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

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

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

Плюсы такого подхода:

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

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

Таблицы vs Деревья

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

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

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

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

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

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

такая структура тестовой документации требует тщательного проектирования и предварительной аналитики — при плохом проектировании все упомянутые выше плюсы теряются

Итоговые паттерны

Экраны приложения

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

Ниже в качестве примера приведена общая схема рассуждений при декомпозиции раздела заказов агрегатора авиабилетов.

К листьям этого дерева крепим короткие чек-листы. Так к каждому листу «навбар» линкуем чек-лист на элементы навбара для текущего экрана:

А к каждому листу «секция запланированные поездки» линкуем чек-лист на проверку части списка с активными заказами:

Критерии для выбора такого паттерна следующие:

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

Объекты/действия

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

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

Ниже приведен пример общей схемы рассуждений при декомпозиции по принципу объект/действие.

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

Например, для уже упомянутого чата схема документации будет выглядеть примерно так:

Критерии выбора такого паттерна:

цель — протестировать функциональность
сложная бизнес-логика
частые правки дизайна
стратегия тестирования на проекте подразумевает сочетание скриптового и исследовательского тестирования

На базе Use cases

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

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

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

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

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

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

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

Критерии выбора такого паттерна:

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

Отталкиваемся от цели

Мы сменили инструмент и выработали новые подходы к ведению тестовой документации, но от старых подходов не отказывались. Выбор стратегии зависит от потребностей на проекте и приоритетов заказчика. Если логика приложения простая и проект длится недолго, то обычно достаточно стандартных чек-листов на функциональность с минимальной подробностью. Если проект большой, сложный и без требований, то на часть фич стоит написать полноценную «древовидную» документацию. Если на проекте есть хорошо задокументированные требования, то иногда можно не тратить время на написание тестов по функциональности, зато можно уделить больше внимания нефункциональному тестированию (производительности, безопасности) и систематизировать его – опять же, если есть соответствующая договоренность с заказчиком. Или задокументировать только «рискованные» тесты. Юзер-стори все равно пишем почти всегда, но уже не такие подробные — как приемку для заказчика или как смоук-тест, а проведенная до этого работа по декомпозиции помогает нам быстро проектировать сценарий и правильно расставлять приоритеты.

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

Читайте также: