5.

Написание тест-кейсов и чек-листов

5.1. Тест-кейсы, чек-листы, тестовые сценарии и различие между ними.
Что такое тест-кейс?
Тест-кейс (test case) — набор входных данных, условий выполнения и ожидаемых результатов,
разработанный с целью проверки того или иного свойства или поведения программного
средства.
Наличие тест-кейсов позволяет:
1) структурировать и систематизировать подход к тестированию;
2) вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его
увеличению;
3) отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-
кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе
количества и т.д.);
4) уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками;
5) хранить информацию для длительного использования и обмена опытом между
сотрудниками и командами;
6) проводить регрессионное тестирование и повторное тестирование;
7) повышать качество требований;
8) быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.
Обычно тест-кейс оформляют в виде технического документа,который имеет общепринятую
структуру, компоненты которой называются атрибутами (полями) тест-кейса. Общий вид
структуры тест-кейса представлен на рисунке:

Теперь рассмотрим каждый атрибут подробно.

Идентификатор (identifier) представляет собой уникальное значение, позволяющее
однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В
общем случае идентификатор тест-кейса может представлять собой просто уникальный номер,
но может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные
компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или
требований), к которой он относится.
 Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B,
C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий»,
«крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но
чаще всего лежит в диапазоне от трёх до пяти. Приоритет тест-кейса может коррелировать с:
1) важностью требования, пользовательского сценария или функции, с которыми связан
тест-кейс;
2) потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
3) степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или
функцией.
Основная задача этого атрибута — упрощение распределения внимания и усилий команды, а
также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей
форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование (requirement) показывает то основное требование,
проверке выполнения которого посвящён тест-кейс.
Частые вопросы, связанные с заполнением этого поля, таковы:
1) Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой
привязки к требованиям, и значение этого поля определить сложно. Хоть такой вариант
и не считается хорошим, он достаточно распространён.
2) Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются
выбрать одно самое главное или «более высокоуровневое». Чаще всего в инструментах
управления тестами это поле представляет собой выпадающий список, где можно
выбрать только одно значение, и этот вопрос становится неактуальным. К тому же
многие тест-кейсы всё же направлены на проверку строго одного требования, и для них
этот вопрос также неактуален.
Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к
которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на
модули и подмодули проистекает из того, что в сложных системах практически невозможно
охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение»
становится недопустимо сложным. Тогда приложение логически разделяется на компоненты
(модули), а те, в свою очередь, на более мелкие компоненты (подмодули). И вот уже для таких
небольших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится
намного проще. Как правило, иерархия модулей и подмодулей создаётся как единый набор для
всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут
использовать разные подходы к такому разделению или даже просто разные названия одних и
тех же частей приложения.
Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочетаний
— главное, чтобы выполнялись следующие условия:
1) информативность;
2) хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).
Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation,
initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала
выполнения тест-кейса, например:
1) состояние базы данных;
2) состояние файловой системы и её объектов;
3) состояние серверов и сетевой инфраструктуры.

Всё, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и
таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
Эта мысль очень и очень важна, потому поясним её простым жизненным примером.
Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать
«купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже,
если закрыт магазин, если не хватило денег и т.д. — всё это НЕ проблемы вкуса конфет, и нельзя
писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».
Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо
реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов
таковы:
1) начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск
приложения, очевидные операции с интерфейсом и т.п.);
2) даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в
будущем случайно «приклеить» описание этого шага к новому тексту);
3) если вы пишете на русском языке, используйте безличную форму (например, «открыть»,
«ввести», «добавить» вместо «откройте», «введите», «добавьте»);
4) соотносите степень детализации шагов и их параметров с целью тест-кейса, его
сложностью, уровнем и т.д. — в зависимости от этих и многих других факторов степень
детализации может варьироваться от общих идей до предельно чётко прописанных
значений и указаний;
5) ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста
(например, «повторить шаги 3–5 со значением…»);
6) пишите шаги последовательно, без условных конструкций вида «если… то…».
Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы
целиком: если те, другие тесткейсы будут изменены или удалены, ваш тест-кейс начнёт
ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-
кейсы или шаги приведут к возникновению ошибки, вы не сможете закончить выполнение
вашего тест-кейса.
Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию
приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует
номеру результата. По написанию ожидаемых результатов можно порекомендовать следующее:
1) описывайте поведение системы так, чтобы исключить субъективное толкование (например,
«приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо);
2) пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие
сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если
вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше
оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие);
3) пишите кратко, но не в ущерб информативности;
4) избегайте условных конструкций вида «если… то…».
В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не
может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной
системе и аварийно завершается с потерей всех пользовательских данных».
При этом корректная работа приложения вполне может предполагать отображение сообщений о
неверных действиях пользователя или неких критических ситуациях. Так, сообщение
«Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно
свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная
работа. Ошибкой приложения (в этой же ситуации) было бы отсутствие такого сообщения, и/или
повреждение, или потеря записываемых данных.
Свойства качественного тест-кейса:
 Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём
нарушено одно из следующих свойств:
1) Правильный технический язык.
- пишите лаконично, но понятно;
- используйте безличную форму глаголов (например, «открыть» вместо
«откройте»);
- обязательно указывайте точные имена и технически верные названия элементов
приложения;
- не объясняйте базовые принципы работы с компьютером (предполагается, что
ваши коллеги знают, что такое, например, «пункт меню» и как с ним работать).
2) Баланс между специфичностью и общностью. Тест-кейс считается тем более
специфичным, чем более детально в нём расписаны конкретные действия, конкретные
значения и т.д., т.е. чем в нём больше конкретики. Соответственно, тест-кейс считается
тем более общим, чем в нём меньше конкретики.
Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой
тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):

Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой —

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

В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он
стал короче и проще для выполнения, а отсутствие строго указанных значений приводит
к тому, что при многократном выполнении тест-кейса (особенно — разными
тестировщиками) конкретные параметры будут менять свои значения, что увеличивает
вероятность обнаружения ошибки. Ещё раз главная мысль: сами по себе специфичность
или общность тест кейса не являются чем-то плохим, но резкий перекос в ту или иную
сторону снижает качество тест-кейса.
3) Баланс между простотой и сложностью. Здесь не существует академических
определений, но принято считать, что простой тест-кейс оперирует одним объектом (или
в нём явно виден главный объект), а также содержит небольшое количество тривиальных
действий; сложный тест-кейс оперирует несколькими равноправными объектами и
содержит много нетривиальных действий.

Преимущества простых тест-кейсов:

 - их можно быстро прочесть, легко понять и выполнить;
- они понятны начинающим тестировщикам и новым людям на проекте;
- они делают наличие ошибки очевидным (как правило, в них предполагается выполнение
повседневных тривиальных действий, проблемы с которыми видны невооружённым
взглядом и не вызывают дискуссий);
- они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.
Преимущества сложных тест-кейсов:
- при взаимодействии многих объектов повышается вероятность возникновения ошибки;
- пользователи, как правило, используют сложные сценарии, а потому сложные тесты
более полноценно эмулируют работу пользователей;
- программисты редко проверяют такие сложные случаи (и они совершенно не обязаны
это делать).
Рассмотрим примеры.
Слишком простой тест-кейс:

