тестовые сценарии

articles/5_3_1_4_testcase.md

@@ -16,29 +16,15 @@
 
 Теперь рассмотрим самый главный для нас термин — «тест-кейс».
 
-**Тест-кейс** — набор входных данных, условий выполнения и ожидаемых
-результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.
+**Тест-кейс** — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.
 
-Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.
+Под **тест-кейсом** также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.
 
-Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и
-вовсе невозможно выполнить).
+Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и вовсе невозможно выполнить).
 
 >Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.
 
-**Высокоуровневый тест-кейс** — тест-кейс без конкретных входных дан-
-ных и ожидаемых результатов.
-
-Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
-
-**Низкоуровневый тест-кейс** — тест-кейс с конкретными входными дан-
-ными и ожидаемыми результатами.
-
-Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой
-информацией можно пренебречь, при этом не снизив ценность тест-кейса.
-
-**Спецификация тест-кейса** — документ, описывающий набор
-тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
+**Спецификация тест-кейса** — документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
 
 **Спецификация теста** — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.
 
@@ -49,8 +35,9 @@
 Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов).
 
 Наличие же тест-кейсов позволяет:
+
 * Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
-* Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
+* Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
 * Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
 * Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
 * Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
@@ -67,12 +54,12 @@
 * Создан — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
 * Запланирован — в этом состоянии тест-кейс находится, когда он
 или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения.
-* Не выполнен — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
+* **Не выполнен** — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
 * Выполняется — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
-* Пропущен — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
-* Провален — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
-* Пройден успешно — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
-* Заблокирован — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
+* **Пропущен** — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
+* **Провален** — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
+* **Пройден успешно** — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
+* **Заблокирован** — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
 * Закрыт — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
 * Требует доработки — как видно из схемы, в это состояние (и из него) тест-кейс может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
 
@@ -80,7 +67,7 @@
 
 ## Атрибуты (поля) тест-кейса.
 
-Как уже было сказано выше, термин «тест-кейс» может относиться к формальной записи тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компоненты которой называются атрибутами (полями) тест-кейса.
+Как уже было сказано выше, термин «тест-кейс» может относиться к формальной записи тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компоненты которой называются атрибутами (полями) тест-кейса. На демо-экзамене обычно в ресурсах есть файл со структурой тест-кейса, например [`testing-template.docx`](../docs/testing-template.docx)
 
 В зависимости от инструмента управления тест-кейсами внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
 
@@ -91,12 +78,12 @@
 Теперь рассмотрим каждый атрибут подробно.
 
 **Идентификатор** представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если
-позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например:
-UR216_S12_DB_Neg).
+позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например: `UR216_S12_DB_Neg`).
 
-**Приоритет** показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.
+**Приоритет** показывает важность тест-кейса. Он может быть выражен буквами (`A`, `B`, `C`, `D`, `E`), цифрами (`1`, `2`, `3`, `4`, `5`), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.
 
 Приоритет тест-кейса может коррелировать с:
+
 * важностью требования, пользовательского сценария или функции, с которыми связан тест-кейс;
 * потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
 * степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функцией.
@@ -107,18 +94,18 @@ UR216_S12_DB_Neg).
 как прослеживаемость.
 
 Частые вопросы, связанные с заполнением этого поля, таковы:
+
 * Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.
-* Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.
+* Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять `R56.1`, `R56.2`, `R56.3` и т.д., можно просто написать `R56`). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.
 
-**Модуль и подмодуль приложения** указывают на части приложения,
-к которым относится тест-кейс, и позволяют лучше понять его цель.
+**Модуль и подмодуль приложения** указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель.
 Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разде-
-ляется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули).
-И вот уже для таких небольших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится намного проще.
+ляется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). И вот уже для таких небольших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится намного проще.
 
 Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения.
 
 Теперь — самое сложное: как выбираются модули и подмодули. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
+
 * Механизм запуска:
     * механизм анализа параметров;
     * механизм сборки приложения;
@@ -127,27 +114,33 @@ UR216_S12_DB_Neg).
 * Механизм взаимодействия с файловой системой:
     * механизм обхода дерева SOURCE_DIR;
     * механизм обработки ошибочных ситуаций.
+
 * Механизм преобразования файлов:
     * механизм определения кодировок;
     * механизм преобразования кодировок;
     * механизм обработки ошибочных ситуаций.
+
 * Механизм ведения журнала:
     * механизм записи журнала;
     * механизм отображения журнала в консоли;
     * механизм обработки ошибочных ситуаций.    
 
 Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:
+
 * Стартер:
     * анализатор параметров;
     * сборщик приложения;
     * обработчик ошибок.
+
 * Сканер:
     * обходчик;
     * обработчик ошибок.
+
 * Преобразователь:
     * детектор;
     * конвертер;
     * обработчик ошибок.
