ALMELN.ru

Хранилище текстов, отзывов и закладок о тестировании, обеспечении качества и литературе

View the Project on GitHub

Тест-кейс: понятие, атрибуты и правила составления

В учебных программах по дисциплине “Обеспечение качества и тестирование программ” предусмотрены следующие темы для изучения:

В программе обучения базового уровня International Software Testing Qualifications Board “Сертифицированный тестировщик” указаны следующие цели изучения методов проектирования тестов:

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

Содержание

  1. Стандартный глоссарий терминологии по программированию Института инженеров электротехники и электроники
  2. “Информационная технология. Пакеты программ. Требования к качеству и тестирование” ГОСТ №12119-94
  3. «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений»
  4. «Сертифицированный тестировщик. Программа обучения Базового уровня»
  5. Стандартный глоссарий терминов, используемых в тестировании программного обеспечения
  6. «Тестирование программного обеспечения. Базовый курс»

Стандартный глоссарий терминологии по программированию Института инженеров электротехники и электроники

Institute of Electrical and Electronics Engineers Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology:

Test case. (1) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. (2) (IEEE Std 829-1983 153) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

“Информационная технология. Пакеты программ. Требования к качеству и тестирование”

Государственный стандарт Российской Федерации, Международная организация по стандартизации, Международная электротехническая комиссия №12119-94:

Контрольный пример (test case): Документально оформленное руководство для испытателя, которое определяет, как должна или может быть протестирована функция или комбинация функций. Контрольный пример должен содержать информацию, охватывающую следующие вопросы:

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

Канер и Нгуен

Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001. 341-346 страницы:

Кто пользуется тестовой документацией

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

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

Личные заметки

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

Назначение личных заметок может быть следующим.

Заметки для другого члена команды

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

В заметках может быть следующая информация.

Заметки для другого опытного тестировщика

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

Вам придется предоставить следующие сведения.

Заметки для следующего выпуска программы (планируемого, вероятно, через год)

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

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

Итак, вашим последователям будут крайне необходимы следующие материалы.

Сценарий теста для неопытного тестировщика

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

Назначение сценариев и обеспечиваемые ими выгоды могут быть сле­дующими.

К сожалению, здесь же имеется и целый ряд проблем.

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

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

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

То, как организовать сценарий, может существенно повлиять на резуль­таты работы. Инструкции должны быть отделены от описаний, например, “Что сделать” должно быть записано в отдельном столбце, перед “Что вы увидите”. Не менее важен и порядок заданий. Тестировщик не должен пе­рескакивать между классами тестов. Кроме того, у него не должно быть чувства, что он зря теряет время. Прежде чем передать сценарий временному персоналу, предложите его для опробования опытному тестировщику.

Типы тестовых документов

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

Этого документа в стандарте 829 нет. О его назначении и содержании уже рассказывалось в разделе “Сценарий теста для неопытного тестировщика”. Вот из чего он состоит.

«Сертифицированный тестировщик Программа обучения Базового уровня»

International Software Testing Qualifications Board, Boulevard du Souverain 280, Brussels, Belgium

Версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 51-57/101 страница:

4.1 Процесс разработки тестов

Вводная информация

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

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

Установление трассируемости от тестовых условий назад к спецификациям и требованиям позволяет как определить последствия при изменяющихся требованиях, так и установить покрытие требований набором тестов. При анализе тестирования реализуется детализированный подход к тестированию с целью выбора методов проектирования тестов, основываясь, в том числе, на выявленных рисках (см. Главу 5).

Во время проектирования тестов определяются и специфицируются тестовые сценарии и тестовые данные.

Тестовый сценарий состоит из набора входных значений, предусловий выполнения, ожидаемых результатов и постусловий, определяемых для покрытия определенных тестовых условий (или тестового условия) или целей (цели) тестирования. Содержание спецификаций проектирования тестов (включая тестовые условия) и спецификаций тестовых сценариев описывается в стандарте «Документация при тестировании программ» (IEEE STD 829-1998).

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

В идеальных условиях ожидаемые результаты должны быть определены до момента выполнения теста.