Слишком сложный тест-кейс:

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

4) «Показательность» (высокая вероятность обнаружения ошибки). Тест-кейс является тем

более хорошим, чем он более показателен (с большей вероятностью обнаруживает
ошибку).
Пример непоказательного (плохого) тест-кейса:

Пример показательного (хорошего) тест-кейса:

 Обратите внимание, что показательный тест-кейс по-прежнему остался достаточно
простым, но он проверят ситуацию, возникновение ошибки в которой несравненно более
вероятно, чем в ситуации, описываемой плохим непоказательным тест-кейсом. Также
можно сказать, что показательные тест-кейсы часто выполняют какие-то «интересные
действия», т.е. такие действия, которые едва ли будут выполнены просто в процессе
работы с приложением (например: «сохранить файл» — это обычное тривиальное
действие, которое явно будет выполнено не одну сотню раз даже самими разработчиками,
а вот «сохранить файл на носитель, защищённый от записи», «сохранить файл на носитель
с недостаточным объёмом свободного пространства», «сохранить файл в папку, к которой
нет доступа» — это уже гораздо более интересные и нетривиальные действия).
5) Последовательность в достижении цели. Суть этого свойства выражается в том, что
все действия в тест-кейсе направлены на следование единой логике и достижение единой
цели и не содержат никаких отклонений. Примерами правильной реализации этого
свойства могут служить представленные в этом разделе в избытке примеры хороших тест-
кейсов. А нарушение может выглядеть так:

Шаги 3–5 никак не соответствуют цели тест-кейса, состоящей в проверке корректности

конвертации входных данных, представленных во всех поддерживаемых кодировках.
6) Отсутствие лишних действий. Чаще всего это свойство подразумевает, что не нужно
в шагах тест-кейса долго и по пунктам расписывать то, что можно заменить одной фразой:
 Вторая по частоте ошибка — начало каждого тест-кейса с запуска приложения и
подробного описания по приведению его в то или иное состояние. В наших примерах мы
рассматриваем каждый тест-кейс как существующий в единственном виде в
изолированной среде, и потому вынуждены осознанно допускать эту ошибку (иначе тест-
кейс будет неполным), но в реальной жизни на запуск приложения будут свои тесты, а
длинный путь из многих действий можно описать как одно действие, из контекста
которого понятно, как это действие выполнить. Следующий пример тест-кейса не
относится к нашему «Конвертеру файлов», но очень хорошо иллюстрирует эту мысль:

7) Неизбыточность по отношению к другим тест-кейсам. В процессе создания

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

Выдержка из демонстративного тест-кейса:

 В первом случае тест-кейс плох не только расплывчатостью формулировки «корректный
вид в кодировке UTF-8 с учётом английских букв», там также очень легко допустить
ошибки при выполнении:
- забыть сконвертировать вручную входной текст в KOI8-R;
- не заметить, что в первый раз расширение начинается с пробела;
- забыть заменить в слове «Пример» буквы «р» на английские;
- из-за расплывчатости формулировки ожидаемого результата принять ошибочное, но
выглядящее правдоподобно поведение за верное.
Второй тест-кейс чётко ориентирован на свою цель по проверке конвертации (не
содержит странной проверки с игнорированием файла с неверным расширением) и описан
так, что его выполнение не представляет никаких сложностей, а любое отклонение
фактического результата от ожидаемого будет сразу же заметно.
9) Прослеживаемость. Из содержащейся в качественном тест-кейсе информации должно
быть понятно, какую часть приложения, какие функции и какие требования он проверяет.
Пример непрослеживаемого тест-кейса:

Пример прослеживаемого тест-кейса:

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

11) Соответствие принятым шаблонам оформления и традициям. С шаблонами

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

Что такое чек-лист?

Чек-лист (checklist) — это список, содержащий ряд необходимых проверок во время
тестирования программного продукта. У чек-листа нет подробного описания действий. Главный
принцип чек-листов заключается в том, что каждый тестировщик по-своему проходит их,
расширяя тестовый набор своей экспертизой.
Чек-лист нужен чтобы:
1. не забыть требуемые тесты;
2. делить задачи по уровню квалификации;
3. сохранять отчетности и результаты тестирования.
Чек-лист содержит:
1. список проверок;.
2. окружение проверки:
○ сборка, на которой проводилось тестирование;
○ тестовое окружение (если применимо);
○ информация о тестировщике;
3. результат проверки.

Как правило, чек-листы делают в Google-таблице для обеспечения общего доступа всем QA-
специалистам. При прохождении чек-листов тестировщик отмечает статус напротив каждого
тестируемого пункта.
Возможны следующие варианты статусов:
● «Passed» – проверка пройдена успешно, багов не найдено;
 ● «Failed» – найден один или более багов;
● «Blocked» – невозможно проверить, т.к. один из багов блокирует текущую проверку;
● «In Progress» – текущий пункт, над которым работает тестировщик;
● «Not run» – еще не проверено;
● «Skipped» – проверяться не будет по какой-либо причине. Например, текущий
функционал еще не реализован.
Для большей наглядности, как правило, каждый из статусов имеет свой цвет.

Отметим несколько основных моментов, которые стоит учитывать при работе с чек-листами:
1. По завершении прохождения чек-листа не должно остаться ячеек со статусом «Not run».
2. Все ячейки со статусом «Failed» и «Blocked» обязательно должны иметь примечания со
ссылками на баг-репорты.
3. Статус «Passed» устанавливается только для пунктов, которые проверены и не содержат
ошибок.
Rules for drawing up checklists:
1. One point - one operation. Checklist items are unambiguous atomic and complete operations.
For example, adding an item to a website cart and paying for an order are two different tasks. In
the list of checks, such operations are formalized as separate items: the item was added to the
cart, the payment was sent.
2. Points start with a noun. The purpose of the checklist is to take into account all the actions for
the most complete coverage with software tests, therefore, when compiling points, you should
adhere to a unified form. For a clear and unambiguous presentation, it is better to start
paragraphs with a noun - "Check", "Add", "Submit" or an indefinite verb - "Check", "Add",
"Send".
3. Drawing up a checklist by levels of detail. For the convenience of passing the checklist, it is
best to make a list in a form that will be consistent based on the logic of using the functionality.
Within the section "Registration and Personal Profile": registration on the site, editing the
profile. Section "Feedback form": field validation, letter sending, letter delivery.

Правила составления чек-листов:

1. Один балл - одна операция. Пункты контрольного списка однозначно представляют
собой элементарные и полные операции. Например, добавление товара в корзину на
сайте и оплата заказа - две разные задачи. В списке чеков такие операции оформляются
отдельными позициями: товар добавлен в корзину, оплата отправлена.
2. Очки начинаются с существительного. Цель чек-листа - учесть все действия для
наиболее полного покрытия тестами ПО, поэтому при составлении баллов следует
придерживаться единой формы. Для ясного и однозначного изложения абзацы лучше
начинать с существительного - «Проверить», «Добавить», «Отправить» или
неопределенного глагола - «Проверить», «Добавить», «Отправить».
3. Составление чек-листа по уровням детализации. Для удобства прохождения
контрольного списка лучше всего составить список в форме, которая будет согласована в
зависимости от логики использования функциональности. В разделе «Регистрация и
 личный кабинет»: регистрация на сайте, редактирование профиля. Раздел «Форма
