Ошибки при написании тест кейсов

В этом материале о тест кейсах вы узнаете:

1. Что такое тест кейс
2. Из чего состоит тест кейс и какая у тест кейсов форма
3. Правила написания хорошего тест кейса
4. Типичные ошибки в тест кейсах

Что такое тест кейс

Тест кейс — это проверка работоспособности программы или проекта.
Написать тест кейс — значит создать текстовое описание процесса тестирования какой-то части или функции проекта.

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

1. Порядковый номер тест кейса
2. Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
3. Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
   Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды
4. Порядок действий в тест кейсе и описания действий в тест кейсе
5. Ожидаемый результат тест кейса.

Вот пример тест кейса:

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

1. Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
2. Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
3. Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.

Существуют 6 правил проведения тест кейсов:

1. Один тест кейс должен проверять только одну конкретную вещь.
2. Тест кейс не должен зависеть от других тест кейсов.
3. Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
4. В тест кейсе должна быть вся информация. необходимая для его проведения.
5. В тест кейсе не должно быть лишних деталей.
6. Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.

Прочитайте статью Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила!

Типичные ошибки при написании тест кейсов

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

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

Плохо: yandex.ru
Хорошо: yandex.ru

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!

Автор: Артём Ваулин

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

Странное название?

Обычно TOP-ы круглочисленные (Fortuna 500, Русская 10-ка и т.д.)?

Почему именно 13? Не потому ли, что по общепринятому мнению (программисты часто считают свое мнение — общепринятым) тестировщики приносят одни несчастья?

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

Все намного проще…

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

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

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

1. Требования
2. Тест-кейсы
3. Управление ошибками
4. Документирование
5. Взаимодействие

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

Требования

1. Требования необходимо тестировать

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

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

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

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

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

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

В заключении заметки о тестировании требований еще раз осмелюсь повторить критерии качества требований к программному обеспечению:

• Корректность
• Недвусмысленность (однозначность)
• Полнота
• Непротиворечивость (совместимость)
• Упорядоченность (ранжированность по важности и стабильности)
• Проверяемость (тестируемость или тестопригодность)
• Модифицируемость
• Трассируемость (прослеживаемость)
• Понятность

Тест- кейсы

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

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

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

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

Написанные тест-кейсы часто объединяются в тестовые наборы (test suite).

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

2. Тест-кейсы необходимо писать по требованиям

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

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

Данное определение ни в коем случае не претендует на полноту и описывает процесс тестирования только с одной стороны. С той стороны, которая повернута к требованиям. Именно поэтому не стоит расценивать все, что будет написано дальше, как исчерпывающую инструкцию по написанию тест-кейсов.

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

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

В этом случае получается, что в процессе тестирования проверяется соответствие разработанного продукта разработанному продукту (вот такой каламбурчик). Сами можете представить себе, что из этого получается.

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

3. Тест-кейсы должны не повторять требования, а проверять их

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

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

Что я имею в виду, когда пишу, что тесты должны не повторять требования, а проверять их?

Поясню на простых (естественно, выдуманных, чтобы читатели не краснели, при виде своих собственных творений) примерах.

Есть одно из функциональных требований к системе, для которого необходимо написать тест-кейсы: Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «A» и «B».

Тест-кейс, написанный ленивым тестировщиком:

…

Действия:

Ввести значения в поля «A» и «B».

Ожидаемый результат:

Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.п.).

…

Тест-кейс, написанный неленивым тестировщиком:

…

Действия:

1. В поле «А» ввести значение 2

2. В поле «B» ввести значение 3

3. Нажать на кнопку «Рассчитать»

Ожидаемый результат:

В поле «Сумма» отобразилось значение 5

…

Чем второй тест-кейс лучше первого?

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

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

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

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

4. Написание приемочных тест-кейсов (по определенным правилам)

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

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

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

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

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

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

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

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

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

Сокращенно звучит он так — один тест-кейс — одна проверка.

Как реагировать на следующий тест-кейс?

…

Steps

1. Действие 1

2. Действие 2

3. Действие 3

4. Действие 4

Expected Results

1. Результат 1

2. Результат 2

3. Результат 3

4. Результат 4

…

Каждому номеру действия необходимо сопоставлять соответствующий номер ожидаемого результата? Или же после выполнения полностью всех действий мы получим результат, состоящий из четырех пунктов? А может быть как — то еще?

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

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

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

5. Своевременность отметок о прохождении/сбое тест-кейсов

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

В нашем случае цель проста — в любой момент времени отслеживать текущую ситуацию по процессу выполнения тест-кейсов:

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

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