Во время реализации теста тестовые сценарии разрабатываются, реализуются, получают приоритеты и формируют спецификацию процедуры тестирования (IEEE STD 829-1998). Процедура тестирования (или ручной сценарий тестирования) описывает последовательность действий для выполнения теста. Если тесты запускаются с использованием инструмента выполнения тестов, последовательность действий описывается автоматизированным тестовым сценарием.

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

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

Рекомендуемая литература для углубления в тему:

  1. “Systematic Software Testing”, Craig, Rick D. and Jaskiel, Stefan P., 2002;
  2. “Complete Guide to Software Testing”, Hetzel, W., 1988;
  3. IEEE Standard for Software Test Documentation, IEEE Std 829, 1998.

4.2 Категории методов проектирования тестов

… Целью метода проектирования тестов является определение тестовых условий и тестовых сценариев. Классическим является разделение методов тестирования на методы черного и белого ящиков. Методы черного ящика (включающие в себя методы разработки тестов на основе спецификаций и на основе опыта) – это способ определить и выбрать тестовые условия или сценарии для компонента или системы (как функциональные, так и не функциональные), на основе анализа базиса тестирования и опыта разработчиков, тестировщиков и пользователей, без отсылки к внутренней структуре компонента или системы…

Общие признаки подходов, основанных на спецификациях:

Общие признаки методов на основе опыта:

Рекомендуемая литература для углубления в тему:

  1. “Software Testing Techniques” (2nd edition), Beizer, B., 1990;
  2. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004.

4.3 Методы,основанные на спецификациях, или методы черного ящика

4.3.1 Эквивалентное разбиение

Рекомендуемая литература для углубления в тему:

  1. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004;
  2. “Art of Software Testing”, Glenford J. Myers, 1979.

4.3.2 Анализ граничных значений

Рекомендуемая литература для углубления в тему:

  1. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004;
  2. “Art of Software Testing”, Glenford J. Myers, 1979.

4.3.3 Тестирование таблицы решений

Рекомендуемая литература для углубления в тему:

  1. “Software Testing Techniques” (2nd edition), Beizer, B., 1990.
  2. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004.

4.3.4 Тестирование таблицы переходов

Рекомендуемая литература для углубления в тему:

  1. “Software Testing Techniques” (2nd edition), Beizer, B., 1990;
  2. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004.

4.3.5 Тестирование по сценариям использования

Рекомендуемая литература для углубления в тему - “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004.

4.5 Методы,основанные на опыте

Предположение об ошибках.

Исследовательское тестирование.

Рекомендуемая литература для углубления в тему - “Lessons Learned in Software Testing”, Kaner, C., Bach, J. and Petticord, B., 2002.

4.6 Выбор методов тестирования

Рекомендуемая литература для углубления в тему:

  1. “Software Testing Techniques” (2nd edition), Beizer, B., 1990
  2. “A Practitioner’s Guide to Software Test Design”, Copeland, L., 2004

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

Версия 2.3 (от 9 июля 2014 года), International Software Testing Qualifications Board, ред. пер. Александр Александров:

Спецификация проектирования теста (test design specification): Документ, описывающий тестовое условие (элементы покрытия) для элемента тестирования, детализованный подход к тестированию, и идентифицирующий соответствующие тестовые сценарии высокого уровня. [IEEE 829] См. также спецификация теста.

Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. [IEEE 829] См. также спецификация теста.

Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования.

Спецификация тестовых сценариев (test case specification): Документ, описывающий комплект тестовых сценариев - цель, входы, тестовые операции, ожидаемые результаты и предусловия выполнения для объекта тестирования. [IEEE 829] См. также спецификация теста.

Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]

Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. См. также тестовый сценарий низкого уровня.

Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. См. также тестовые сценарии высокого уровня.

Трассируемость (traceability): Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. См. горизонтальная трассируемость, вертикальная трассируемость.

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование»

Рекс Блэк, Москва, Лори, 2006. 310/566 страница:

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

«Тестирование программного обеспечения. Базовый курс»

Святослав Куликов, EPAM

Святослав Куликов. Версия книги 1.2.1 от 02.08.2017, EPAM Systems. 114-/295 страницы:

2.4.2. Тест-кейс и его жизненный цикл

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

Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.

Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и вовсе невозможно выполнить).

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

Высокоуровневый тест-кейс (high level test case) — тест-кейс без конкретных входных данных и ожидаемых результатов.

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

Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.

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