обратной связи»: проверка полей, отправка писем, доставка писем.

Преимущества использования чек-листов:

● нивелирование эффекта пестицида в регрессионном тестировании;
● расширение тестового покрытия за счёт отличий при прохождении;
● сокращение затрат на содержание и поддержку тестов: не надо писать много букв!
● отсутствие рутины, которую так не любят квалифицированные тестировщики;
● возможность проходить и комбинировать тесты по-разному, в зависимости от
предпочтений сотрудников.
Недостатки использования чек-листов:
● начинающие тестировщики не всегда эффективно проводят тесты без достаточно
подробной документации;
● чек-листы невозможно использовать для обучения начинающих сотрудников, так как в
них недостаточно подробной информации;
● заказчику или руководству может быть недостаточно того уровня детализации, который
предлагают чек-листы.
Thus, if the company has a high staff turnover, low-skilled employees, or the management requires it,
you will have to create and maintain detailed, detailed test cases. But if your team has qualified
employees, then checklists are much more convenient and will help you get the most out of your test
documentation without wasting time on bureaucracy.
Таким образом, если в компании высокая текучесть кадров, низкоквалифицированные
сотрудники или этого требует руководство, вам придется создавать и поддерживать подробные,
подробные тестовые примеры. Но если в вашей команде есть квалифицированные сотрудники,
то контрольные списки намного удобнее и помогут вам максимально эффективно использовать
тестовую документацию, не тратя время на бюрократию.

Что такое тестовый сценарий?

Тестовый сценарий— совокупность тест-кейсов, выбранных с некоторой общей целью или по
некоторому общему признаку.
Как мы убедились на примере множества отдельных тест-кейсов, крайне неудобно каждый раз
писать в каждом тест-кейсе одни и те же приготовления и повторять одни и те же начальные
шаги. Намного удобнее объединить несколько тест-кейсов в набор или последовательность.
В общем случае тестовые сценарии можно разделить на свободные (порядок выполнения тест-
кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
- тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы
внутри наборов»;
- если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность
выполнения других тест-кейсов.
Преимущества последовательных наборов:
- каждый следующий в наборе тест-кейс в качестве входного состояния приложения
получает результат работы предыдущего тест-кейса, что позволяет сильно сократить
количество шагов в отдельных тест-кейсах;
- длинные последовательности действий куда лучше имитируют работу реальных
пользователей, чем отдельные «точечные» воздействия на приложение.
 К отдельному подвиду последовательных наборов тест-кейсов можно отнести
пользовательские сценарии ,представляющие собой цепочки действий, выполняемых
пользователем в определённой ситуации для достижения определённой цели.
Поясним это сначала на примере. Допустим, пользователь хочет распечатать табличку на дверь
кабинета с текстом «Идёт работа, не стучать!» Для этого ему нужно:
1) Запустить текстовый редактор.
2) Создать новый документ (если редактор не делает это самостоятельно).
3) Набрать в документе текст.
4) Отформатировать текст должным образом.
5) Отправить документ на печать.
6) Сохранить документ (спорно, но допустим).
7) Закрыть текстовый редактор.
Вот мы и получили пользовательский сценарий, пункты которого могут стать основой для
шагов тест-кейса или целого набора отдельных тест-кейсов. Сценарии могут быть достаточно
длинными и сложными, могут содержать внутри себя циклы и условные ветвления, но при всём
этом они обладают рядом весьма интересных преимуществ:
- сценарии показывают реальные и понятные примеры использования продукт;
- сценарии понятны конечным пользователям и хорошо подходят для обсуждения и
совместного улучшения;
- сценарии и их части легче оценивать с точки зрения важности, чем отдельные пункты
требований;
- сценарии отлично показывают недоработки в требованиях;
- в предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не
прописывать подробно, а просто именовать — и само наименование уже подскажет
опытному специалисту, что делать.
Подробная классификация тестовых сценариев:
Подробная классификация наборов тест-кейсов может быть выражена следующей таблицей:

- Набор изолированных свободных тест-кейсов: действия из раздела «приготовления»

нужно повторить перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в
любом порядке:
- Набор обобщённых свободных тест-кейсов: действия из раздела «приготовления» нужно
выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы можно
выполнять в любом порядке:

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

«приготовления» нужно повторить перед каждым тест-кейсом, а сами тест-кейсы нужно
выполнять в строго определённом порядке:
 - Набор обобщённых последовательных тест-кейсов: действия из раздела
«приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а
сами тест-кейсы нужно выполнять в строго определённом порядке:

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

него не влияют результаты работы предыдущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).
Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе,
т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для
следующего.
Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также
то, что при провале некоего тест-кейса остальные тест-кейсы по-прежнему можно выполнять.
The principles of building test scenarios.
Now - about the most important thing: how to form test scripts? The correct answer sounds very
short: logical. And it's not a joke. The only task of test scenarios is to increase the efficiency of testing
by speeding up and simplifying the execution of test cases, increasing the depth of exploration of a
certain area of the application or functionality, following typical user scenarios or a convenient
sequence of test cases execution, etc.
A test scenario is created for a purpose, based on some logic, and according to the same principles,
tests with suitable properties are included in it.
If we talk about the most typical approaches to writing a test scenario, then we can outline the
following:
- based on checklists. Look carefully at the examples of checklists that we have developed in the
corresponding section: each checklist item can turn into several test cases - and now we get a
ready-made test script;
- based on splitting the application into modules and submodules. For each module (or its
individual submodules), you can create your own set of test cases;
- on the principle of checking the most important, least important and all other functions of the
application;
- according to the principle of grouping test cases to check a certain level of requirements or type
of requirements, a group of requirements or an individual requirement;
- by the principle of the frequency of detection of defects in the application by test cases (for
example, we see that some test cases fail over and over again, which means that we can
combine them into a set, conventionally called "problem areas in the application");
- on an architectural basis;
- by the area of internal work of the application, for example: "test cases affecting working with
the database", "test cases affecting working with the file system", "test cases affecting working
with the network", etc.;
- by type of testing.
You don't need to memorize this list. These are just examples - roughly speaking, "the first thing that
comes to mind." The principle is important: if you see that running some test cases in the form of a test
script will benefit you, create such a set.

Принципы построения тестовых сценариев.

