Для чего в тест кейсе нужны шаги
Правила написания предварительных шагов в тест-кейсах
Содержание
Что такое предварительные шаги тест-кейса
Тест-кейс — это подробное описание проверки. Такое, которое можно будет дать человеку с улицы и он все поймет. В тест-кейсе есть название, предварительные шаги, шаги и результат. И куча других примочек, которые будут зависеть от стандартов оформления на вашей работе. В этой статье я хочу поговорить о предварительных шагах.
Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация.
Скажем, чтобы поставить лайк под фото, мне нужно войти в систему. Вот чтобы я смогла войти в систему, мне сначала надо зарегистрироваться, если я не делала этого раньше. Но, если я подготовилась заранее, этот предварительный шаг можно выкинуть.
Это как когда готовишь. Скажем, шарлотку
Шарлотка
| Сходить в магазин и купить: |
| Вкусная шарлотка! Которую родные уминают за 5 минут. |  |
Фишка в чем? Если у меня уже есть яйца, я могу их не покупать. Но взбивать их мне все равно придется. Даже если я неделю назад взбивала яйца с сахаром, я не могу их взять сейчас (они же уже протухли!). То есть шаги я выкинуть не могу, сделав их заранее. А вот предварительные — вполне.
Также и в ИТ мире. Не надо радостно перетаскивать в предварительные шаги вообще все. Например:
Кликнуть на кнопку «Войти»…
Что? Какая кнопка? Где мне ее искать? На рабочем столе? Шаги должны быть независимыми. Если говорить про веб-сайт, я должна открыть новую вкладку в режиме инкогнито и там пройтись по всем шагам и у меня все получится. Поэтому выкидывать ссылку на сайт в предварительные шаги не надо, она важна для выполнения теста.
А вот если я уже заранее зарегистрировалась, то хоть в новой вкладке, хоть в новом окне открою все и пройдусь по шагам. Авторизация то будет работать, если вы укажете, под кем входить. А регистрация прямого отношения к тесту не имеет.
Какие еще могут быть предварительные шаги? Посмотрим на примере Дадаты. Тестируем функционал обработки файла. Он доступен только авторизованному пользователю → надо зарегистрироваться. И он небесплатный → нужно пополнить баланс. И, конечно, у нас должен быть на руках файл для загрузки.
Регистрация на сайте, пополнение баланса и подготовка файлов — предварительные шаги, они не имеют прямого отношения к тесту загрузки файла, это так, подготовка. Как они будут выглядеть? Допустим, мы хотим обработать файл-образец (есть такой в системе).
На что обратить внимание при написании предварительных шагов? Давайте разберемся с правилами их написания.
Правила их составления
1. Писать лучше обезличено
Повелительное наклонение неприятно читать: пойди, открой, сделай, нажми. Фи.
Превращаем в нейтральные глаголы: пойти, открыть, сделать, нажать…
2. Писать нужно в едином стиле
Все предложения должны быть в едином стиле, а то читаешь потом такой текст и недоумеваешь:
3. Можно ссылаться на другие тест-кейсы
Так как предварительные шаги прямого отношения к тесту не имеют → мы не расписываем их подробно. Если надо уточнить, как выполнить действие, дайте ссылку на другой кейс:
Зарегистрироваться с именем «Д`Артаньян» (см. тест-кейс «Регистрация»).
Зарегистрируйся с таким-то именем. Если не знаешь как — welcome to тест-кейс регистрации.
Только помните, зачем делается отсылка на другой тест → чтобы, если у нас что-то поменяется в том действии (например, в регистрации), чтобы мы изменили это в ОДНОМ месте, в ОДНОМ тесте, а не в 100500.
Поэтому не надо писать «Зарегистрироваться в системе: зайти по ссылке А, нажать кнопку «Регистрация» в правом верхнем углу сайта, ввести в поле «имя» такое-то значение…». Завтра название кнопки изменится, вы во всех кейсах будете исправлять? А зачем?
4. Но не доходя до маразма ツ
Вот у нас в Дадате студенты пишут тест-кейсы на загрузку и обработку файлов. Чтобы им было проще, первый тест-кейс тренер сделал сам. Тест-кейс — на обработку файла-образца. Того, который система предоставляет для демонстрации своих возможностей.
Предварительные шаги выглядят так:
А потом студент тестирует, скажем, обработку файла в формате CSV. Угадайте с трех раз, как выглядят его предварительные шаги? Правильно!
Вот и как я тут должна понять, что за файл я должна скачать? В формате CSV? С одной строкой и одной колонкой, с 10000 колонок? С разным форматом дат рождения? С весом в 5 Мб? Какой? ЧТО именно тестируется?
Некоторые студенты учитывают этот момент и пишут так:
Но тут возникает новый вопрос — откуда скачать? Из тест-линка, внутри которого написан тест? Из какого-то общего хранилища? И что это за тест-кейс такой магический на скачивание файла, на который идет отсылка? Это ведь явная копипаста из примера. Там написано «тест-кейс на скачивание», значит, и я также напишу!
Почему в моем примере написано «скачать»? Потому что файл-образец в системе уже есть! И если мы хотим его протестировать, нам надо именно скачать то, что находится по ссылке «образец», а не какой-то свой прошлогодний файл в систему запихивать. Иначе какой смысл в этом тесте?
Отдельный тест-кейс на скачивание образца тоже сделан не просто так. Ведь нам надо убедиться в том, что по ссылке «образец» скачивается ровно то, что нам нужно. Что написано в ТЗ. Ведь в образце не какие-то абстрактные данные, они подобраны специальным образом, чтобы что-то показать, какие-то возможности системы.
Отдельный тест-кейс на скачивание образца:
В этом случае нам не важно наполнение файла. Мы просто хотим загрузить точно-работающий файл. И образец в этом случае идеален! Ведь если система не в состоянии обработать собственный образец — какое к ней может быть доверие? Тест на обработку образца идет первым в приоритете тестировщика.
А дальше мы уже исследуем, как реагирует система на разные форматы, разный вес, разное количество столбцов и колонок… И для этих тестов файлы придется готовить самостоятельно. Скачать то неоткуда!
Поэтому в предварительных шагах мы пишем о том, какой именно файл надо подготовить. Так и пишем: «Подготовить такой-то файл, см пример в аттаче».
Подготовить файл формата doc с данными из файла-примера (см аттач «Пример.doc»)
Подготовить файл с разными форматами дат рождения (см аттач «Даты рождения.xls»)
Подготовить файл картинкой внутри вместо текста (см аттач «Картинка. xls»)
Еще раз: не скачать. Подготовить. И никаких отсылок на мифический тест-кейс «Скачивание файла», что это за тест-кейс? Что он проверят в рамках нашей системы? И зачем нам на каждый тест-кейс писать отдельный тест-кейс на подготовку файла? Просто чтобы сослаться ради ссылки? Не надо.
Заметьте, как описан подготовительный шаг — мы готовим файл. Не скачиваем аттач, а готовим файл. И написано, что это за файл — вдруг аттач испарится завтра, случайно удалим? Все равно понятно, какой именно файл надо готовить )
А еще аттач может устареть — изменили функционал системы, файлы в старом формате уже не грузятся. Но если описано, ЧТО это за файл, тестировщик сможет его обновить!
5. Выкидывать текст ради текста нужно
«Кратко, но емко!» — главное правило оформления текстов. Будь то баг-репорт, тест-кейс или письмо Заказчику.
Текст ради текста всегда выкидываем. Сравните:
Что лучше? Лучше первый вариант, так как там меньше текста. У нас ведь все тесты на сайт https://www.example.com/, зачем тогда лишний раз писать ссылку? Тем более что потом придется продублировать ее в основных шагах.
А если разработчик решит поменять URL ссылки? Зачем нам вносить лишние правки? Когда надо поменять в 10 местах, всегда есть шанс хоть одно продолбать → а в итоге у нас будет неактуальная тестовая документация.
Мы потому и выносим регистрацию в предварительные шаги. Чтобы не исправлять сотни кейсов, если что-то изменится. Поправить в одном месте, в одном кейсе.
Ок, а если выбирать из таких вариантов, что будет лучше? Подумайте сами, прежде чем прочитать ответ:
Правильный ответ — все зависит от контекста. Если нам важно зарегистрироваться именно с таким именем (проверяем женские имена, или имена с апострофом, или что-то еще) — это нужно указать в предварительном шаге с регистрацией.
А если нам неважно, будет email «xxx@gmail.com» или «olala@gmail.com» — зачем об этом писать? Если я умею регистрироваться, я как-нибудь справлюсь с придумыванием email. Если не умею — пойду в тест-кейс регистрации и пройду по нему.
Поэтому, если нам важен сам факт регистрации, будет лучше вариант 1. Если важны данные — вариант 2.
6. Предварительных шагов может и не быть — это нормально
Не надо высасывать их из пальца там, где они не нужны. Именно так и получаются тесты, в которых просто отсекли первые 2-3 шага и запихали в раздел «предварительные шаги» непонятно зачем.
Шаги
Ввести логин такой-то, пароль сякой-то
Итого
Предварительные шаги — это все то, что поможет нам пройти тест-кейс, но прямого отношения к текущему тесту не имеет. Например, регистрация в системе. Или покупка ингредиентов для шарлотки ツ
Правила описания предварительных шагов:
Пишем максимально эффективный тест-кейс
Что такое тест-кейс?
Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату.
Набор тест-кейсов называют тест-комплектом. Иногда тест-набор путают с тест-планом. Тест-план описывает какие работы, как и когда должны быть проведены в рамках тестирования продукта, а так же что необходимо для их выполнения.
Зачем нужны тест-кейсы?
Атрибуты тест-кейса
Любой тест-кейс обязательно включает в себя:
Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.
Что еще необходимо знать, перед созданием тест-кейса?
Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:
1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.
Во-вторых, одним тест-кейсом проверяется одна конкретная вещь, и для этой вещи должен быть только один ожидаемый результат.
Чего не должно быть в тест-кейсе
1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.
Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки.
Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов.
Со вторым думаю все ясно. Если описание шагов или ожидаемое результата будет не четким, то это блокирует прохождение тест-кейса.
В тест-кейса должно быть вся информация, которая необходима для его прохождения. Например, если мы проверяем окно логина на сайте, значит нам понадобится логин и пароль, иначе прохождение этого сценария будет невозможно.
Так же не следует слишком детализировать кейс. Например, если мы проверяем возможность создания комментария, то не стоит писать в каком угле экрана должно быть окно логина. Избыточная информация только затрудняет прохождение тест-кейса.
Для чего в тест кейсе нужны шаги
Без какой части тест-кейс никак не может обойтись?
Вопрос номер 2
Для чего в тест-кейсе нужны шаги?
Шаги нужны для того что бы привести тестировщика к фактическому результату, необходимому, чтобы узнать, есть баг или нет.
Вопрос номер 3
Два вида исхода исполнения тест-кейса. К какому исходу мы, как тестировщики, стремимся?
Каждый завершенный тест-кейс дает один из двух исходов (результатов):
Положительный исход (PASS), если фактический результат исполнения тест-кейса равен ожидаемому.
Отрицательный исход (FAIL) если фактический результат исполнения тест-кейса НЕ равен ожидаемому.
Вопрос номер 4
Вопрос номер 5
Вопрос номер 6
УНИКАЛЬНЫЙ ID(Unique ID)
ID должен быть уникальным в пределах не только документа, содержащего тест-кейс, но и всего департамента качества. Необходим для ведения статистики по тест-кейсам, обновления, удаления или переноса в другой документ. Что бы ничего не путалось.
ПРИОРИТЕТ ТЕСТ-КЕЙСА (Test Case Priority)
Используется для определения важности тест-кейса. Помогает определить очередность выполнения тест-кейсов.
ИДЕЯ (IDEA)
Это описание конкретной вещи, проверяемой тест-кейсом.
ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ(SETUP and ADDITIONAL INFO)
Все данные, которые могут понадобиться при выполнении тест-кейса, собранные в одном месте.
Вопрос номер 7
Вопрос номер 8
Вопрос номер 9
Вопрос номер 10
Вопрос номер 11
Формальные недостатки, не позволяющие тест-кейсам быть белыми и пушистыми.
Если я правильно понял вопрос, то речь идет о поддерживаемости тест-кейса.
Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен.
Ответ из комментариев
Формальные недостатки, не позволяющие тест-кейсам быть белыми и пушистыми.
Если я правильно понял вопрос, то речь идет о поддерживаемости тест-кейса.
Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен.
Я не понял вопрос, стоит уточнить у автора.
Вопрос номер 12
Вопрос номер 13
Ожидается ли, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО?
Никто не ожидает, что тест-кейсы будут на 100% «работать» сразу после написания. Дело в том, что они создаются на основании опека (или, как это часто бывает, на основании устного пожелания начальника), и так как мы физически не видим функциональностей этого опека (код еще не написан), то многие вещи нужно в буквальном смысле представить себе. Кроме того, как мы уже видели, сами спеки имеют баги и спек может быть изменен без ведома тестировщика.
Ответ из коментариев
Да, ожидается, что тестировщик изменит тест-кейс, написанный лишь на основании спека, без знакомства с реально написанным ПО.
Вопрос номер 14
Вопрос номер 15
Приведите атрибуты шапки тест-комплекта.
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека.
Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека.
Producer — продюсер, написавший спек.
Developer — программист, пишущий код в соответствии со спеком.
Добавленно из комментариев
Overview — вкратце рассказывается, чему посвящен этот тест-комплект.
GLOBAL SETUP and ADDITIONAL INFO — здесь мы говорим о повторяющихся вещах, которые будем использовать в более чем одном тест-кейсе, и вообще о любой другой полезной информации для всего тест-комплекта.
Вопрос номер 16
Состояния тест-кейса.
состояние — «Новый» (New).
Это первая редакция тест-кейса:
«Created on: 11/17/2003 by 0. Тарасов».
состояние — «Измененный» (Modified).
Модификации, как правило, связаны с изменением спека, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке:
«Modified on: 11/26/2003 by И.Новикова».
состояние — «Более недействителен» (Retired).
Вопрос номер 17
Вопрос номер 18
Вопрос номер 19
Тест-кейс «проверяет» не более одной идеи. При этом два и более ожидаемых результата легитимны, если истинность идеи вытекает из одновременной истинности этих ожидаемых результатов.
Тестовая документация. Тест кейс
Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Высокоуровневый тест-кейс — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполнению тест-кейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, поскольку прописать все данные подробно намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса — документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).
Цель написания тест-кейсов:
Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне, в зависимости от множества факторов). Наличие же тест-кейсов позволяет:
Жизненный цикл тест-кейса
В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь идёт о наборе состояний, в которых он может находиться.
Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения.
Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
Выполняется (work in progress) — если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
Пройден успешно (passed) — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
Требует доработки (not ready) — как видно из схемы, в это состояние (или из него) тест-кейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
Структура тест кейса
Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например, UR216_S12_DB_Neg).
Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля является не обязательным.
Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам.
Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса.
Общие рекомендации по написанию шагов таковы:
Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.
Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
Преимущества последовательных наборов:
К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии (или сценарии использования), представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.
Классификация наборов тест-кейсов
Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).
Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего.
Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также то, что при провале какого-то тест-кейса (приложение не пришло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять.
Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же принципам в набор включаются тесты, обладающие подходящими свойствами.