Чаще всего тестировщики не проставляют отметки сразу же, откладывая на потом, когда полностью закончат тестирование. Какие я вижу минусы в этом подходе:

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

Выполнив 125 тест-кейсов тестировщик вряд ли точно вспомнит, какие тест-кейсы прошли успешно, а какие нет.

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

Поэтому давайте делать все в свое время! Как говорится: «Дорога ложка к обеду».

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

Что такое тест-кейсы

Это четкое описание входных данных, условий и процедуры тестирования, ожидаемых результатов. Они определяют один сценарий — конкретную цель тестирования программного обеспечения. Целью может быть проверка ПО: соответствует ли оно требованиям.

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

Отличия

🚀 От чек-листа

В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.

🚀 От баг-репорта

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

Виды тест-кейсов

Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.

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

2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.

3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.

Пример 

У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».

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

Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название.

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

Жизненный цикл

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

1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.

2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.

3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.

4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.

Обязательные атрибуты

Они тоже зависят от внутренней культуры компании или возможностей систем управления тест-кейсами. И даже от типа тестируемого ПО. Но обычно выделяют следующие атрибуты:

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

✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.

✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.

✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.

✅ Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.

✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.

✅ Статус — текущее состояние тест-кейса.

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

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

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

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

👉 Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.

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

👉 Задавайте идентификатор тест-кейса. Так, чтобы его было легко идентифицировать. Например, когда отслеживают ошибки или определяют требования к ПО на более позднем этапе.

👉 Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:

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

👉 Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.

👉 Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.

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

Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.

На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.

Шаблон и пример тест-кейса

Главное о тест-кейсах

• Тест-кейс — это четкое описание входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов.
• Исходным документом для тест-кейсов может быть чек-лист. Проваленный тест-кейс служит источником данных для баг-репорта.
• Обязательные атрибуты тест-кейса: уникальный идентификатор, краткое описание, входные данные. А еще шаги, ожидаемый результат, фактический результат, статус.
• От правильности написания тест-кейсов зависит качество тестирования. Создавайте простые тест-кейсы с учетом интересов конечного пользователя. Избегайте повторов и не предполагайте, пишите тестовые примеры. Внедряйте методы тестирования, самоочистку, консультируйтесь с экспертами.

• Что такое тест-кейс и зачем он нужен
• Чем отличаются тест-кейс и чеклист
• Типы тест-кейсов
• Атрибуты тест-кейса ручного тестирования
• Характеристики хорошего тест-кейса
• Лучшие практики в написании тест-кейсов
• Формирование тест-кейсов
• Примеры тест-кейсов ручного тестирования
  • Позитивный
  • Деструктивный
  • Негативный
• Итоги: тестирование тест-кейса

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

Что такое тест-кейс и зачем он нужен

Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.

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

Чем отличаются тест-кейс и чеклист

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

Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

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

Позитивные, негативные и деструктивные тест-кейсы

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

В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования. 

Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.

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

Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.

Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования. 

Для деструктивного тестирования QA-специалисты могут применять следующие методы:

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

Атрибуты тест-кейса для ручного тестирования

Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:

1. ID — уникальное сочетание букв и цифр.
2. Заголовок — основная идея тест-кейса, краткое описание его сути. Например, заголовок тест-кейса для ручного тестирования страницы входа может выглядеть следующим образом: «Проверить вход пользователя с корректными данными».
3. Предусловия — список действий, которые необходимо выполнить перед выполнением тест-кейса. При необходимости здесь могут указываться учетные данные.
4. Шаги — описание действий, необходимых для проверки.
5. Постусловия — список действий, возвращающих систему в исходное состояние (указывается при необходимости).
6. Ожидаемый результат — то, что мы ожидаем получить после успешного выполнения тест-кейса.
7. Фактический результат — то, что мы получаем после выполнения тест-кейса (указывается при необходимости).
8. Статус — Success (успех), Failed (провал), Blocked (блокировка) (указывается при необходимости).

Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:

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

Характеристики хорошего тест-кейса

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

Короче говоря, хороший тест-кейс:

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

Best practices в написании тест-кейсов

Под  best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:

• Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.
• Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.
• Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.
• Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.
• Не забудьте указать учетные данные, если они необходимы для выполнения теста.
• Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.
• Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.

Формирование тест-кейсов

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

Примеры тест-кейсов для ручного тестирования

Позитивный тест-кейс

Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.

ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).

Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).

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

Шаги:

1. Откройте домашнюю страницу. (Ссылка не обязательна, ее наличие может затруднить поддержку тест-кейса в будущем).
2. Введите в поле поиска ключевое слово, связанное с названием доступного продукта.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте результаты.

Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.