Теперь о самом главном: как формировать тестовые сценарии? Правильный ответ звучит
очень кратко: логично. И это не шутка. Единственная задача тестовых сценариев - повысить
эффективность тестирования за счет ускорения и упрощения выполнения тестовых примеров,
увеличения глубины исследования определенной области приложения или функциональности,
следуя типичным пользовательским сценариям или удобной последовательности тестовых
примеров. казнь и др.
Сценарий тестирования создается с определенной целью на основе некоторой логики, и
согласно тем же принципам в него включаются тесты с подходящими свойствами.
Если говорить о наиболее типичных подходах к написанию тестового сценария, то можно
выделить следующие:
- на основе чек-листов. Посмотрите внимательно на примеры контрольных списков, которые мы
разработали в соответствующем разделе: каждый элемент контрольного списка может
превратиться в несколько тестовых случаев - и теперь мы получаем готовый тестовый скрипт;
- на основе разделения приложения на модули и подмодули. Для каждого модуля (или его
отдельных подмодулей) вы можете создать свой собственный набор тестовых примеров;
- по принципу проверки наиболее важных, наименее важных и всех остальных функций
приложения;
- согласно принципу группировки тестовых примеров для проверки определенного уровня
требований или типа требований, группы требований или отдельного требования;
- по принципу частоты обнаружения дефектов в приложении по тестовым случаям (например,
мы видим, что некоторые тестовые примеры терпят неудачу снова и снова, а это значит, что мы
можем объединить их в набор, условно называемый «проблемные области в приложение");
- по архитектурной основе;
- по области внутренней работы приложения, например: «тест-кейсы, влияющие на работу с
базой данных», «тест-кейсы, влияющие на работу с файловой системой», «тест-кейсы, влияющие
на работу с сетью» и т.д .;
- по типу тестирования.
Вам не нужно запоминать этот список. Это всего лишь примеры - грубо говоря, «первое, что
приходит в голову». Принцип важен: если вы видите, что выполнение некоторых тестовых
примеров в виде тестового сценария принесет вам пользу, создайте такой набор.

5.2. Логика создания эффективных проверок

There is a simple logic: Tests look for errors. But all the mistakes are impossible to find. This means
that the task of the tester is to find the maximum of IMPORTANT errors in the available time. By
important errors we mean those that lead to the violation of functions or properties of the product
important for the user. Functions and properties are not separated by accident - security, performance,
convenience, etc. are not functional, but play an equally important role in shaping customer and end-
user satisfaction.
There is a fairly simple algorithm that allows us to create efficient checks. When you start thinking
about a checklist, test case or test scenario, ask yourself the following questions and get clear answers:
1) What's in front of you? If you don’t understand what you are going to test, you will not go
beyond thoughtless formal checks.
2) Who needs it and why (and how important is it)? The answer to this question will allow you to
quickly come up with some typical use cases for what you are going to test.
3) How is it commonly used?
4) How can it break, i.e. start working wrong?
To this algorithm, you can add a small list of universal recommendations that will allow you to
conduct testing better:
- Start as early as possible - from the moment the first requirements appear, you can test and
improve them, you can write checklists and test cases, you can refine the test plan, prepare a
test environment, etc.
- If you have to test something large and complex, break it down into modules and submodules,
subject the functionality to functional decomposition - i.e. achieve a level of detail where you
can easily keep in mind all the information about the test object.
- Be sure to write checklists. If you think that you can remember all the ideas and then easily
reproduce them, you are wrong. There are no exceptions.
- As you create checklists, test cases, etc. write the questions that arise directly into the text.
When you have enough questions, collect them separately, clarify the wording and contact
someone who can provide answers.
- If the tool you are using allows you to use cosmetic design of the text, use it (this will make the
text better read), but try to follow generally accepted traditions and do not color every second
word in your own color, font, size, etc.
- Use a quick glance technique to get feedback from colleagues and improve the document you
create.
- Schedule time to improve test cases (bug fixes, revision as requirements change, etc.).
- Start developing (and executing) test cases with simple checks of the most important
functionality. Then gradually increase the difficulty of the tests.
- Remember, testing is based on purpose. If you cannot quickly and easily formulate the purpose
of the test case you created, you have created a bad test case.
- Avoid redundant, duplicate test cases.
- If the exponentialness of the test case can be increased without significantly changing its
complexity and without deviating from the original goal, do so.
- Remember that many test cases require separate preparation, which must be described in the
appropriate field of the test case.
- Think about how you can optimize the test case you created (a set of test cases, etc.) so as to
reduce the labor costs of its execution.
- Before sending the final version of the document you have created, re-read what you have
written (in a good half of the cases, you will find a typo or other flaw).

Логика проста: тесты ищут ошибки. Но все ошибки найти невозможно. Это означает,
что задача тестировщика - найти максимум ВАЖНЫХ ошибок за доступное время. Под
важными ошибками мы понимаем те, которые приводят к нарушению функций или
свойств продукта, важных для пользователя. Функции и свойства не разделены случайно
- безопасность, производительность, удобство и т. Д. Не являются функциональными, но
играют одинаково важную роль в формировании удовлетворенности клиентов и
конечных пользователей.
Есть довольно простой алгоритм, позволяющий создавать эффективные проверки.
Когда вы начинаете думать о контрольном списке, тестовом примере или сценарии
тестирования, задайте себе следующие вопросы и получите четкие ответы:
1) Что перед тобой? Если вы не понимаете, что собираетесь тестировать, вы не пойдете
дальше бездумных формальных проверок.
2) Кому это нужно и зачем (и насколько это важно)? Ответ на этот вопрос позволит вам
быстро найти некоторые типичные варианты использования того, что вы собираетесь
тестировать.
3) Как это обычно используется?
4) Как он может сломаться, т.е. начать работать неправильно?
К этому алгоритму вы можете добавить небольшой список универсальных
рекомендаций, которые позволят вам лучше проводить тестирование:
- Начните как можно раньше - с момента появления первых требований вы можете
тестировать и улучшать их, вы можете писать контрольные списки и тестовые примеры,
вы можете уточнить план тестирования, подготовить тестовую среду и т. Д.
- Если вам нужно протестировать что-то большое и сложное, разбейте его на модули и
подмодули, подвергните функциональность функциональной декомпозиции, то есть
достигните уровня детализации, на котором вы можете легко запомнить всю
информацию об объекте тестирования.
- Обязательно напишите чек-листы. Если вы думаете, что можете запомнить все идеи, а
затем легко их воспроизвести, вы ошибаетесь. Никаких исключений.
- Когда вы создаете контрольные списки, контрольные примеры и т. Д., Записывайте
возникающие вопросы прямо в текст. Когда у вас будет достаточно вопросов, соберите
их отдельно, уточните формулировки и обратитесь к тому, кто может дать ответы.
- Если используемый вами инструмент позволяет использовать косметическое
оформление текста, используйте его (это улучшит читаемость текста), но старайтесь
 следовать общепринятым традициям и не окрашивайте каждое второе слово в свой цвет,
шрифт, размер и т. д.
- Используйте технику быстрого взгляда, чтобы получить обратную связь от коллег и
улучшить создаваемый вами документ.
- Запланируйте время для улучшения тестовых случаев (исправления ошибок, пересмотр
при изменении требований и т. Д.).
- Начните разработку (и выполнение) тестовых примеров с простых проверок наиболее
важных функций. Затем постепенно увеличивайте сложность тестов.
- Помните, что тестирование основано на цели. Если вы не можете быстро и легко
сформулировать цель созданного вами тестового примера, вы создали плохой тестовый
пример.
- Избегайте повторяющихся тестов.
- Если экспоненциальность тестового примера можно увеличить без значительного
изменения его сложности и без отклонения от исходной цели, сделайте это.
- Помните, что многие тестовые примеры требуют отдельной подготовки, которая
должна быть описана в соответствующем поле тестового примера.
- Подумайте, как вы можете оптимизировать созданный вами тестовый пример (набор
тестовых примеров и т. Д.), Чтобы снизить трудозатраты на его выполнение.
- Перед отправкой окончательной версии созданного вами документа перечитайте
написанное (в доброй половине случаев вы обнаружите опечатку или другой
недостаток).