Спецификация теста (test specification) — документ, состоящий из спецификации тест-дизайна (test design specification), спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).

Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

Внимание! Из-за особенностей перевода очень часто под термином «тест-сценарий» («тестовый сценарий») имеют в виду набор тест-кейсов.

Цель написания тест-кейсов

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

Жизненный цикл тест-кейса

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

Рисунок 2.4.a, Святослав Куликов, EPAM, Жизненный цикл (набор состояний) тест-кейса

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

2.4.3. Атрибуты (поля) тест-кейса

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

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

Общий вид всей структуры тест-кейса представлен на рисунке 2.4.b.

Рисунок 2.4.b — Общий вид тест-кейса, Святослав Куликов, EPAM

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

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

Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.

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

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

Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость.

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

Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель.

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

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

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

Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:

Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на основе графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению.

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

Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.

Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.

Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов.

Сравните.

Плохо Хорошо
Тест 1 Запуск, одна копия, верные параметры
Тест 2 Запуск одной копии с неверными путями
Тест 78 (улучшенный) Запуск, много копий, без конфликтов
Остановка Остановка по Ctrl+C
Закрытие Остановка закрытием консоли

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

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

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

Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:

То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении. Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин, если не хватило денег и т.д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».

Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами, чтобы понять, какой точки зрения на данный вопрос они придерживаются.

Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы:

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

Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.

По написанию ожидаемых результатов можно порекомендовать следующее:

Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».

При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение “Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места” — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.

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

2.4.5. Свойства качественных тест-кейсов

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

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

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

Тест-кейс 1 “Конвертация из всех поддерживаемых кодировок”:

Приготовления:

Шаги Ожидаемые результаты
1. Запустить приложение, выполнив команду “php converter.php c:/a c:/b c:c/converter.log”. 1. Отображается консольный журнал приложения с сообщением “текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log, в котором появляется запись “текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log”
2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A. 2. Файлы 1.html, 2.txt, 3.md появляются в папке c:/a, затем пропадают оттуда и появляются в папке с:/b. В консольном журнале и файле c:/c/converter.log появляются сообщения (записи) “текущее_время proceccing 1.html (KOI8-R)», «текущее_время processing 2.txt (CP-1251)», «текущее_время processing 3.md (CP-866)».
3. Остановить приложение нажатием Ctrl+C. 3. В файле C:/C/converter.log появляется запись «текущее_время closed». Приложение завершает работу.

Тест-кейс 2 “Конвертация из всех поддерживаемых кодировок”:

Шаги Ожидаемые результаты
1. Выполнить конвертацию трех файлов допустимого размера в трех разных кодировках всех трех допустимых форматов. 1. Файлы перемеющаются в папку-приемник, кодировка всех файлов меняется на UTF-8.

Если вернуться к вопросу “какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему”, то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.

Почему плоха излишняя специфичность (тест-кейс 1):

Почему плоха излишняя общность (тест-кейс 2):

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

Тест-кейс 3 “Конвертация из всех поддерживаемых кодировок”:

Приготовления:

Шаги  
1) Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). Приложение запускается и выводит сообщение о своем запуске в консоль и файл журнала.
2) Скопировать файлы из папки для времен-ного хранения в папку для входных файлов. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки.
3) Остановить приложение. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.

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

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

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

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

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

Рассмотрим примеры.

Слишком простой тест-кейс “Запуск приложения”:

Шаги Ожидаемые результаты
1) Запустить приложение. 1) Приложение запускается.

Слишком сложный тест-кейс “Повторная конвертация”:

Приготовления:

Шаги Ожидаемые результаты
1) Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала - произвольное). 1) …
2) Скопировать в папку для входных файлов несколько файлов допустимого формата. 2) Файлы постепенно перемещаются из входной в выходнную папку, в консоли и файле журнала появляются сообщения об успешной конвертации файлов.
3) Переместить сконвертированные файлы из папки с результирующими файлами в папку для входных файлов. 3) Файлы постепенно перемещаются из входной в выходнную папку, в консоли и файле журнала появляются сообщения об успешной конвертации файлов.
4) Переместить сконвертированные файлы из папки с результирующими файлами в папку для входных файлов. 4) …
5) Переместить все файлы из папки с набором файлов для теста в папку для входных файлов. Файлы постепенно перемещаются из входной в выходнную папку, в консоли и файле журнала появляются сообщения об успешной конвертации файлов допустимого формата и сообщения об игнорировании файлов недопустимого формата.
6) Переместить конвертированные файлы из папки с результирующими файлами в папку для входных файлов. 6) Файлы постепенно перемещаются из входной в выходнную папку, в консоли и файле журнала появляются сообщения об успешной конвертации файлов допустимого формата и сообщения об игнорировании файлов недопустимого формата.

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

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