+
 * Регистратор:
     * дисковый регистратор;
     * консольный регистратор;
@@ -156,8 +149,7 @@ UR216_S12_DB_Neg).
 Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на основе графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением
 задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению.    
 
->Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы
-они отглагольными существительными), а не процесс печати или настройки принтера).
+>Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы они отглагольными существительными), а не процесс печати или настройки принтера).
 >
 >Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.
 
@@ -176,27 +168,27 @@ UR216_S12_DB_Neg).
 Закрытие | Остановка закрытием консоли
 
 Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочетаний — главное, чтобы выполнялись следующие условия:
+
 * Информативность.
 * Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).
 
 >Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его **всё равно надо писать**. Тест-кейсы без заглавий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами.
 
-И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую
-ситуацию он проверяет.
+И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую ситуацию он проверяет.
 
 **Исходные данные, необходимые для выполнения тест-кейса**, позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
+
 * Состояние базы данных.
 * Состояние файловой системы и её объектов.
 * Состояние серверов и сетевой инфраструктуры.
 
 То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
-Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,
-если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».
+Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин, если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».
 
->Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,
-чтобы понять, какой точки зрения на данный вопрос они придерживаются.
+>Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами, чтобы понять, какой точки зрения на данный вопрос они придерживаются.
 
 **Шаги тест-кейса** описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы:
+
 * начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
 * даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
 * если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);
@@ -204,13 +196,13 @@ UR216_S12_DB_Neg).
 * ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением...»);
 * пишите шаги последовательно, без условных конструкций вида «если... то...».
 
->Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению
-ошибки, вы не сможете закончить выполнение вашего тест-кейса.
+>Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению ошибки, вы не сможете закончить выполнение вашего тест-кейса.
 
 **Ожидаемые результаты** по каждому шагу тест-кейса описывают реакцию
 приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
 
 По написанию ожидаемых результатов можно порекомендовать следующее:
+
 * описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью...» — хорошо);
 * пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия,
 лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие);
@@ -219,8 +211,7 @@ UR216_S12_DB_Neg).
 
 >Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».
 >
->При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы
-отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.
+>При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.
 
 Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов».
 
@@ -230,8 +221,8 @@ UR216_S12_DB_Neg).
 
 Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нарушено одно из следующих свойств.
 
-**Правильный технический язык, точность и единообразие формулировок**. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до-
-кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:
+**Правильный технический язык, точность и единообразие формулировок**. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:
+
 * пишите лаконично, но понятно;
 * используйте безличную форму глаголов (например, «открыть» вместо «откройте»);
 * обязательно указывайте точные имена и технически верные названия элементов приложения;
@@ -239,7 +230,6 @@ UR216_S12_DB_Neg).
 * везде называйте одни и те же вещи одинаково (например, нельзя в одном тест-кейсе некий режим работы приложения назвать «графическое представление», а в другом тот же режим — «визуальное отображение», т.к. многие люди могут подумать, что речь идёт о разных вещах);
 * следуйте принятому на проекте стандарту оформления и написания тест-кейсов (иногда такие стандарты могут быть весьма жёсткими: вплоть до регламентации того, названия каких элементов должны быть приведены в двойных кавычках, а каких — в одинарных).
 
-
 **Баланс между специфичностью и общностью**. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т. е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики.
 
 Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):
@@ -257,11 +247,13 @@ UR216_S12_DB_Neg).
 Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.
 
 Почему плоха излишняя специфичность (тест-кейс 1):
+
 * при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же действия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки;
 * возрастает время написания, доработки и даже просто прочтения тест-кейса;
 * в случае выполнения тривиальных действий опытные специалисты тратят дополнительные мыслительные ресурсы в попытках понять, что же они упустили из виду, т. к. они привыкли, что так описываются только самые сложные и неочевидные ситуации.
 
 Почему плоха излишняя общность (тест-кейс 2):
+
 * тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными специалистами, лишь недавно подключившимися к проекту;
 * недобросовестные сотрудники склонны халатно относиться к таким тест-кейсам;
 * тестировщик, выполняющий тест-кейс, может понять его иначе, чем было задумано автором (и в итоге будет выполнен фактически совсем другой тест-кейс).
@@ -276,22 +268,21 @@ UR216_S12_DB_Neg).
 ---|---
 **Конвертация из всех поддерживаемых кодировок**<br/>Приготовления:<br/>- Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов.<br/>- Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов.<br/>1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное).<br/>2. Скопировать файлы из папки для временного хранения в папку для входных файлов.<br/>3. Остановить приложение.| 1. Приложение запускается и выводит сообщение о своём запуске в консоль и файл журнала.<br/>2. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки.<br/>3. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.
 
-В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что
-при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки.
+В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки.
 
 Ещё раз главная мысль: сами по себе специфичность или общность тест-кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса.
 