5.3. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов

Ошибки оформления и формулировок
- Отсутствие заглавия тест-кейса.
- Отсутствие нумерации шагов и/или ожидаемых результатов. Наличие этой ошибки
превращает тест-кейс в «поток сознания», в котором нет структурированности,
модифицируемости и прочих полезных свойств — становится очень легко перепутать,
что к чему относится. Даже выполнение такого тест-кейса усложняется, а доработка и
вовсе превращается в каторжный труд.
- Ссылка на множество требований. Иногда тест-кейс действительно затрагивает
несколько требований, но в таком случае рекомендуется писать ссылку на максимум 2–3
самых ключевых (наиболее соответствующих цели тест-кейса), а ещё лучше —
указывать общий раздел этих требований (т.е. не ссылаться, например, на требования
5.7.1, 5.7.2, 5.7.3, 5.7.7, 5.7.9, 5.7.12, а просто сослаться на раздел 5.7, включающий в себя
все перечисленные пункты).
- Использование личной формы глаголов. Если вы пишете требования на русском, то
пишите «нажать» вместо «нажмите», «ввести» вместо «введите», «перейти» вместо
«перейдите» и т.д. В технической документации вообще не рекомендуется «переходить
на личности», а также существует мнение, что личная форма глаголов подсознательно
воспринимается как «чужие бессмысленные команды» и приводит к повышенной
утомляемости и раздражительности.
- Использование прошедшего или будущего времени в ожидаемых результатах. Это не
очень серьёзная ошибка, но всё равно «введённое значение отображается в поле»
читается лучше, чем «введённое значение отобразилось в поле» или «введённое значение
отобразится в поле».
- Постоянное использование слов «проверить» (и ему подобных) в чек-листах. В итоге
почти каждый пункт чек-листа начинается с «проверить …», «проверить…»,
 «проверить…». Но ведь весь чек-лист — это и есть список проверок! Зачем писать это
слово? Сравните:

- Описание стандартных элементов интерфейса вместо использования их устоявшихся

названий. «Маленький крестик справа вверху окна приложения» — это системная кнопка
«Закрыть» (system button «Close»), «быстро-быстро дважды нажать на левую клавишу
мыши» — это двойной щелчок (double click), «маленькое окошечко с надписью
появляется, когда наводишь мышь» — это всплывающая подсказка (hint).
- Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без
комментариев.

Логические ошибки
- Ссылка на другие тест-кейсы или шаги других тест-кейсов.
- Детализация, не соответствующая уровню функционального тестирования. Например, не
нужно на уровне дымового тестирования проверять работоспособность каждой
отдельной кнопки или прописывать некий крайне сложный, нетривиальный и редкий
сценарий — поведение кнопок и без явного указания будет проверено множеством тест-
кейсов, объективно задействующих эти кнопки, а сложному сценарию место на уровне
тестирования критического пути или даже на уровне расширенного тестирования (в
которых, напротив, недостатком можно считать излишнее обобщение без должной
детализации).
- Расплывчатые двусмысленные описания действий и ожидаемых результатов. Помните,
что тест-кейс с высокой вероятностью будете выполнять не вы (автор тест-кейса), а
другой сотрудник, и он — не телепат. Попробуйте догадаться по этим примерам, что
имел в виду автор: «Установить приложение на диск C». (Т.е. в «C:\»? Прямо в корень?
Или как?) «Нажать на иконку приложения». (Например, если у меня есть ico-файл с
иконкой приложения, и я по нему кликну — это оно? Или нет?) «Окно приложения
запустится». (Куда?) «Работает верно». (Ого! А верно — это, простите, как?) «OK». (И?
Что «OK»?) «Количество найденных файлов совпадает». (С чем?) «Приложение
отказывается выполнять команду». (Что значит «отказывается»? Как это выглядит? Что
должно происходить?)
- Описание действий в качестве наименований модуля/подмодуля. Например, «запуск
приложения» — это НЕ модуль или подмодуль. Модуль или подмодуль — это всегда
некие части приложения, а не его поведение. Сравните: «дыхательная система» — это
модуль человека, но «дыхание» — нет.
- Описание событий или процессов в качестве шагов или ожидаемых результатов.
Например, в качестве шага сказано: «Ввод спецсимволов в поле X». Это было бы
сносным заглавием тест-кейса, но не годится в качестве шага, который должен быть
сформулирован как «Ввести спецсимволы (перечень) в поле X». Куда страшнее, если
подобное встречается в ожидаемых результатах. Например, там написано: «Отображение
скорости чтения в панели X». И что? Оно должно начаться, продолжиться, завершиться,
не начинаться, неким образом измениться (например, измениться должна размерность
данных), как-то на что-то повлиять? Тест-кейс становится полностью бессмысленным,
 т.к. такой ожидаемый результат невозможно сравнить с фактическим поведением
приложения.
- «Выдумывание» особенностей поведения приложения. Да, часто в требованиях
отсутствуют самоочевидные (без кавычек, они на самом деле самоочевидные) вещи, но
нередко встречаются и некачественные (например, неполные) требования, которые
нужно улучшать, а не «телепатически компенсировать». Например, в требованиях
сказано, что «приложение должно отображать диалоговое окно сохранения с указанным
по умолчанию каталогом». Если из контекста (соседних требований, иных документов)
ничего не удаётся узнать об этом таинственном «каталоге по умолчанию», нужно задать
вопрос. Нельзя просто записать в ожидаемых результатах «отображается диалоговое
окно сохранения с указанным по умолчанию каталогом» (как мы проверим, что выбран
именно указанный по умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в
ожидаемых результатах писать «отображается диалоговое окно сохранения с выбранным
каталогом “C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно,
т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно).
- Отсутствие описания приготовления к выполнению тест-кейса.
- Слишком длинный перечень шагов, не относящихся к сути (цели) тесткейса. Например,
мы хотим проверить корректность одностороннего режима печати из нашего
приложения на дуплексном принтере. Сравните:

Слева мы видим огромное количество действий, не относящихся непосредственно к тому,

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

Здесь или не указано, что вызов окна «Текущее состояние» происходит гд-ето в другом
приложении, или остаётся загадкой, как вызвать это окно у завершившего работу
приложения. Запустить заново? Возможно, но в тест-кейсе этого не сказано.
- Тест-кейсы, не относящиеся к тестируемому приложению. Например, нам нужно
протестировать фотогалерею на сайте. Соответственно, следующие тест-кейсы никак не
относятся к фотогалерее (они тестируют браузер, операционную систему пользователя,
файловый менеджер и т.д. — но НЕ наше приложение, ни его серверную, ни даже
клиентскую часть):
- Файл с сетевого диска.
- Файл со съёмного носителя.
- Файл, заблокированный другим приложением.
- Файл, открытый другим приложением.
- Файл, к которому у пользователя нет прав доступа.
- Вручную указать путь к файлу.
- Файл из глубоко расположенной поддиректории.

5.4. Классы эквивалентности и граничные условия.