Деструктивный тест-кейс

Еще один пример — деструктивный тест-кейс.

ID: FWSF-2.

Заголовок: Проверить устойчивость поиска к SQL-инъекциям.

Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.

Шаги:

1. Откройте домашнюю страницу.
2. Введите SQL-запрос в поле поиска.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте, правильно ли отображаются результаты, нет ли сообщений об ошибках на странице результатов поиска.

Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.

Негативный тест-кейс

Наконец, вот вам негативный тест-кейс.

ID: FWSF-3.

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

Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.

Шаги:

1. Откройте домашнюю страницу.
2. Введите комбинацию недопустимых значений в поле поиска.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте, отображается ли предупреждающее сообщение «Пожалуйста, используйте только допустимые символы».

Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.

Итоги: тестирование тест-кейса

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

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

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

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

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

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

Что важно при составлении чек-листа?

Создание качественногоартефакта – это уже половина успеха. При написании этого документа важно следовать нескольким рекомендациям:

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

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

Чек-лист: как избежать ошибок?

Это один из наиболее острых вопросов для тестировщиков. Чаще всего недочёты и недоработки этого документа связаны счеловеческим фактором. Чтобы не допустить ошибок при создании данных артефактов, следует опираться на три принципа.

1. Чек-лист – это не развёрнутая и досконально проработанная инструкция

Это только лаконичное напоминание, черновик для QA-процесса. Пункты списка касаются только основных этапов тестирования.

1. Чек-лист стоит рассматривать не как план работы, а как эффективнейший инструмент экономии времени

Данный артефакт служит отличной подсказкой, которая направит процесс оценки качество в верное русло.

1. Пункты чек-листа могут и должны корректироваться

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

Что такое тест-кейс?

Тест-кейс (test case) – это детальное описание проверки работоспособности программного решения. Совокупность подобных документов называется тестовым набором (test suite).

Эти артефакты могут быть двух типов: позитивные или негативные. Для проведения позитивных проверок применяются корректные данные и оценивается ожидаемое поведение ПО. Негативный сценарий используется, когда нужно посмотреть на программу в нестандартных условиях.

Какие ошибки допускаются тестировщиками при составлении чек-листов?

К типичным недочётам и недоработкам тест-кейсов можно отнести следующее:

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

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

Почему чек-лист и тест-кейс являются очень важными инструментами в руках тестировщика?

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

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

1. Зайти на сайт.
2. Открыть раздел «Книги: новинки».
3. Выбрать книгу.
4. Поместить книгу в корзину.
5. Перейти в корзину.

Чек-лист в аналогичной ситуации будет содержать один-единственный пункт – «Поместить книгу в корзину». Здесь уже не нужно пошагово описывать последовательность переходов, нажатий кнопок.

Заключение

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

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

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

Что такое тест-кейсы

Это четкое описание входных данных, условий и процедуры тестирования, ожидаемых результатов. Они определяют один сценарий — конкретную цель тестирования программного обеспечения. Целью может быть проверка ПО: соответствует ли оно требованиям.

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

Отличия

🚀 От чек-листа

В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.

🚀 От баг-репорта

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

Виды тест-кейсов

Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.

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

2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.

3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.

Пример 

У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».

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

Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название.

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

Жизненный цикл

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

1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.

2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.

3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.

4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.

Обязательные атрибуты

Они тоже зависят от внутренней культуры компании или возможностей систем управления тест-кейсами. И даже от типа тестируемого ПО. Но обычно выделяют следующие атрибуты:

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

✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.

✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.

✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.

✅ Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.

✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.

✅ Статус — текущее состояние тест-кейса.

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

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

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

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

👉 Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.

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

👉 Задавайте идентификатор тест-кейса. Так, чтобы его было легко идентифицировать. Например, когда отслеживают ошибки или определяют требования к ПО на более позднем этапе.

👉 Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:

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

👉 Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.

👉 Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.

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

Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.

На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.

Шаблон и пример тест-кейса

Главное о тест-кейсах

• Тест-кейс — это четкое описание входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов.
• Исходным документом для тест-кейсов может быть чек-лист. Проваленный тест-кейс служит источником данных для баг-репорта.
• Обязательные атрибуты тест-кейса: уникальный идентификатор, краткое описание, входные данные. А еще шаги, ожидаемый результат, фактический результат, статус.
• От правильности написания тест-кейсов зависит качество тестирования. Создавайте простые тест-кейсы с учетом интересов конечного пользователя. Избегайте повторов и не предполагайте, пишите тестовые примеры. Внедряйте методы тестирования, самоочистку, консультируйтесь с экспертами.