-**Баланс между простотой и сложностью.** Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден
-главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных
-действий.
+**Баланс между простотой и сложностью.** Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных действий.
 
 Преимущества простых тест-кейсов:
+
 * их можно быстро прочесть, легко понять и выполнить;
 * они понятны начинающим тестировщикам и новым людям на проекте;
 * они делают наличие ошибки очевидным (как правило, в них предполагается выполнение повседневных тривиальных действий, проблемы с которыми видны невооружённым взглядом и не вызывают дискуссий);
 * они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.
 
 Преимущества сложных тест-кейсов:
+
 * при взаимодействии многих объектов повышается вероятность возникновения ошибки;
 * пользователи, как правило, используют сложные сценарии, а потому сложные тесты более полноценно эмулируют работу пользователей;
 * программисты редко проверяют такие сложные случаи (и они совершенно не обязаны это делать).
@@ -300,7 +291,7 @@ UR216_S12_DB_Neg).
 
 [//TODO дописать - тема нужная]: _
 
-# Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями
+## Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями
 
 >Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.
 >
@@ -316,7 +307,7 @@ UR216_S12_DB_Neg).
 Рабочая версия | Версия проекта/программного обеспечения (первый тест считается 1.0).
 Имя тестирующего | Имя того, кто проводил тесты
 Дата(ы) теста | Дата(ы) проведения тестов – это один или несколько дней. Если тесты проводились в более протяженный период времени, нужно отметить отдельную дату для каждого теста. 
-Тестовый пример # | Уникальный ID для каждого тестового примера.  Следуйте некоторым конвенциям, чтобы указать типы тестов. Например,‘TC_UI_1′ означает‘user interface test case #1′ ( ТС_ПИ_1: тестовый случай пользовательского интерфейса#1)
+Тестовый пример # | Уникальный ID для каждого тестового примера.  Следуйте некоторым конвенциям, чтобы указать типы тестов. Например, `TC_UI_1` означает `user interface test case #1`
 Приоритет тестирования *(Низкий/Средний/Высокий)* | Насколько важен каждый тест. Приоритет тестирования для бизнес-правил и функциональных тестовых случаев может быть средним или высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет. 
 Заголовок/название теста | Название тестового случая. Например, Подтвердите страницу авторизации с действительным именем пользователя и паролем.  
 Краткое изложение теста | Описание того, что должен достичь тест. 
@@ -342,11 +333,11 @@ UR216_S12_DB_Neg).
 
 &nbsp;|&nbsp;| Мои комментарии
 ---|---|---
-Тестовый пример # | TC_DP_1 | расшифровывается: TestCase_DeleteProduct_x
+Тестовый пример # | `TC_DP_1` | расшифровывается: TestCase_DeleteProduct_N
 Приоритет тестирования | средний | бизнес-правило
-Заголовок/название теста | Удаление товара без продаж и дополнительных товаров |
-Краткое изложение теста | Товар должен без ошибок удалиться из таблицы товаров |
-Этапы теста | 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу **Products**<br/>3. Вызвать метод удаления товара<br/>4. Проверить наличие удаленной записи в таблице |
+Заголовок/название теста | Удаление товара без продаж и дополнительных товаров | &nbsp;
+Краткое изложение теста | Товар должен без ошибок удалиться из таблицы товаров | &nbsp;
+Этапы теста | 1. Очистить таблицы: _продаж_, _дополнительных товаров_, _дополнительных картинок и товаров_. <br/>2. Добавить тестовый товар в таблицу **Products**<br/>3. Вызвать метод удаления товара<br/>4. Проверить наличие удаленной записи в таблице |
 Тестовые данные | Название: *Моторное масло Motor Oil KE900-90042-R*<br/>Изображение: *Товары автосервиса\8FE07916.jpg*<br/>Производитель: *Nissan*<br/>Активен: *да*<br/>Цена: *2060* | Тут нужно вставить содержимое любой записи из *products_a_import*
 Ожидаемый результат | Запись должна быть удалена из таблицы без ошибок и исключений |
 Фактический результат | Запись удалена | 
@@ -355,14 +346,13 @@ UR216_S12_DB_Neg).
 Постусловие | Таблица товаров должна быть пустой |
 Примечания/комментарии | Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы | 
 
-
 ## Что еще можно проверить
 
 * **№2** - удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.
 
-* **№3** - удаление товара с дополнительными картинками. Аналогично №2.
+* **№3** - удаление товара с дополнительными картинками. Аналогично **№2**.
 
-* **№4** - удаление товара с продажами. Вариант без предварительной проверки - база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.
+* **№4** - удаление товара с продажами. Вариант без предварительной проверки (негативное тестирование) - база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.
 
 * **№5** - удаление товара с продажами. Вариант с предварительной проверкой - в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.