В данном разделе рассмотрим такие техники, как разделение на классы эквивалентности и
анализ граничных значений. Эти техники считаются одними из самых важных при
тестировании, так как:
● они могут использоваться как для отдельного модуля, так и для системы в целом;
● ими интуитивно пользуются каждый день;
● они позволяют минимизировать количество проводимых тестов;
● неправильное использование данных техник может повлечь за собой пропуск критичных
дефектов.
Класс эквивалентности (equivalence class) – это набор данных, обработка которых приводит к
одному и тому же результату. Два теста можно считать эквивалентными, в случае когда:
● они проверяют одну и ту же часть системы (функцию, модуль);
● один тест находит ошибку, то и другой, скорее всего, найдет ошибку и наоборот (если
один не находит ошибку – второй также не находит);
● они используют сходные наборы входных данных;
● чтобы выполнить тесты, необходимо совершить одни и те же операции;
● в результате проведения тестов получаем одинаковые выходные данные и система
находится в одном и том же состоянии:
 ○ срабатывает один и тот же блок обработки ошибки;
○ не срабатывает блок обработки ошибки.
Разделение на классы эквивалентности – это техника, при которой функционал (диапазон
возможных входных значений) разделяется на группы значений эквивалентных по воздействию
на систему.
Рассмотрим пример разделения на классы эквивалентности. Есть поле с допустимым
диапазоном значений ввода от 1 до 1000. Вводить весь диапазон достаточно долгий процесс. Тем
более, есть еще недопустимые значения (спецсимволы, отрицательные числа, буквы и т.п.), ввод
которых нужно проверить. Как говорилось выше, все значения одного класса эквивалентности
одинаково влияют на систему, т.е. допустимые значения система принимает, а недопустимые –
нет. В поле должен быть запрещен ввод недопустимых значений. Таким образом, можно
выделить два класса эквивалентности:
1. Допустимые значения: числа от 1 до 1000.
2. Недопустимые значения: числа от -∞ до 0, от 1001 до +∞, а также
все остальные буквы и символы.
Класс с недопустимыми значениями можно разбить на несколько:
1. От - ∞ до 0.
2. От 1001 до + ∞.
3. Специальные символы (# @ + — / _ : ; “ ‘ и т.д.).
4. Буквы.
В результате, благодаря классам эквивалентности можно использовать минимум 5 тестов для
тестирования поля ввода. Например, в поле ввести следующие данные: 46, -37, 1773, Имя, $_=#.
Технику разделения на классы эквивалентности применяют для сокращения числа тестов, при
этом сохраняя приемлемое тестовое покрытие.
Шаги применения техники разделения на классы эквивалентности следующие:
1. Определить классы эквивалентности. От правильности выполнения данного шага
зависит эффективность предстоящего тестирования.
2. Выбрать представителя каждого класса.
3. Выполнить тесты.
Давайте рассмотрим еще один пример. На рейсах авиакомпании при оформлении
предварительной оплаты за провоз сверхнормативного багажа ранее, чем за 24 часа до вылета
рейса по расписанию действует скидка в размере 50% от общего тарифа. При оплате за провоз
сверхнормативного багажа во время посадки в самолет действует тариф на 20% выше общего
тарифа. Регистрация на рейс начинается за 3 часа до вылета.
Теперь пройдемся по шагам.
1. Определим классы эквивалентности:

Класс Значения Стоимость сверхнормативного багажа

Класс 1 время > 24 50% скидка

Класс 2 24 >= время > 3 обычный тариф

 Класс 3 3 >= время > 0 +20%

2. Выберем представителя от каждого класса:

1. Время до вылета = 30 часов (тест из 1-го класса).
2. Время до вылета = 10 часов (тест из 2-го класса).
3. Время до вылета = 2 часа (тест из 3-го класса).

3. Выполним тесты.
1. Внесем предварительную оплату за 30 часов до вылета рейса по расписанию. Проверим,
что в тариф включена скидка 50%.
2. Внесем предварительную оплату за 10 часов до вылета рейса по расписанию. Проверим,
что тариф – общий.
3. Внесем предварительную оплату за 2 часа до вылета рейса по расписанию. Проверим,
что тариф увеличен на 20%.

Техника разделения на классы эквивалентности имеет свои плюсы и минусы:

1. К достоинствам можно отнести возможность структурировать процесс тестирования и,
следовательно, сократить время на выполнение тестирования.
2. К недостаткам можно отнести пропуск багов при неправильном использовании техники.
Анализ граничных значений – это проверка поведения системы на граничных значениях
входных данных (границах классов эквивалентности).
Очень важно проверять именно граничные значения, потому что довольно часто возникают
ошибки именно на границах классов эквивалентности. На каждой границе диапазона нужно
проверить 3 значения: граничное значение, значения до и после границы.
Например, для диапазона вводимых значений от 1 до 1000 все значения от 1 до 1000 приведут
к одному и тому же результату, то границы две: нижняя и верхняя. Первое граничное значение –
1. Второе граничное значение – 1000. Добавляем к ним, стоящие рядом значения:

1. 0, 1, 2
2. 999, 1000, 1001

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

 1. Определить классы эквивалентности.
2. Определить граничные значения для каждого класса (важно понимать к какому классу
относится значение).
3. Провести тесты по проверке значения до границы, на границе и сразу после границы.
Теперь выделим граничные значения для примера, описанного выше.
1. Определим классы эквивалентности для примера с авиакомпанией:
1. Время > 24 (за 24 часа до вылета рейса по расписанию действует скидка в размере 50%).
2. 24 >= время > 3 (регистрация на рейс начинается за 3 часа до вылета).
3. 3 >= время > 0.
2. Определим граничные значения:
1. 24 часа (относится ко второму классу).
2. 3 часа (относится к третьему классу).
3. Протестируем значения на границах, до и после них.
Для этого внесем предварительную плату:
● За 24 часа + 1 минута. Проверим, что скидка составляет 50%.
● Ровно за 24 часа. Проверим, что тариф – общий.
● За 23 часа 59 минут. Проверим, что тариф – общий.
● За 3 часа + 1 минута. Проверим, что тариф – общий.
● Ровно за 3 часа. Проверим, что тариф увеличен на 20%.
● За 2 часа 59 минут. Проверим, что тариф увеличен на 20%.
Из этого следует, что для проверки граничных значений достаточно выполнить 6 тестов.
Использование техник разделения на классы эквивалентности и анализа граничных значений
позволяют снизить риск пропуска ошибки, качественно улучшить результаты тестирования, а
также значительно сократить количество тестов, необходимых для проведения, и,
следовательно, сэкономить время. Но не стоит также забывать, что важна правильность
использования той или иной техники для достижения качественного результата.

5.5. Попарное тестирование (Pairwise testing)

Pairwise testing (попарное тестирование) – это техника формирования наборов тестовых
данных из полного набора входных данных в системе, которая позволяет существенно сократить
количество тест-кейсов.
Сформулировать суть попарного тестирования можно следующим образом: формирование
таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых
параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных
проверяемых параметров.
Главные цели Pairwise Testing:
● убрать избыточные проверки;
● обеспечить хорошее тестовое покрытие;
● выявить наибольшее количество багов на минимальном наборе тестов.
Pairwise testing эффективен лишь на поздних этапах разработки, на стабильном функционале,
когда текущие тесты уже теряют свою эффективность, либо дополненный основными
функциональными тестами.
Рассмотрим более детально суть попарного тестирования на примерах.
Пример 1
Представим, что у нас есть параметры A, B и C принимающие значения Yes или No.
Максимальное количество комбинаций значений этих параметров – 8. Но при использовании
попарного тестирования достаточно четырех комбинаций, так как учитываются все возможные
пары параметров (пара A и B, пара B и C, пара A и C):

Пример 2
Допустим, какое-то значение (например, налог) для человека рассчитывается на основании его
пола, возраста и наличия детей – получаем три входных параметра, для каждого из которых для
тестов выбираем любое из возможных значений. Например: пол – мужской или женский; возраст
– до 25, от 25 до 60, более 60; наличие детей – да или нет. Для проверки правильности расчетов
можно, конечно, перебрать все комбинации значений всех параметров:

№ Пол Возраст Дети

1 мужчина до 25 детей нет

2 женщина до 25 детей нет

3 мужчина 25-60 детей нет

4 женщина 25-60 детей нет

5 мужчина старше 60 детей нет

6 женщина старше 60 детей нет

7 мужчина до 25 дети есть

8 женщина до 25 дети есть

9 мужчина 25-60 дети есть

 10 женщина 25-60 дети есть

11 мужчина старше 60 дети есть

12 женщина старше 60 дети есть

А можно решить, что не нужно проверять сочетания значений всех параметров со всеми, а
только убедиться, что проверятся все уникальные пары значений параметров. Например, с точки
зрения параметров пола и возраста нужно убедиться, что точно проверим мужчину до 25,
мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60,
также женщину после 60. И точно так же для всех остальных пар параметров. И таким образом,
можем получить гораздо меньше наборов значений (в них есть все пары значений, правда
некоторые дважды):

№ Пол Возраст Дети

1 мужчина до 25 детей нет

2 женщина до 25 дети есть

3 мужчина 25-60 дети есть

4 женщина 25-60 детей нет

5 мужчина старше 60 детей нет

6 женщина старше 60 дети есть

Пример 3
Есть два браузера Opera и Firefox. Есть две операционные системы Windows и Linux. Тут ничего
не уменьшить, так как из них можно сложить 4 конфигурации:

№ Browser OS

1 Opera Windows

2 Firefox Linux

3 Opera Linux

4 Firefox Windows
Допустим, сайт на двух языках: русский (RU) и английский (EN). Для полного эксперимента,
умножим те 4 конфигурации на 2, т.е. каждую из предыдущих конфигураций проверить с
обоими языками. Но зачем? Вместо этого воспользуемся попарным подходом и вместо 8
конфигураций получим опять 4:

№ Browser OS Language

1 Opera Windows RU

2 Firefox Linux RU

3 Opera Linux EN

4 Firefox Windows EN

Далее, сайт может использовать MySQL, Oracle и MSSQL как базу данных. Просто используя
попарное тестирование получаем 7 конфигураций (а не 12 – предыдущие 4х3, и тем более не
24=2х2х2х3). Но тут опять стоит задуматься, а важно ли проверять каждую базу в сочетании с
другими параметрами. Очевидно – нет. Важно посмотреть, например, как каждая база работает с
каждым языком. Таким образом, введя ограничения, вместо 7 получим 6 конфигураций (3 базы х
2 языка):

№ Browser OS Language Database

1 Opera Windows RU MySQL

2 Firefox Linux EN MySQL

3 Opera Linux EN MSSQL

4 Firefox Windows RU MSSQL

5 Opera Linux RU Oracle

6 Firefox Windows EN Oracle

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

Parameter Value 1 Value 2 Value 3 Value 4

Font TT Arial

Style Regular Italic Bold Bold Italic

Size min normal max

Color black white red

 Underline style none words only other

Strikethrough on off

Double Strikethrough on off

Superscript on off

Subscript on off

Shadow on off

Outline on off

Emboss on off

Engrave on off

Small caps on off

All caps on off

Hidden on off

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

параметра, то получим следующее количество вариантов проверок:
2 * 4 * 3 * 3 * 3 * 2^11 = 442 368.
Итоговая таблица проверок:
Таким образом, метод «Всех пар» позволяет существенно сократить количество проверок.
Составление нужных комбинаций данных – задача часто не самая простая, но, к счастью, для
ее решения существует множество инструментов, разного уровня качества, например, PICT
(Pairwise Independent Combinatorial Testing – инструмент для попарного тестирования от
Microsoft).
PICT позволяет генерировать компактный набор значений тестовых параметров, который
представляет собой все тестовые сценарии для всестороннего комбинаторного покрытия
параметров.

6. Управление тест- кейсами и тестовыми сценариями

6.1. Особенности регрессионного тестирования.
Регрессионное тестирование – это набор тестов, направленных на обнаружение дефектов в
уже протестированных участках программного обеспечения. Делается это совсем не для того,
чтобы окончательно убедиться в отсутствии багов, а для поиска и исправления регрессионных
ошибок.
Регрессионные ошибки – те же баги, но появляются они не при написании программы, а при
добавлении в существующий билд нового участка программы или исправлении других багов,
что и стало причиной возникновения новых дефектов в уже протестированном продукте.
Таким образом, мы можем сказать, что цель регрессионного тестирования – убедиться, что
исправление одних багов не стало причиной возникновения других и что обновление билда не
создало новых дефектов в уже проверенном коде.
 Есть несколько видов регрессионных тестов:
• Верификационные тесты - проводятся для проверки исправления обнаруженного и открытого
ранее бага.
• Тестирование верификации версии - содержит принципы дымового тестирования и
тестирование сборки: проверка работоспособности основной функциональности программы в
каждой новой сборке.
• Непосредственно само регрессионное тестирование – повторное выполнение всех тестов,
которые были написаны и проведены ранее. Они выполняются по уже существующим тест-
кейсам независимо от того, были в ходе их прохождения найдены баги, или нет.
• Тестирование в новом билде уже исправленных багов в старых билдах. Это выполняется для
того, чтобы проверить, не возобновило ли обновление билда старых дефектов.
Некоторые положения относительно того, как проводить регрессионное тестирование:
• Данный вид тестирования проводится в каждом новом билде.
• Начинать нужно с верификации версии (тестирование сборки и дымное тестирование).
• Проверка исправленных багов.
• Регрессионное тестирование, в основном, не покрывает все приложение, а только те участки,
которые тем или иным способом «соприкасаются» с изменениями в билде.
Далее тестируются уже закрытые ранее баги.
1) Регрессионное тестирование рекомендуется проводить несколько раз (3-5). Поэтому, с целью
экономии времени (и, может быть, для избавления от «рутинности») в регрессионных тестах
активно используют мощь автоматизации тестирования.
2) Проведение финального регрессионного тестирования, для которого отбираются тесты по
приоритету, определяемому наибольшим количеством найденных ошибок.