Пример хорошего сложного тест-кейса может выглядеть так. “Много копий приложения, конфликт файловых операций”. Приготовления:

  1. Создать в корне любого диска три отдельные папки для входных файлов, выходных файлов, файла журнала.
  2. Подготовить набор из нескольких файлов максимального поддерживаемого размера поддерживаемых форматов с поддерживаемыми кодировками.
Шаги Ожидаемые результаты
1) Запустить первую копию приложения, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). -
2) Запустить вторую копию приложения с теми же параметрами (см. шаг 1). -
3) Запустить третью копию приложения с теми же параметрами (см. шаг 1). 3) Все три копии приложения запускаются, в файле журнала появляются последовательно три записи о запуске приложения.
4) Изменить приоритет процессов второй (“high”) и третьей (“low”) копий. -
5) Скопировать подготовленный набор исходных файлов в папку для входных файлов. Файлы постепенно перемещаются из входной в выходную папку, в консоли и файле журнала появляются сообщения об успешной конвертации файлов, а также (возможно) сообщения вида:
a. “source file inaccessible, retrying”.
b. “destination file inaccessible, retrying”.
c. “log file inaccessible, retrying”.

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

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

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

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

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

Пример непоказательного (плохого) тест-кейса “Запуск и остановка приложения”:

Шаги Ожидаемые результаты
1) Запустить приложение с корректными пара-метрами. 1) Приложение запускается.
2) Завершить работу приложения. 2) Приложение завершает работу.

Пример показательного (хорошего) тест-кейса “Запуск с некорректными параметрами, несуществующие пути”:

Шаги Ожидаемые результаты
1) Запустить приложение со всеми тремя параметрами (SOURCE_DIR, DESTINA-TION_DIR, LOG_FILE_NAME), значения которых указывают на несуществующие в файловой системе пути (например: z:\src\, z:\dst\, z:\log.txt при условии, что в системе нет логического диска z). 1) В консоли отображаются нижеуказанные сообщения, приложение завершает работу. Сообщения:
a. SOURCE_DIR: directory not exists or inaccessible.
b. DESINATION_DIR: directory not exists or inaccessible.
c. LOG_FILE_NAME: wrong file name or inaccessible path.

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

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

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

Приготовления:

Шаги Ожидаемые результаты
1) Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). 1) Приложение запускается и выводит сообщение о своем запуске в консоль и файл журнала.
2) Скопировать файлы из папки для времен-ного хранения в папку для входных файлов. 2) Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждного из файлов с указанием его исходной кодировки.
3) Остановить приложение. 3) Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.
4) Удалить файл журнала. -
5) Повторно запустить приложение с теми же параметрами. 5) Приложение запускается и выводит сообщение о своем запуске в консоль и заново созданный файл журнала.
6) Остановить приложение. 6) Приложение выводит сообщение о заврешении работы в файл журнала и завершает работу.

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

Плохо Хорошо
1) Указать в качестве первого параметра приложения путь к папке с исходными файлами. 1) Запустить приложение со всеми тремя корректными параметрами (например, c:\src\, c:\dist\, c:\log.txt при условии, что соответствующие папки существуют и доступны приложению).
2) Указать в качестве второго параметра приложения путь к папке с конечными файлами. -
3) Указать в качестве третьего параметра приложения путь к файлу журнала. -
4) Запустить приложение. -

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

Следующий пример тест-кейса не относится к нашему «Конвертеру файлов», но очень хорошо иллюстрирует эту мысль:

Плохо Хорошо
1) Запустить приложение. 1) Открыть DOCX-файл с тремя и более страницами.
2) Выбрать в меню пункт «Файл». -
3) Выбрать подпункт «Открыть». -
4) Перейти в папку, в которой находится хотя бы один файл формата DOCX с тремя и более страницами. -

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

