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

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

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

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

Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации:

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

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

Баланс между специфичностью и общностью.

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

Рассмотрим «шаги» и «ожидаемые результаты» двух тест-кейсов:

• Тест-кейс 1:

Тест-кейс 2:

Какой тест-кейс считается хорошим, а какой — плохим и почему?

Ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим.

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

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

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

Вот пример такого срединного подхода:

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

Баланс между простотой и сложностью

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

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

• их можно быстро прочесть, легко понять и выполнить;
• они понятны начинающим тестировщикам и новым людям на проекте;

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

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

Слишком простой тест-кейс:

• Сложный – тест - кейс

• Пример хорошего тест – кейса

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

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

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

Последовательность в достижении цели

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

Нарушение может выглядеть так:

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

Отсутствие лишних действий

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

Вторая по частоте ошибка — начало каждого тест-кейса с запуска приложения и подробного описания по приведению его в то или иное состояние.

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

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

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

Демонстративность

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

Пример недемонстративного тест – кейса

Пример демонстративного тест - кейса

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

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

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

Прослеживаемость

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

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

Недостатки, затрудняющие прослеживаемость:

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

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

Возможность повторного использования

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

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

Повторяемость

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

• во-первых, даже общие формулировки, допускающие разные варианты выполнения тест-кейса, должны определять соответствующие явные границы (например: «ввести какое-нибудь число» — плохо, «ввести целое число в диапазоне от -273 до +500 включительно» — хорошо);
• действия (шаги) тест-кейса по возможности не должны приводить к необратимым последствиям (например: удалению данных, нарушению конфигурации окружения и т.д.) — не стоит включать в тест-кейс такие «разрушительные действия», если они не продиктованы явным образом целью тест-кейса; если же цель тест-кейса обязывает нас к выполнению таких действий, в самом тест-кейсе должно быть описание действий по восстановлению исходного состояния приложения (данных, окружения).

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

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