6.2. Инструментальные средства управления тест кейсами

Инструментальных средств управления тестированием (test management tool) очень много, к
тому же многие компании разрабатывают свои внутренние средства решения этой задачи. Не
имеет смысла заучивать, как работать с тест-кейсами в том или ином инструментальном
средстве — принцип везде един, и соответствующие навыки нарабатываются буквально за пару
дней. Что на текущий момент важно понимать, так это общий набор функций, реализуемых
такими инструментальными средствами (конечно, то или иное средство может не реализовывать
какую-то функцию из этого списка и/или реализовывать не вошедшие в список функции):
- создание тест-кейсов и наборов тест-кейсов;
- контроль версий документов с возможностью определить, кто внёс те или иные
изменения, и отменить эти изменения, если требуется;
- формирование и отслеживание реализации плана тестирования, сбор и визуализация
разнообразных метрик, генерирование отчётов;
- интеграция с системами управления дефектами, фиксация взаимосвязи между
выполнением тест-кейсов и созданными отчётами о дефектах;
- интеграция с системами управления проектами;
- интеграция с инструментами автоматизированного тестирования, управление
выполнением автоматизированных тест-кейсов.
Иными словами, хорошее инструментальное средство управления тестированием берёт на
себя все рутинные технические операции, которые объективно необходимо выполнять в
процессе реализации жизненного цикла тестирования. Огромным преимуществом также
является способность таких инструментальных средств отслеживать взаимосвязи между
различными документами и иными артефактами, взаимосвязи между артефактами и процессами
и т.д., подчиняя эту логику системе разграничения прав доступа и гарантируя сохранность и
корректность информации.
Для общего развития и лучшего закрепления темы об оформлении тест-кейсов мы сейчас
рассмотрим несколько картинок с формами из разных инструментальных средств. Здесь вполне
сознательно не приведено никакого сравнения или подробного описания — подобных обзоров
достаточно в Интернете, и они стремительно устаревают по мере выхода новых версий
обозреваемых продуктов. Но интерес представляют отдельные особенности интерфейса, на
которые мы обратим внимание в каждом из примеров (важно: если вас интересует подробное
описание каждого поля, связанных с ним процессов и т.д., обратитесь к официальной
документации — здесь будут лишь самые краткие пояснения).
 QAComplete