Проблема с подготовительными (и финальными) действиями идеально решена в автоматизированном модульном тестировании с использованием фреймворков наподобие JUnit или TestNG — там существует специальный «механизм фиксаций» (fixture), автоматически выполняющий указанные действия перед каждым отдельным тестовым методом (или их совокупности) или после него.

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

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

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

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

Шаги Ожидаемые результаты
1) Разместить в файле текст «Пример длинного текста, содержащего символы русского и английского алфавита вперемешку» в кодировке KOI8-R (в слове «Пример» буквы «р» — английские). -
2) Сохранить файл под именем «test. txt» и отправить файл на конвертацию. 2) Приложение игнорирует файл.
3) Переименовать файл в “test.txt”. 3) Текст принимает корректный вид в кодировке UTF-8 с учетом английских букв.

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

Шаги Ожидаемые результаты
1) Разместить в файле текст «Ё╥╔═┼╥ ╘┼╦╙╘┴.» (Эти символы представляют со-бой словосочетание «Пример текста.» в коди-ровке KOI8-R, прочитанной как CP866). -
2) отправить файл на конвертацию. 2) Текст принимает вид: “Пример текста” (кодировка UTF8)

В первом случае тест-кейс плох не только расплывчатостью формулировки «корректный вид в кодировке UTF-8 с учётом английских букв», там также очень легко допустить ошибки при выполнении:

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

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

Пример непрослеживаемого тест-кейса “Совмещение кодировок”:

Приготовления: файл с несколькими допустимыми и недопустимыми кодировками.

Требование Модуль Подмодуль Шаги Ожидаемые результаты
ПТ-4 Приложение - 1) Передать файл на конвертацию. 1) Допустимые кодировки конвертируются верно, недопустимые остаются без изменений.

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

Пример прослеживаемого тест-кейса “Запуск с некорректными параметрами, несуществуие пути”:

Требование Модуль Подмодуль Шаги Ожидаемые результаты
ДС-2.4, ДС-3.2 Стартер Обработчик ошибок 1) Запустить приложение со всеми тремя параметрами, значения которых указывают на несуществующие в файловой системе пути. 1) В консоли отображаются нежеуказанные сообщения, приложение завершает работу. Сообщения:
a. SOURCE_DIR: directory not exists or inaccessible.
DESTINATION_DIR: directory not exists or inaccessible.
c. LOG_FILE_NAME: wrong file name or inaccessible path.

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

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

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

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

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

Шаги Ожидаемые результаты
1) Запустить приложение, указав в качестве всех параметров заведомо некорректные значения. 1) Приложение запускается, после чего выводит сообщение с описание сути проблемы с каждым из параметров и заврешает работу.

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

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

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

Ошибки оформления и формулировок

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

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

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

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

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

Ссылка на множество требований. Иногда высокоуровневый тест-кейс действительно затрагивает несколько требований, но в таком случае рекомендуется писать ссылку на максимум 2–3 самых ключевых (наиболее соответствующих цели тест-кейса), а ещё лучше — указывать общий раздел этих требований (т.е. не ссылаться, например, на требования 5.7.1, 5.7.2, 5.7.3, 5.7.7, 5.7.9, 5.7.12, а просто сослаться на раздел 5.7, включающий в себя все перечисленные пункты). В большинстве инструментальных средств управления тест-кейсами это поле представляет собой выпадающий список, и там эта проблема теряет актуальность.

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

Использование прошедшего или будущего времени в ожидаемых результатах. Это не очень серьёзная ошибка, но всё равно «введённое значение отображается в поле» читается лучше, чем «введённое значение отобразилось в поле» или «введённое значение отобразится в поле».

Постоянное использование слов «проверить» (и ему подобных) в чек-листах. В итоге почти каждый пункт чек-листа начинается с «проверить …», «проверить…», «проверить…». Но ведь весь чек-лист — это и есть список проверок! Зачем писать это слово? Сравните:

Плохо Хорошо
Проверить запуск приложения. Запуск приложения.
Проверить открытие корректного файла. Открытие корректного файла.
Проверить модификацию файла. Модификация файла.
Проверить сохранение файла. Сохранение файла.
Проверить закрытие приложения. Закрытие приложения.