1. Id (идентификатор), как видно из соответствующей надписи, автогенерируемый.

2. Title (заглавие), как и в большинстве систем, является обязательным для заполнения.
3. Priority (приоритет) по умолчанию предлагает значения high (высокий), medium (средний), low
(низкий).
4. Folder name (расположение) является аналогом полей «Модуль» и «Подмодуль» и позволяет
выбрать из выпадающего древовидного списка соответствующее значение, описывающее, к
чему относится тест-кейс.
5. Status (статус) показывает текущее состояние тест-кейса: new (новый), approved (утверждён),
awaiting approval (на рассмотрении), in design (в разработке), outdated (устарел), rejected
(отклонён).
6. Assigned to (исполнитель) указывает, кто в данный момент является «основной рабочей
силой» по данному тест-кейсу (или кто должен принять решение о, например, утверждении тест-
кейса). 7. Last Run Status (результат последнего запуска) показывает, прошёл ли тест успешно
(passed) или завершился неудачей (failed).
8. Last Run Configuration (конфигурация, использованная для последнего запуска) показывает, на
какой аппаратно-программной платформе тест-кейс выполнялся в последний раз.
9. Avg Run Time (среднее время выполнения) содержит вычисленное автоматически среднее
время, необходимое на выполнение тест-кейса.
10. Last Run Test Set (в последний раз выполнялся в наборе) содержит информацию о наборе
тест-кейсов, в рамках которого тест-кейс выполнялся последний раз.
11. Last Run Release (последний раз выполнялся на выпуске) содержит информацию о выпуске
(билде) программного средства, на котором тест-кейс выполнялся последний раз.
12. Description (описание) позволяет добавить любую полезную информацию о тест-кейсе
(включая особенности выполнения, приготовления и т.д.).
13. Owner (владелец) указывает на владельца тест-кейса (как правило — его автора).
14. Execution Type (способ выполнения) по умолчанию предлагает только значение manual
(ручное выполнение), но при соответствующих настройках и интеграции с другими продуктами
список можно расширить (как минимум добавить automated (автоматизированное выполнение)).
15. Version (версия) содержит номер текущей версии тест-кейса (фактически — счётчик того,
сколько раз тест-кейс редактировали). Вся история изменений сохраняется, предоставляя
возможность вернуться к любой из предыдущих версий.
16. Test Type (вид теста) по умолчанию предлагает такие варианты, как negative (негативный),
positive (позитивный), regression (регрессионный), smoke-test (дымный).
17. Default host name (имя хоста по умолчанию) в основном используется в автоматизированных
тест-кейсах и предлагает выбрать из списка имя зарегистрированного компьютера, на котором
установлен специальный клиент.
18. Linked Items (связанные объекты) представляют собой ссылки на требования, отчёты о
дефектах и т.д.
19. File Attachments (вложения) могут содержать тестовые данные, поясняющие изображения,
видеоролики и т.д.
Для описания шагов исполнения и ожидаемых результатов после сохранения общего описания
тест-кейса становится доступным дополнительный интерфейс:

При необходимости можно добавить и настроить свои дополнительные поля, значительно

расширяющие исходные возможности системы.

TestLink
1. Title (заглавие) здесь тоже является обязательным для заполнения.
2. Summary (описание) позволяет добавить любую полезную информацию о тест-кейсе (включая
особенности выполнения, приготовления и т.д.).
3. Steps (шаги выполнения) позволяет описать шаги выполнения.
4. Expected Results (ожидаемые результаты) позволяет описать ожидаемые результаты,
относящиеся к шагам выполнения.
5. Available Keywords (доступные ключевые слова) содержит список ключевых слов, которые
можно проассоциировать с тест-кейсом для упрощения классификации и поиска тест-кейсов.
Это ещё одна вариация идеи «Модулей» и «Подмодулей» (в некоторых системах реализованы
оба механизма).
6. Assigned Keywords (назначенные ключевые слова) содержит список ключевых слов,
проассоциированных с тест-кейсом.
Как видите, инструментальные средства управления тест-кейсами могут быть и достаточно
минималистичными.

TestRail
1. Title (заглавие) здесь тоже является обязательным для заполнения.
2. Section (секция) — очередная вариация на тему «Модуль» и «Подмодуль», позволяющая
создавать иерархию секций, в которых можно размещать тест-кейсы.
3. Type (тип) здесь по умолчанию предлагает выбрать один из вариантов: automated
(автоматизированный), functionality (проверка функциональности), performance
(производительность), regression (регрессионный), usability (удобство использования), other
(прочее).
4. Priority (приоритет) здесь представлен числами, по которым распределены следующие
словесные описания: must test (обязательно выполнять), test if time (выполнять, если будет
время), don’t test (не выполнять).
5. Estimate (оценка) содержит оценку времени, которое необходимо затратить на выполнение
тест-кейса.
6. Milestone (ключевая точка) позволяет указать ключевую точку проекта, к которой данный
тест-кейс должен устойчиво показывать положительный результат (выполняться успешно).
7. References (ссылки) позволяет хранить ссылки на такие артефакты, как требования,
пользовательские истории, отчёты о дефектах и иные документы (требует дополнительной
настройки).
8. Preconditions (приготовления) представляет собой классику описания предварительных
условий и необходимых приготовлений к выполнению тесткейса.
9. Step Description (описание шага) позволяет добавлять описание отдельного шага тест-кейса.
10. Expected Results (ожидаемые результаты) позволяет описать ожидаемый результат по
каждому шагу.