Сюда же относится типичное слово «попытаться» в негативных тест-кейсах («попытаться поделить на ноль», «попытаться открыть несуществующий файл», «попытаться ввести недопустимые символы»): «деление на ноль», «открытие несуществующего файла», «ввод спецсимволов» намного короче и информативнее. А реакцию приложения, если она не очевидна, можно указать в скобках (так будет даже информативнее): «деление на ноль» (сообщение «Division by zero detected»), «открытие несуществующего файла» (приводит к автоматическому созданию файла), «ввод спецсимволов» (символы не вводятся, отображается подсказка).

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

Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без комментариев.

Логические ошибки

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

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

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

Описание действий в качестве наименований модуля/подмодуля. Например, «запуск приложения» — это НЕ модуль или подмодуль. Модуль или подмодуль — это всегда некие части приложения, а не его поведение. Сравните: «дыхательная система» — это модуль человека, но «дыхание» — нет.

Описание событий или процессов в качестве шагов или ожидаемых результатов. Например, в качестве шага сказано: «Ввод спецсимволов в поле X». Это было бы сносным заглавием тест-кейса, но не годится в качестве шага, который должен быть сформулирован как «Ввести спецсимволы (перечень) в поле X». Куда страшнее, если подобное встречается в ожидаемых результатах. Например, там написано: «Отображение скорости чтения в панели X». И что? Оно должно начаться, продолжиться, завершиться, не начинаться, неким образом измениться (например, измениться должна размерность данных), как-то на что-то повлиять? Тест-кейс становится полностью бессмысленным, т.к. такой ожидаемый результат невозможно сравнить с фактическим поведением приложения.

«Выдумывание» особенностей поведения приложения. Да, часто в требованиях отсутствуют самоочевидные (без кавычек, они на самом деле самоочевидные) вещи, но нередко встречаются и некачественные (например, неполные) требования, которые нужно улучшать, а не «телепатически компенсировать».

Например, в требованиях сказано, что «приложение должно отображать диалоговое окно сохранения с указанным по умолчанию каталогом». Если из контекста (соседних требований, иных документов) ничего не удаётся узнать об этом таинственном «каталоге по умолчанию», нужно задать вопрос. Нельзя просто записать в ожидаемых результатах «отображается диалоговое окно сохранения с указанным по умолчанию каталогом» (как мы проверим, что выбран именно указанный по умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожидаемых результатах писать «отображается диалоговое окно сохранения с выбранным ката-логом “C:/SavedDocuments”» (откуда взялось это «C:/SavedDocuments», — не ясно, т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно).

Отсутствие описания приготовления к выполнению тест-кейса. Часто для корректного выполнения тест-кейса необходимо каким-то особым образом настроить окружение. Предположим, что мы проверяем приложение, выполняющее резервное копирование файлов. Если тест выглядит примерно так, то выполняющий его сотрудник будет в замешательстве, т.к. ожидаемый результат кажется просто бредом. Откуда взялось «~200»? Что это вообще такое?

Шаги выполнения Ожидаемые результаты
1) Нажать на панели «Главная» кнопку «Быстрая дедубликация». 1) Кнопка “Быстрая дедубликация” переходит в утопленное состояние и меняет цвет с серого на зеленый.
2) Выбрать католог “C:/MyDaya”. На панели “Состояние” в поле “Дубликаты” отображается “~200”.

И совсем иначе этот тест-кейс воспринимался бы, если бы в приготовлениях было сказано: «Создать каталог “C:/MyData” с произвольным набором подкаталогов (глубина вложенности не менее пяти). В полученном дереве каталогов разместить 1000 файлов, из которых 200 имеют одинаковые имена и размеры, но НЕ внутрен-нее содержимое».

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

- Дымовое тестирование  Тестирование критического пути Расширенное тестирование 
Плохо Запуск приложения. Запуск приложения. Запуск приложения.
Хорошо Запуск приложения. Запуск приложения из командной строки.
Запуск приложения через ярлык на рабочем столе.
Запуск приложения через меню “Пуск”.
Запуск приложения из командной строки в активном режиме.
Запуск приложения из командной строки в фоновом режиме.
Запуск приложения через ярлык на рабочем столе от имени администратора.
Запуск приложения через меню “Пуск” из списка часто запускаемых приложений.

Слишком длинный перечень шагов, не относящихся к сути (цели) тест-кейса. Например, мы хотим проверить корректность одностороннего режима печати из нашего приложения на дуплексном принтере. Сравните тест-кейсы “Односторонняя печать”:

Плохо Хорошо
1) Запустить приложение. 1) Открыть любой DOCX-файл, содержащий три и более непустых страницы.
2) В меню выбрать «Файл» -> «Открыть». 2) В диалоговом окне “Настройка печати” в списке “Двустороняя печать” выбрать “Нет”.
3) Выбрать любой DOCX-файл, состоящий из нескольких страниц. 3) Произвести печать документа на принтере, поддерживающем двустороннюю печать.
4) Нажать кнопку «Открыть».
5) В меню выбрать «Файл» -> «Печать».
6) В списке «Двусторонняя печать» выбрать пункт «Нет».
7) Нажать кнопку “Печать”.
8) Закрыть файл.
9) Закрыть приложение.

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

Некорректное наименование элементов интерфейса или их свойств. Иногда из контекста понятно, что автор тест-кейса имел в виду, но иногда это становится реальной проблемой. Например, мы видим тест-кейс с заглавием «Закрытие приложения кнопками “Close” и “Close window”». Уже тут возникает недоумение по поводу того, в чём же различие этих кнопок, да и о чём вообще идёт речь. Ниже (в шагах тест-кейса) автор поясняет: «В рабочей панели внизу экрана нажать “Close window”». Ага! Ясно. Но «Close window» — это НЕ кнопка, это пункт системного контекстного меню приложения в панели задач.

Ещё один отличный пример: «Окно приложения свернётся в окно меньшего диаметра». Хм. Окно круглое? Или должно стать круглым? А, может, тут и вовсе речь про два разных окна, и одно должно будет оказаться внутри второго? Или, всё же «размер окна уменьшается» (кстати, насколько?), а его геометрическая форма остаётся прямоугольной?

И, наконец, пример, из-за которого вполне можно написать отчёт о дефекте на вполне корректно работающее приложение: «В системном меню выбрать “Фиксация расположения”». Казалось бы, что ж тут плохого? Но потом выясняется, что имелось в виду главное меню приложения, а вовсе не системное меню.

Непонимание принципов работы приложения и вызванная этим некорректность тест-кейсов. Классикой жанра является закрытие приложения: тот факт, что окно приложения «исчезло» (сюрприз: например, оно свернулось в область уведомления панели задач (system tray, taskbar notification area)), или приложение отключило интерфейс пользователя, продолжив функционировать в фоновом режиме, вовсе не является признаком того, что оно завершило работу.

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

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

Общая некорректность тест-кейсов. Может быть вызвана множеством причин и выражаться множеством образов, но вот классический пример:

Шаги выполнения Ожидаемые результаты
4) Закрыть приложение нажатием Alt+F4. 4) Приложение завершает работу.
5) Выбрать в меню “Текущее состояние”. 5)Отображается окно с заголовком “Текущее состояние” и содержимым, соответствующим рисунку 999.99.

Здесь или не указано, что вызов окна «Текущее состояние» происходит где-то в другом приложении, или остаётся загадкой, как вызвать это окно у завершившего работу приложения. Запустить заново? Возможно, но в тест-кейсе этого не сказано.

Неверное разбиение наборов данных на классы эквивалентности. Действительно, иногда классы эквивалентности могут быть очень неочевидными. Но ошибки встречаются и в довольно простых случаях. Допустим, в требованиях сказано, что размер некоего файла может быть от 10 до 100 КБ (включительно). Разбиение по размеру 0–9 КБ, 10–100 КБ, 101+ КБ ошибочно, т.к. килобайт не является неделимой единицей. Такое ошибочное разбиение не учитывает, например, размеры в 9.5 КБ, 100.1 КБ, 100.7 КБ и т.д. Потому здесь стоит применять неравенства: 0 КБ ≤ размер < 10 КБ, 10 КБ ≤ размер ≤ 100 КБ, 100 КБ < размер. Также можно писать с использованием синтаксиса скобок: [0, 10) КБ, [10, 100] КБ, (100, ∞) КБ, но вариант с неравенствами более привычен большинству людей.

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

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

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

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

09.10.2017. Перейти на Главную страницу