Думаю, что даже противники бумажной волокиты не будут отрицать, что описанный план проверки значительно упрощает процесс тестирования и экономит в последующем кучу времени.
Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.
Тест-кейсы и чек-листы относятся к документации тестирования. Их задача — систематизировать и упростить процесс тестирования, сделать его более прозрачным и структурированным. А еще их использование может очень сильно экономить время.
Тест-кейс
Тестовый случай, тестовый сценарий (test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Иными словами, это артефакт или документ, который описывает наши тесты. Говорит, как их выполнить, при каких условиях и что должно получиться после выполнения тех шагов, которые заложены в тест-кейсе, то есть каков ожидаемый результат.
Тест-кейс имеет определенный шаблон, разработанный для того, чтобы стандартизировать и упростить создание и дальнейшее чтение тест-кейсов. Шаблон условно стандартизированный, потому что может меняться в зависимости от компаний и процессов.
1.ID — уникальный номер.
Обычно проставляется автоматически в системах хранения тест-кейсов.
2. Краткое описание тест-кейса (Name).
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.
Если мы сделаем название только коротким, то в таких кейсах будет очень сложно ориентироваться.
Например, мы проверяем регистрацию и называем тест-кейс: “Проверить успешную регистрацию”. Вроде логично, но такое название включает в себя проверку регистрации по нескольким полям. И получается, что название не информативно.
Если делать название тест-кейса слишком длинным, то его будет очень сложно читать, например: “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”.
Такое название неудобно читать. Плюс некоторые инструменты хранения тест-кейсов могут обрезать длинные названия.
Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.
3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.
4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс.
5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять.
6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс.
7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу.
8. Шаги (steps) — точная последовательность действий для выполнения проверки.
Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект. Скажу даже больше: иногда вы сами спустя какое-то время с трудом разбираете, что имели ввиду написав тот или иной шаг.
9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов.
10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.
Тест-кейс для авторизации на сайте
Рассмотрим составление тест-кейса на примере тестирования формы авторизации на сайте. Предположим, что нам необходимо проверить Авторизацию существующего пользователя:
1.ID
Пусть будет №1, так как это наш первый тест-кейс
2. Краткое описание тест-кейса (Name)
Авторизация существующего пользователя.
Если бы нам на выбор было предложено несколько способов регистрации (Телефон, E-mail, ВКонтакте, Фейсбук и т.п.), то название могла бы выглядеть вот так “Авторизация существующего пользователя через ВКонтакте”.
3. Ссылка на требования
В нашем случае требований нет. Значит поле оставляем пустым
4. Автор тест-кейсы (Author)
Иванов И.
5. Приоритет (Priority)
Высокий, так как функциональность важная. В двух словах, чем важнее объект тестирования и проверки, тем выше приоритет.
6. Название/модуль/версия продукта (Component/Version)
Кейс относится напрямую к авторизации, следовательно этот модуль и укажем.
7. Предварительные условия (pre-condition)
Во-первых, нужно зайти на сайт по адресу https://msk.farfor.ru. Во-вторых, пользователь должен существовать и быть не залогинен.
8. Шаги (steps)
1) Вводим в поле телефона “+7 900 000-00-00”,
2) Вводим в поле password пароль “123”,
3) Нажимаем кнопку “Вход”.
9. Ожидаемый результат (expected result)
Авторизация прошла успешна, пользователь остался на странице https://msk.farfor.ru
10. Приложения (attachments)
В этот раз файлы нам не нужны, поэтому обойдемся без них.
Для наглядности соберем все это в таблицу.
Обратите внимание, что все тестовые данные, такие как почта или пароль лучше указывать явно, так как это убережет вас от лишних действий и поиска того, каким должен быть правильный аккаунт.
В рассмотренном примере все шаги приводят к одному результату. Но также есть ситуации, когда на каждый шаг будет свой ожидаемый результат.
Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.
Теперь давайте немного поговорим о чек-листах в тестировании.
Чек-лист
Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта.
Можно сказать, что чек-лист — это упрощенный тест-кейс без шагов и прочего описания. Просто список того, что необходимо проверить. Более того, иногда список тест-кейсов является своего рода чек-листом, если смотреть просто на названия тест-кейсов. Например, чек лист «Авторизация пользователя» может выглядеть следующим образом:
1. Авторизация пользователя через E-mail
2. Авторизация пользователя через ВКонтакте
3. Авторизация пользователя с пустым E-mail
4. Авторизация пользователя с неверным паролем и так далее
________________________________
Чек-лист экономит время тестировщика и упрощает поддержку тестовой документации, но, с другой стороны, многие вещи при проверки остаются на совести тестировщика. Например, какой е-mail вводим, какой неправильный пароль и так далее
________________________________
Следовательно, если с чек-листом работают уже опытные тестировщики, то особых проблем не возникает. Если приходят новички и видят чек-листы, то они могут запутаться и неправильно проверить функциональность, потому что не будут с точностью знать, как правильно протестировать и какие данные вводить.
***
Как видите, чек-листы и тест-кейсы сильно упрощают процесс тестирования. Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.
При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить. Достаточно один раз уделить немного больше времени на проверку и написать по ней тест-кейсы и чек-листы, чтобы потом экономить время при следующих проверках.
#1
urururka
-
- Members
-
- 20 сообщений
Новый участник
Отправлено 17 ноября 2015 — 09:40
Народ, я сейчас хожу на собеседования и понял что валюсь на вопросах терминалогии, помогите разобраться, пожалуйста:
1. Что такое тест кейс, тест степ, тестовый сценарий, тест сьют, чек лист и т.д.?
2. Для чего нужен документ Стратегия тестирования? Что это такое вообще?
3. Что такое тест-план?
4. Какая еще бывает документация?
Пробовал капать интернет, но как-то все по разному всё пишут, но общее представления ответов на эти вопросы получил, но и из-за него полностью запутался 
Извините, если это уже здесь обсуждалось, не нашел поисковиком… Киньте ссылку тогда, пожалуйста.
-
0
- Наверх
#2
Molechka
Отправлено 17 ноября 2015 — 10:49
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования 
4. Собственно, техническое задание Которое, правда, очень редко бывает.
Или имеется в виду документация, которая поступает от тестировщика?
-
0
- Наверх
#3
urururka
urururka
-
- Members
-
- 20 сообщений
Новый участник
Отправлено 17 ноября 2015 — 12:47
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
Ух ты! Ольга, спасибо!
1. То есть стратегия тестирования и часть плана? Я как думал, что тест-план — это набор тест-сценариев с описанием параметров проверки (браузер, разрешения экрана, прочая такая штука), и тест-план является частью стратегии. А стратегия — это, где-то прочитал, описание првоерки функционала. Как-то так.
2. А вот фиг его знает что имеют в виду собеседующие… Я как бы тоже отвечал: документация бывает поступающая от аналитиков — ТЗ и прочее. Но видно что-то как-то не так ответил… А какая документация поступает от тестировщика?
-
0
- Наверх
#4
SALar
Отправлено 17 ноября 2015 — 13:23
2. Для чего нужен документ Стратегия тестирования? Что это такое вообще?
http://sqadays.com/ru/talk/38135
Как вариант запишитесь на тестовый прогон этого доклада. Дней через пять делать буду.
PS. http://software-test…-testirovaniia/
Найдите RUP-ский шаблон. Он мне не нравится, авторы сделали стандартную ошибку смешав plan и shedule. Но все равно это лучшее что есть, несмотря на то, что этому шаблону лет 20. Я начинал с него. В 2001.
PS. В моем блоге есть пример плана по RUP-скому шаблону.
-
0
- Наверх
#5
Molechka
Отправлено 17 ноября 2015 — 17:53
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
Ух ты! Ольга, спасибо!
1. То есть стратегия тестирования и часть плана? Я как думал, что тест-план — это набор тест-сценариев с описанием параметров проверки (браузер, разрешения экрана, прочая такая штука), и тест-план является частью стратегии. А стратегия — это, где-то прочитал, описание првоерки функционала. Как-то так.
2. А вот фиг его знает что имеют в виду собеседующие… Я как бы тоже отвечал: документация бывает поступающая от аналитиков — ТЗ и прочее. Но видно что-то как-то не так ответил… А какая документация поступает от тестировщика?
Не за что
По поводу стратегии Salar уже ответил, почитайте у него
Документацию можно писать в виде вариантов использования, как вариант. Диаграммы переходов рисовать.
От тестировщика поступает как раз тест-план, тест-кейсы, чек-листы и прочая.
Уточняйте у работодателей, что они имеют в виду Ну и перечитывайте Савина, Coopeland и другие книжки, каждый раз что-то новое находя)
-
0
- Наверх
#6
Solovey_PO
Solovey_PO
-
- Members
-
- 4 сообщений
Новый участник
Отправлено 21 июня 2019 — 06:00
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
А чем тест-сьют отличается от чек листа?
-
0
- Наверх
#7
Vasiliy
Vasiliy
- ФИО:Касимов Василий
- Город:Москва
Отправлено 21 июня 2019 — 09:13
Сьют это набор тест-кейсов.
Чеклист это список «быстрых» проверок.
-
0
- Наверх
#8
Little_CJIOH
Little_CJIOH
- ФИО:Власкин Павел
- Город:Санкт-Петербург
Отправлено 21 июня 2019 — 10:35
сьют — это набор тест кейсов объединенных некоей логикой ( по модулям системы, по пользовательским сценариям, по уровням тестирования.
чек-лист — это список-напоминалка что нужно сделать, в котором отмечается что уже сделано.
-
0
- Наверх
#9
Solovey_PO
Solovey_PO
-
- Members
-
- 4 сообщений
Новый участник
Отправлено 22 июня 2019 — 00:22
-
0
- Наверх
В чем разница между тестовым сценарием и тестовым случаем?
Я немного запутался в тестовых сценариях и тестовых примерах. Каковы различия между ними?
Допустим, мне нужно проверить коробок спичек. Правильно ли я говорю, что ниже могут быть примеры тестовых сценариев?
- может ли коробка содержать x спичек?
- скажем, коробка закрыта, и я энергично встряхиваю ее. Спички все еще в коробке?
Можете ли вы привести примеры тестовых сценариев и тестовых случаев?
Пример:
Вы тестируете свой телефон:
Сценарий: убедитесь, что устройство автоматически подключается к Wi-Fi, если пользователь создает новый профиль
Test cases:
case 1: create Wi-Fi profile and verify that it created successfully
case 2: verify that device succeeded to connect to Wi-Fi
В этом примере у вас есть один тестовый сценарий, который содержит 2 тестовых случая. Потому что 1-й относится к предварительное условие
Создан 03 июн.
Тестовый пример состоит из набора входных значений, предварительного условия выполнения, исключенных результатов и выполненного постусловия, разработанного для покрытия определенного тестового условия. В то время как тестовый сценарий — это не что иное, как тестовая процедура. Сценарии тестирования имеют связь один ко многим с тестовым набором, значит сценарий имеет несколько тестовых случаев. Каждый раз мы пишем тестовые примеры для тестового сценария. Итак, приступая к тестированию, сначала подготовьте тестовые сценарии, а затем создайте два разных тестовых примера для каждого сценария. Тестовые случаи выводятся (или пишутся) из тестового сценария. Сценарии являются производными от вариантов использования. Сценарий тестирования представляет собой серию связанных друг с другом действий. В то время как тестовый пример представляет собой одно (низкоуровневое) действие пользователя. Сценарий — это поток операций, где в качестве тестовых случаев используется набор входных и выходных данных, предоставляемых Системе. Например:
Проверка функциональности кнопки «Войти» — это тестовый сценарий, а тестовые примеры для этого тестового сценария: 1. Нажмите кнопку, не вводя имя пользователя и пароль. 2. Нажмите кнопку, введя только имя пользователя. 3. Нажмите кнопку при вводе неправильного имени пользователя и неправильного пароля. Так далее…
Тестовый сценарий — это «Что тестировать», а тестовый пример — «Как тестировать».
Создан 30 янв.
Проще говоря, сценарии тестирования предоставляют обзор того, что необходимо тестировать и в каких условиях. Принимая во внимание, что тестовые примеры описывают, как это условие будет проверено с положительным и отрицательным результатом путем изменения предварительных условий и необходимых переменных. Таким образом, 1 сценарий может иметь 1….1* связь с тестовым набором.
Например,
Senario 1 — пользователь подключается к веб-сайту, используя веб-URL, и получает доступ к своему профилю после успешного входа в систему в качестве первой страницы.
Тестовые примеры возможность входа в систему только с именем пользователя возможность входа только с паролем возможность входа в систему с именем пользователя и паролем возможность входа в систему с неправильным именем пользователя и паролем возможность просмотра профиля пользователя после входа в систему возможность просмотра истории заказов пользователей после входа в систему
Я надеюсь, что это имеет немного больше смысла. дайте мне знать, если вам нужны дополнительные примеры.
ответ дан 17 дек ’13, 14:12
Сценарий тестирования
Подтвердите страницу входа
Испытательные случаи
- Введите правильное имя пользователя и пароль
- Сбросить пароль
- Введите неверные учетные данные
Создан 31 янв.
Тест-кейсы — это то, что вы можете изобразить в проработанной форме.
Допустим, что тестовый сценарий является «страницей входа».
Учитывая этот тестовый сценарий, контрольные примеры вероятно, будут связаны со страницей входа и их атрибутами:
-
Подтвердите URL-адрес, чтобы отобразить страницу входа
-
Проверьте поле ввода имени пользователя и пароля в текстовом поле на странице входа.
-
Подтвердите предупреждающее сообщение, когда имя пользователя определено, но пароль пуст, и пользователь нажимает кнопку входа в систему.
-
Подтвердите предупреждающее сообщение, когда имя пользователя не определено, но есть пароль, и пользователь нажимает кнопку входа в систему.
Создан 31 янв.
В общем, прецедент означает как тест и тестовый сценарий что тестировать.
Вот пример с банкоматом.
Испытательные случаи
- Вставьте карту банкомата, которая действительна
- Введите свой пин-код
- Затем дисплей должен отображаться с такими опциями, как «снять», «проверить баланс» и т. д.
- Выберите нужный вариант
- Наконец, машина должна напечатать бумагу с подробностями
Тестовый сценарий
-
Вставьте банкоматную карту
-
Введите свой пин-код
-
Выберите один из вариантов
-
Введите сумму
-
Снять деньги со счета
Создан 31 янв.
Для данного примера: Тестирование приложения, такого как watsapp Тестовые сценарии: Проверка того, что пользователь может совершать видеозвонки. Тестовые примеры: чтобы убедиться, что пользователь может совершать видеозвонки на любой номер. Для проверки качества изображения. Чтобы убедиться, что приложение не падает при звонке.
ответ дан 10 мая ’22, 08:05
Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками
testing
or задайте свой вопрос.
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
-
планированием работ (Test Management)
-
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
-
выполнением тестирования (Test Execution)
-
анализом результатов (Test Analysis)
Основные цели тестирования
-
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
-
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
|
Верификация (verification) |
Валидация (validation) |
|
Соответствие продукта требованиям (спецификации) |
Соответствие продукта потребностям пользователей |
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
-
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
-
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
-
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Атрибуты дефекта
-
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
-
Blocker — ошибка, приводящая приложение в нерабочее состояние, из-за которой дальнейшая работа с системой или ее ключевыми функциями становится невозможна, т.е. тестирование значительной части функциональности становится недоступно
-
Крит (Critical) — неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround).
-
Значительный (Major) — часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
-
Minor — часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид; либо незначительная функциональная ошибка, не нарушающая бизнес-логику тестируемой части приложения.
-
Тривиальная (Trivial) — ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.
-
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
-
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
-
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
-
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
-
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
-
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
-
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
-
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
-
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT).
-
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
-
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
-
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
-
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
-
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
-
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
-
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
-
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
-
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
-
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
-
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
-
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
-
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
-
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
-
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
-
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
-
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
-
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
-
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
-
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
-
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
-
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
-
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
-
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
-
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
-
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
-
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
-
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
-
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
-
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
-
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
-
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
-
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
-
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
-
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
-
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
-
Недвусмысленность — требование должно содержать однозначные формулировки.
-
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
-
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
-
Что нужно тестировать?
-
Как будет проводиться тестирование?
-
Когда будет проводиться тестирование?
-
Критерии начала тестирования.
-
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.
|
Тестовые сценарии |
Функциональное требование 1 |
Функциональное требование 2 |
Функциональное требование 3 |
… |
|
test case 1 |
+ |
+ |
||
|
test case 2 |
+ |
+ |
||
|
test case 3 |
+ |
+ |
+ |
|
|
… |
+ |
Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.
Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
-
Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.
-
Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.
-
Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.
-
иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)
Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).
Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.
|
Шапка |
Название/тема: Краткое описание (Summary) некорректного поведения, составляется по схеме WWW, т.е. ЧТО ГДЕ КОГДА (при каких условиях) |
|
Назначен на (Assigned To) сотрудника, который будет с ним разбираться |
|
|
Статус (Status) бага в соответствии с workflow |
|
|
Компонент приложения (Component): название тестируемой функции или ее части |
|
|
Информация по сборке, на которой была найдена ошибка: Номер версии (Version), название ветки |
|
|
Информация об окружении (Environment): ОС + версия, модель девайса (для мобильных устройств) и т.д. |
|
|
Серьезность (Severity) |
|
|
Приоритет (Priority) |
|
|
Описание |
Подробное описание (Description): указывается по необходимости; как правило, сюда вносятся предусловия (PreConditions) или другая дополнительная полезная информация, например, если для воспроизведения бага нужны специальные знания/данные/инструменты |
|
Шаги воспроизведения (Steps to Reproduce), по которым воспроизводится ситуация, приведшая к ошибке |
|
|
Фактический Результат (Result), полученный после прохождения шагов воспроизведения, часто может быть = теме/краткому описанию (Summary) + расшифровка чего-либо (например, ошибки по коду), если нужно |
|
|
Ожидаемый результат (Expected Result): который правильный, т.е. описание того, как именно должна работать система в соответствии с требованиями |
|
|
Прикрепленные файлы |
Вложения (Attachment): файлы с логами, скриншот или видео каст либо их комбинация для прояснения причины ошибки |
Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.
UPD: статья пополняется. Спасибо @yakoeka
Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется
Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 610)
Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. (ISTQB)
Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. (ISTQB)
Test case (тест-кейс, тестовый пример/случай) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго — формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.
-
Идентификатор набора тестов (Test Suite ID): Идентификатор набора тестов, в которых входит этот кейс;
-
Идентификатор тестового кейса (Test Case ID): Идентификатор самого кейса;
-
Заголовок кейса (Test Case Summary): Краткое и емкое название проводимой проверки;
-
Связанное требование (Related Requirement): Идентификатор требования, к которому относится / отслеживается данный тестовый пример;
-
Предварительные условия (Prerequisites): Любые предпосылки или предварительные условия, которые должны быть выполнены перед выполнением теста;
-
Шаги выполнения (Test Script / Procedure): Шаги выполнения теста;
-
Тестовые данные (Test Data): Тестовые данные или ссылки на тестовые данные, которые должны использоваться при проведении теста;
-
Ожидаемый результат (Expected Result): результат, который мы ожидаем получить после выполнения шагов теста;
-
Статус пройден или не пройден (Status): Другие статусы могут быть «Не выполнено», если тестирование не проводится, и «Заблокировано», если тестирование заблокировано;
-
Заметки (Remarks): Любые комментарии к тесту или выполнению теста;
-
Создано (Created By): Имя автора тестового примера;
-
Дата создания (Date of Creation): Дата создания тестового примера (опционально модификации);
-
Выполнено (Executed By): Имя человека, выполнившего тест;
-
Дата выполнения (Date of Execution): Дата выполнения теста;
-
Тестовое окружение (Test Environment): оборудование / программное обеспечение / сеть, в которых выполнялся тест, т.е. все необходимые сведения об окружении, чтобы можно было воспроизвести полученный результат.
В иностранной литературе часто делят кейсы на две категории:
-
Высокоуровневый тест-кейс (high level test case или logical test case) — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне smoke. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
-
Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Нужно ли вообще писать кейсы? Ответ тот же, что и для любого документа — если написание кейсов решает определенную задачу и это обоснованно, то писать. Если вы один, не путаетесь в небольшом проекте, пользуетесь чек листами/mind map/.., можете и без TMS/test runs reports наглядно предоставлять актуальные сведения о протестированности/качестве заинтересованным лицам, то не писать.
Может ли быть несколько ожидаемых результатов? Может, если это необходимо, но сразу после каждого шага.
Можно ли объединять позитивные и негативные тест-кейсы? Позитивные можно, негативные нельзя, поскольку сложно будет понять, что именно влияет на результат.
Тестовые сценарии (Test case), тестовые варианты. Оформление результатов тестирования.
ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ
Для начала определимся с терминологией, поскольку здесь есть много путаницы, вызванной разными переводами англоязычных терминов на русский язык и разными традициями в тех или иных странах, фирмах и отдельных командах.
Во главе всего лежит термин «тест». Официальное определение звучит так.
Тест — набор из одного или нескольких тест-кейсов.
Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… продолжать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.
Теперь рассмотрим самый главный для нас термин — «тест-кейс».
Тест-кейс — набор входных данных, условий выполнения и ожидаемых
результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.
Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.
Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и
вовсе невозможно выполнить).
Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.
Высокоуровневый тест-кейс — тест-кейс без конкретных входных дан-
ных и ожидаемых результатов.
Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными дан-
ными и ожидаемыми результатами.
Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой
информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса — документ, описывающий набор
тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.
Тест-сценарий — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).
ЦЕЛЬ НАПИСАНИЯ ТЕСТ-КЕЙСОВ
Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов).
Наличие же тест-кейсов позволяет:
- Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
- Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
- Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
- Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
- Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
- Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
- Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
- Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.
ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА
В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь скорее идёт о наборе состояний, в которых он может находиться (жирным шрифтом отмечены наиболее важные состояния).
- Создан — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
- Запланирован — в этом состоянии тест-кейс находится, когда он
или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения. - Не выполнен — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
- Выполняется — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
- Пропущен — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
- Провален — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
- Пройден успешно — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
- Заблокирован — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
- Закрыт — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
- Требует доработки — как видно из схемы, в это состояние (и из него) тест-кейс может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
Ещё раз подчеркнём, что в отличие от жизненного цикла дефекта, который достаточно стандартизирован и формализован, для тест-кейса описанное выше носит общий рекомендательный характер, рассматривается скорее как разрозненный набор состояний (а не строгий жизненный цикл) и может сильно отличаться в разных компаниях (в связи с имеющимися традициями и/или возможностями систем управления тест-кейсами).
Атрибуты (поля) тест-кейса.
Как уже было сказано выше, термин «тест-кейс» может относиться к формальной записи тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компоненты которой называются атрибутами (полями) тест-кейса.
В зависимости от инструмента управления тест-кейсами внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
Общий вид всей структуры тест-кейса представлен ниже:
Теперь рассмотрим каждый атрибут подробно.
Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если
позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например:
UR216_S12_DB_Neg).
Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
- важностью требования, пользовательского сценария или функции, с которыми связан тест-кейс;
- потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
- степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функцией.
Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса,
как прослеживаемость.
Частые вопросы, связанные с заполнением этого поля, таковы:
- Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.
- Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.
Модуль и подмодуль приложения указывают на части приложения,
к которым относится тест-кейс, и позволяют лучше понять его цель.
Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разде-
ляется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули).
И вот уже для таких небольших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится намного проще.
Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения.
Теперь — самое сложное: как выбираются модули и подмодули. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
-
Механизм запуска:
- механизм анализа параметров;
- механизм сборки приложения;
- механизм обработки ошибочных ситуаций.
-
Механизм взаимодействия с файловой системой:
- механизм обхода дерева SOURCE_DIR;
- механизм обработки ошибочных ситуаций.
-
Механизм преобразования файлов:
- механизм определения кодировок;
- механизм преобразования кодировок;
- механизм обработки ошибочных ситуаций.
-
Механизм ведения журнала:
- механизм записи журнала;
- механизм отображения журнала в консоли;
- механизм обработки ошибочных ситуаций.
Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:
- Стартер:
- анализатор параметров;
- сборщик приложения;
- обработчик ошибок.
- Сканер:
- обходчик;
- обработчик ошибок.
- Преобразователь:
- детектор;
- конвертер;
- обработчик ошибок.
- Регистратор:
- дисковый регистратор;
- консольный регистратор;
- обработчик ошибок.
Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на основе графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением
задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению.
Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы
они отглагольными существительными), а не процесс печати или настройки принтера).Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.
Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.
Заглавие тест-кейса призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов.
Сравните.
| Плохо | Хорошо |
|---|---|
| Тест 1 | Запуск, одна копия, верные параметры |
| Тест 2 | Запуск одной копии с неверными путями |
| Тест 78 (улучшенный) | Запуск, много копий, без конфликтов |
| Остановка | Остановка по Ctrl+C |
| Закрытие | Остановка закрытием консоли |
Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочетаний — главное, чтобы выполнялись следующие условия:
- Информативность.
- Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).
Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его всё равно надо писать. Тест-кейсы без заглавий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами.
И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую
ситуацию он проверяет.
Исходные данные, необходимые для выполнения тест-кейса, позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
- Состояние базы данных.
- Состояние файловой системы и её объектов.
- Состояние серверов и сетевой инфраструктуры.
То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,
если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».
Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,
чтобы понять, какой точки зрения на данный вопрос они придерживаются.
Шаги тест-кейса описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы:
- начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
- даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
- если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);
- соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д. — в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний;
- ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»);
- пишите шаги последовательно, без условных конструкций вида «если… то…».
Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению
ошибки, вы не сможете закончить выполнение вашего тест-кейса.
Ожидаемые результаты по каждому шагу тест-кейса описывают реакцию
приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
- описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо);
- пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия,
лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие); - пишите кратко, но не в ущерб информативности;
- избегайте условных конструкций вида «если… то…».
Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».
При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы
отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.
Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов».
Свойства качественных тест-кейсов
Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нарушено одно из следующих свойств.
Правильный технический язык, точность и единообразие формулировок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до-
кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:
- пишите лаконично, но понятно;
- используйте безличную форму глаголов (например, «открыть» вместо «откройте»);
- обязательно указывайте точные имена и технически верные названия элементов приложения;
- не объясняйте базовые принципы работы с компьютером (предполагается, что ваши коллеги знают, что такое, например, «пункт меню» и как с ним работать);
- везде называйте одни и те же вещи одинаково (например, нельзя в одном тест-кейсе некий режим работы приложения назвать «графическое представление», а в другом тот же режим — «визуальное отображение», т.к. многие люди могут подумать, что речь идёт о разных вещах);
- следуйте принятому на проекте стандарту оформления и написания тест-кейсов (иногда такие стандарты могут быть весьма жёсткими: вплоть до регламентации того, названия каких элементов должны быть приведены в двойных кавычках, а каких — в одинарных).
Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т. е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики.
Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):
Тест-кейс 1:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок Приготовления: — Создать папки C:/A, C:/B, C:/C, C:/D. — Разместить в папке C:/D файлы 1.html, 2.txt, 3.md из прилагаемого архива. 1. Запустить приложение, выполнив команду php converter.php c:/a c:/b c:/c/converter.log.2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A. 3. Остановить приложение нажатием Crtl+C. |
1. Отображается консольный журнал приложения с сообщением «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log», в папке 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:/A, затем пропадают оттуда и появляются в папке C:/B. В консольном журнале и файле C:/C/converter.log появляются сообщения (записи) «текущее_время processing 1.html (KOI8-R)», «текущее_время processing 2.txt (CP-1251)», «текущее_время processing 3.md (CP-866)». 3. В файле C:/C/converter.log появляется запись «текущее_время closed». Приложение завершает работу. |
Тест-кейс 2:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок 1. Выполнить конвертацию трёх файлов до пустимого размера в трёх разных кодировках всех трёх допустимых форматов. |
1. Файлы перемещаются в папку-приёмник, кодировка всех файлов меняется на UTF-8. |
Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.
Почему плоха излишняя специфичность (тест-кейс 1):
- при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же действия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки;
- возрастает время написания, доработки и даже просто прочтения тест-кейса;
- в случае выполнения тривиальных действий опытные специалисты тратят дополнительные мыслительные ресурсы в попытках понять, что же они упустили из виду, т. к. они привыкли, что так описываются только самые сложные и неочевидные ситуации.
Почему плоха излишняя общность (тест-кейс 2):
- тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными специалистами, лишь недавно подключившимися к проекту;
- недобросовестные сотрудники склонны халатно относиться к таким тест-кейсам;
- тестировщик, выполняющий тест-кейс, может понять его иначе, чем было задумано автором (и в итоге будет выполнен фактически совсем другой тест-кейс).
Выход из этой ситуации состоит в том, чтобы придерживаться золотой середины (хотя, конечно же, какие-то тесты будут чуть более специфичными, какие-то — чуть более общими).
Вот пример такого срединного подхода:
Тест-кейс 3:
| Шаги | Ожидаемые результаты |
|---|---|
| Конвертация из всех поддерживаемых кодировок Приготовления: — Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов. — Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов. 1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). 2. Скопировать файлы из папки для временного хранения в папку для входных файлов. 3. Остановить приложение. |
1. Приложение запускается и выводит сообщение о своём запуске в консоль и файл журнала. 2. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки. 3. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу. |
В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что
при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки.
Ещё раз главная мысль: сами по себе специфичность или общность тест-кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса.
Баланс между простотой и сложностью. Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден
главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных
действий.
Преимущества простых тест-кейсов:
- их можно быстро прочесть, легко понять и выполнить;
- они понятны начинающим тестировщикам и новым людям на проекте;
- они делают наличие ошибки очевидным (как правило, в них предполагается выполнение повседневных тривиальных действий, проблемы с которыми видны невооружённым взглядом и не вызывают дискуссий);
- они упрощают начальную диагностику ошибки, т.к. сужают круг поиска.
Преимущества сложных тест-кейсов:
- при взаимодействии многих объектов повышается вероятность возникновения ошибки;
- пользователи, как правило, используют сложные сценарии, а потому сложные тесты более полноценно эмулируют работу пользователей;
- программисты редко проверяют такие сложные случаи (и они совершенно не обязаны это делать).
Рассмотрим примеры.
Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями
Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.
Удаление может быть выполнимо, а может быть отклонено согласно требованиям предметной области.
Необходимо, чтобы варианты тестирования демонстрировали различные исходы работы алгоритма. Для описания тестовых сценариев в ресурсах предоставлен шаблон
testing-template.docx(есть в этом репозитории в каталогеdocs).
Расшифровка тестовых информационных полей:
| Поле | Описание |
|---|---|
| Название проекта | Название тестируемого проекта |
| Рабочая версия | Версия проекта/программного обеспечения (первый тест считается 1.0). |
| Имя тестирующего | Имя того, кто проводил тесты |
| Дата(ы) теста | Дата(ы) проведения тестов – это один или несколько дней. Если тесты проводились в более протяженный период времени, нужно отметить отдельную дату для каждого теста. |
| Тестовый пример # | Уникальный ID для каждого тестового примера. Следуйте некоторым конвенциям, чтобы указать типы тестов. Например,‘TC_UI_1′ означает‘user interface test case #1′ ( ТС_ПИ_1: тестовый случай пользовательского интерфейса#1) |
| Приоритет тестирования (Низкий/Средний/Высокий) | Насколько важен каждый тест. Приоритет тестирования для бизнес-правил и функциональных тестовых случаев может быть средним или высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет. |
| Заголовок/название теста | Название тестового случая. Например, Подтвердите страницу авторизации с действительным именем пользователя и паролем. |
| Краткое изложение теста | Описание того, что должен достичь тест. |
| Этапы теста | Перечислите все этапы теста подробно. Запишите этапы теста в том порядке, в котором они должны быть реализованы. Предоставьте как можно больше подробностей и разъяснений. Пронумерованный список – хорошая идея. |
| Тестовые данные | Перечислите/опишите все тестовые данные, используемые для данного тестового случая. Так, фактические используемые входные данные можно отслеживать по результатам тестирования. Например, Имя пользователя и пароль для подтверждения входа. |
| Ожидаемый результат | Каким должен быть вывод системы после выполнения теста? Подробно опишите ожидаемый результат, включая все сообщения/ошибки, которые должны отображаться на экране. |
| Фактический результат | Каким должен быть фактический результат после выполнения теста? Опишите любое релевантное поведение системы после выполнения теста. |
| Предварительное условие | Любые предварительные условия, которые должны быть выполнены до выполнения теста. Перечислите все предварительные условия для выполнения этого тестового случая. |
| Постусловие | Каким должно быть состояние системы после выполнения теста? |
| Статус (Зачет/Незачет) | Если фактический результат не соответствует ожидаемому результату, отметьте тест как неудачный. В ином случае обновление пройдено. |
| Примечания/комментарии | Используйте эту область для любых дополнительных заметок/комментариев/вопросов. Эта область предназначена для поддержки вышеуказанных полей (например, если есть некоторые особые условия, которые не могут быть описаны в любом из вышеуказанных полей, или если есть вопросы, связанные с ожидаемыми или фактическими результатами). |
Аннотация теста
| Мои комментарии | ||
|---|---|---|
| Название проекта | DoeduSam | |
| Рабочая версия | 1.0 | Эту версию не плохо бы вписать в свойства проекта |
| Имя тестирующего | DEMO_xx | |
| Дата(ы) теста | 21.12.2020 | текущая |
Тестовый пример #1:
| Мои комментарии | ||
|---|---|---|
| Тестовый пример # | TC_DP_1 | расшифровывается: TestCase_DeleteProduct_x |
| Приоритет тестирования | средний | бизнес-правило |
| Заголовок/название теста | Удаление товара без продаж и дополнительных товаров | |
| Краткое изложение теста | Товар должен без ошибок удалиться из таблицы товаров | |
| Этапы теста | 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу Products 3. Вызвать метод удаления товара 4. Проверить наличие удаленной записи в таблице |
|
| Тестовые данные | Название: Моторное масло Motor Oil KE900-90042-R Изображение: Товары автосервиса8FE07916.jpg Производитель: Nissan Активен: да Цена: 2060 |
Тут нужно вставить содержимое любой записи из products_a_import |
| Ожидаемый результат | Запись должна быть удалена из таблицы без ошибок и исключений | |
| Фактический результат | Запись удалена | |
| Статус | зачет | |
| Предварительное условие | В базу должны быть загружен тестовый продукт | |
| Постусловие | Таблица товаров должна быть пустой | |
| Примечания/комментарии | Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы |
Что еще можно проверить
-
№2 — удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.
-
№3 — удаление товара с дополнительными картинками. Аналогично №2.
-
№4 — удаление товара с продажами. Вариант без предварительной проверки — база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.
-
№5 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.
Что такое контрольный пример?
TEST СЛУЧАЙ представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый набор содержит шаги теста, данные теста, предварительное условие, постусловие, разработанное для конкретного тестового сценария для проверки любого требования. Тестовый пример включает в себя конкретные переменные или условия, с помощью которых инженер-тестировщик может сравнивать ожидаемые и фактические результаты, чтобы определить, работает ли программный продукт в соответствии с требованиями заказчика.
Что такое тестовый сценарий?
Сценарий тестирования определяется как любая функциональность, которую можно протестировать. Это совокупность тестовых случаев, которая помогает команде тестирования определить положительные и отрицательные характеристики проекта.
Сценарий тестирования дает общее представление о том, что нам нужно тестировать.
Пример тестового сценария
Для приложения электронной коммерции несколько тестовых сценариев
Тестовый сценарий 1: проверка функциональности поиска
Тестовый сценарий 2: проверка функциональности платежей
Тестовый сценарий 3: проверка функциональности входа
Пример тестовых случаев
Тестовые сценарии для сценария тестирования: «Проверка функциональности входа» будет
- Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
- Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
- Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
- Проверить Забыли пароль работает как положено
- Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
- Проверять поведение системы, когда установлен флажок «Держать меня в подписи»
Почему мы пишем тестовые случаи?
Вот несколько важных причин для создания контрольного примера:
- Контрольные примеры помогают проверить соответствие применимым стандартам, рекомендациям и требованиям клиентов
- Помогает вам подтвердить ожидания и требования клиентов
- Улучшенный контроль, логика и покрытие потока данных
- Вы можете смоделировать «реальные» сценарии конечного пользователя
- Выявляет ошибки или дефекты
- Когда тестовые случаи написаны для выполнения теста, работа инженера по тестированию будет организована лучше и упрощена
Почему мы пишем тестовый сценарий?
Вот важные причины для создания сценария тестирования:
- Основной причиной написания тестового сценария является проверка всей функциональности программного приложения.
- Это также поможет вам убедиться, что бизнес-процессы и потоки соответствуют функциональным требованиям.
- Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
- Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
- Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
- Как только эти тестовые сценарии будут завершены, тестовые примеры могут быть легко получены из тестовых сценариев.
Тестовый случай и тестовый сценарий
Здесь есть существенные различия между тестовым сценарием и тестовым набором
| Тестовый сценарий | Прецедент |
|---|---|
| Тестовый сценарий содержит высокоуровневую документацию, в которой описывается сквозная функциональность, подлежащая тестированию. | Контрольные примеры содержат определенные этапы тестирования, данные, ожидаемые результаты для тестирования всех функций приложения. |
| В нем больше внимания уделяется «что проверять», чем «как проверять». | Полный акцент на «что тестировать» и «как тестировать». |
| Тестовые сценарии являются однострочными. Таким образом, всегда есть вероятность неоднозначности во время тестирования. | Контрольные примеры определили шаг, предварительные условия, ожидаемый результат и т. Д. Поэтому в этом процессе нет никакой двусмысленности. |
| Тестовые сценарии получены из тестовых артефактов, таких как BRS, SRS и т. Д. | Контрольный пример в основном получен из тестовых сценариев. Несколько тестовых случаев могут быть получены из одного тестового сценария |
| Это помогает в гибком способе тестирования сквозной функциональности | Помогает в исчерпывающем тестировании приложения |
| Тестовые сценарии – это действия высокого уровня. | Тестовые случаи – действия низкого уровня. |
| Сравнительно меньше времени и ресурсов требуется для создания и тестирования с использованием сценариев. | Для документирования и выполнения контрольных примеров требуется больше ресурсов. |
Лучшие практики создания тестовых случаев
- Тестовые случаи должны быть прозрачными и понятными
- Создайте контрольный пример, помня конечного пользователя
- Избегайте повторения тестовых случаев
- Вам необходимо убедиться, что вы напишете тестовые наборы для проверки всех требований к программному обеспечению, упомянутых в документе спецификации.
- Никогда не принимайте на себя функциональность и возможности вашего программного приложения при подготовке тестового примера.
- Тестовые случаи должны быть легко идентифицируемыми
Лучшие практики создания сценария тестирования
- Тестовые сценарии – это в основном однострочный оператор, который говорит, что следует тестировать
- Описание сценария должно быть простым и легким для понимания
- Тщательная оценка заявленных требований должна быть сделана
- Необходимые инструменты и ресурсы для тестирования должны быть собраны до начала процесса тестирования
КЛЮЧЕВАЯ РАЗНИЦА
- Тестовый набор – это набор действий, выполняемых для проверки определенных функций или функциональности, тогда как сценарий тестирования – это любая функциональность, которую можно протестировать.
- Тестовый набор в основном получен из тестовых сценариев, в то время как тестовые сценарии получены из тестовых артефактов, таких как BRS и SRS.
- Test Case помогает в исчерпывающем тестировании приложения, тогда как Test Scenario помогает в гибком способе тестирования сквозной функциональности.
- Тестовые случаи направлены на то, что тестировать и как тестировать, в то время как тестовый сценарий больше ориентирован на то, что тестировать.
- Тестовые случаи – действия низкого уровня, тогда как тестовые сценарии – действия высокого уровня.
- Test Case требует больше ресурсов и времени для выполнения теста, в то время как Сценарий тестирования требует меньше ресурсов и времени для выполнения теста.
- Тестовый набор включает в себя этапы тестирования, данные, ожидаемые результаты для тестирования, тогда как сценарий тестирования включает в себя сквозную функциональность, подлежащую тестированию.
What does the Test Case entail?
A test case is a set of criteria that a tester uses to verify whether or not a
software application is meeting the customer’s requirements.
Preconditions, case name, input conditions, and intended outcome are all
included in the test case design. A test case is a basic activity that is
derived from test scenarios.
It is a comprehensive document that comprises all potential inputs (both
positive and negative) as well as navigation instructions for the test
execution process. Writing test cases is a one-time effort that may be
reused for regression testing in the future.
The test case contains thorough information about the testing approach,
procedure, preconditions, and expected results. These are used during the
testing phase to see if the software program is capable of executing the
purpose for which it was created.
By associating a defect with a test case ID, test cases assist testers in
defect reporting. The testing team benefits from detailed test case
documentation because if the developer misses something, it may be
detected during the execution of these full-proof test cases.
To construct the test case, we need the requirements to extract the inputs,
as well as the test scenarios to ensure that we don’t overlook any testing
features. Then, to ensure uniformity, we should have a test case template,
or every test engineer should produce the test document in the same way.
Whenever the developer is busy creating code, we will usually write the test
case.
When should a test case be written?
When we have the following information, we will write the test case −
When the customer provides the business requirements, the developer
begins work and estimates that the product will take 3.5 months to
complete.
Meanwhile, the testing group will begin developing the test cases.
It will email it to the Test Lead for evaluation once it is completed.
The product is then turned over to the testing team once the developers
have finished building it.
Because testing is consistent and does not depend on the mood of the
person rather than the quality of the test engineer, test engineers never
glance at the requirement when testing the product document.
What is a Test Scenario, and how does it work?
Any functionality that may be tested is specified as a Test Scenario. It is a
collection of test scenarios that assists the testing team in determining the
project’s positive and negative features.
The Test Scenario provides a high-level overview of what has to be tested.
In liner statements, a test scenario is a complete list containing test cases
that cover the end-to-end functionality of a software program. A scenario is
defined as a linear statement. The test scenario is a categorization of
testable requirements at a high level. These criteria are categorized
according to a module’s functionality and derived from use cases.
Because there are so many test cases in the scenario, there is a thorough
testing process. The tester must evaluate the test cases for each scenario
before completing the test scenario.
Testers must put themselves in the shoes of the user in the test scenario
since they are testing the software application from the user’s perspective.
The most important aspect of the process is scenario preparation, which
necessitates seeking advice or assistance from consumers, stakeholders,
or developers.
Test Scenarios: How to Write Them
-
To build Test Scenarios as a tester, follow these steps
-
Examine the software’s requirement documents, such as the BRS
(Business Requirement Specification), SRS (System Requirement
Specification), and FRS (Functional Requirement Specification). -
For each need, determine all technical factors and objectives.
-
Find every feasible way for the user to interact with the software.
-
Determine all conceivable scenarios in which the system might be
abused, as well as users who could be hackers. -
Make a list of possible test cases to check each function of the
program after reading the requirement document and completing the
planned analysis. -
Create a traceability matrix once you’ve identified all of the available
test scenarios to see if each requirement has a matching test scenario or not. -
All possibilities are reviewed by the project supervisor. They are then
reviewed by the project’s other stakeholders.
Characteristics of the Test Scenario
-
The test scenario is a one-liner that directs testers through the testing
process. -
The product’s complexity and repetition are reduced by using a test
scenario. -
A test scenario is when you speak and think about tests in great
detail yet write them down in linear statements. -
It’s a series of procedures threaded together.
-
When the tester does not have enough time to develop test cases
and the team agrees on a comprehensive liner scenario, the test
scenario becomes more significant. -
The test scenario is a useful exercise for saving time.
-
It is simple to maintain since adding and modifying test cases is
simple and self-contained.
Exercising a Test Scenario
A few test cases for an eCommerce application might be −
-
Scenario 1 − Examine the Search Functions
-
Check the Payments Functionality in Scenario 2
-
Check the Login Functionality in Scenario 3
The Main Difference
-
A test case is a collection of actions that are carried out to check
certain features or functionality, whereas a test scenario is any
capability that may be evaluated. -
Test Scenarios are derived from test artifacts such as BRS and SRS,
whereas Test Cases are derived from test scenarios. -
Test Cases aid in the thorough testing of an application, whereas
Test Scenarios aid in the testing of end-to-end functionality in a more
agile manner. -
Test Cases are more concerned with what to test and how to test,
whereas Test Scenarios are more concerned with what to test. -
Low-level activities are Test Cases, whereas high-level actions are
Test Scenarios. -
Test Cases necessitate more resources and time to execute,
whereas Test Scenarios necessitate fewer resources and time. -
Test Cases include test procedures, data, and anticipated outcomes,
whereas Test Scenarios contain end-to-end functionality to be
evaluated.
Test Cases as an Example
There would be test cases for the Test Scenario: «Check the Login
Functionality.»
-
When a valid email address and password are entered, observe the
system’s reaction. -
When an incorrect email address and a legitimate password are
supplied, observe the system’s behavior. -
When a legitimate email address and an incorrect password are
submitted, observe the system’s behavior. -
Check the system’s response when an incorrect email address and
password are submitted. -
Examine the system’s behavior when the email address and
password are left blank and the Sign-in button is pressed. -
Make sure Forgot your password is working properly.
-
When a valid or incorrect phone number and password are entered,
observe the system’s behavior. -
When «Keep me signed» is selected, observe the system’s actions.
Why do we write Test Cases in the first place?
Here are a few compelling reasons to develop a Test Case
-
Test cases aid in the verification of compliance with relevant
standards, guidelines, and client needs. -
Assists you in validating client expectations and requirements.
-
Control, logic, and data flow coverage have all been improved.
-
You may play around with real end-user scenarios.
-
exposes flaws or faults
-
The test engineer’s job will be more structured and simpler when test
cases are developed for test execution.
What is the purpose of writing a Test Scenario?
The following are some compelling reasons to build a Test Scenario
-
The primary goal of writing a test scenario is to ensure that the
software application’s whole functioning is verified. -
It also aids in ensuring that business processes and flows are in
compliance with functional requirements. -
To guarantee that the Application Under Test is adequately tested,
multiple stakeholders such as Business Analysts, Developers, and
Customers can approve Test Scenarios. It assures that the program
functions properly in the most prevalent scenarios. -
They are useful for determining the testing work effort and, as a
result, creating a proposal for the customer or organizing the
workforce. -
They aid in the identification of the most crucial end-to-end
transactions or the actual use of software programs. -
Test cases may simply be produced from these Test Scenarios once
they’ve been finalized.
What is the difference between a test case and a test scenario?
There are important distinctions between a Test Case and a Test Scenario.
| Test Scenario | Test Case |
|---|---|
| A test scenario is a high-level document that defines the functionality to be tested from beginning to end. |
For evaluating all of an application’s functionality, test cases contain specified test procedures, data, and expected results. |
| It emphasizes «what to test» rather than «how to test.» |
The emphasis is entirely on «what to test» and «how to test.» |
| A one-liner is a test case. As a result, there is always the risk of ambiguity during testing |
A step, pre-requisites, intended outcome, and so on are all described in test cases. As a result, there is no room for misunderstanding in this procedure |
| BRS, SRS, and other test artifacts are used to create test scenarios. |
The majority of test cases are derived from test scenarios. A single Test Scenario might provide several test cases. |
| It aids in the rapid testing of end-to-end functionality. |
It aids in the thorough testing of an application. |
| High-level actions are used in test scenarios. |
Low-level actions are what test cases are. |
| Creating and testing scenarios requires significantly less time and money. |
More resources are required for test case documentation and execution. |
Example of a Test Case
-
Test cases should be clear and easy to understand.
-
Create a test case with the end-user in mind.
-
Repetition of test cases should be avoided.
-
You must ensure that test cases are written to ensure that all
software requirements specified in the specification document are met. -
When creating a test case, never make assumptions about the
functioning and features of your software application. -
The test cases must be easily distinguishable.
Example of a Test Scenario
-
The majority of test cases are single-line statements that specify what
should be tested. -
The scenario description should be straightforward and easy to
comprehend. -
A thorough examination of the specified criteria should be carried out.
-
Before commencing the testing process, gather the necessary tools
and resources.
What does the Test Case entail?
A test case is a set of criteria that a tester uses to verify whether or not a
software application is meeting the customer’s requirements.
Preconditions, case name, input conditions, and intended outcome are all
included in the test case design. A test case is a basic activity that is
derived from test scenarios.
It is a comprehensive document that comprises all potential inputs (both
positive and negative) as well as navigation instructions for the test
execution process. Writing test cases is a one-time effort that may be
reused for regression testing in the future.
The test case contains thorough information about the testing approach,
procedure, preconditions, and expected results. These are used during the
testing phase to see if the software program is capable of executing the
purpose for which it was created.
By associating a defect with a test case ID, test cases assist testers in
defect reporting. The testing team benefits from detailed test case
documentation because if the developer misses something, it may be
detected during the execution of these full-proof test cases.
To construct the test case, we need the requirements to extract the inputs,
as well as the test scenarios to ensure that we don’t overlook any testing
features. Then, to ensure uniformity, we should have a test case template,
or every test engineer should produce the test document in the same way.
Whenever the developer is busy creating code, we will usually write the test
case.
When should a test case be written?
When we have the following information, we will write the test case −
When the customer provides the business requirements, the developer
begins work and estimates that the product will take 3.5 months to
complete.
Meanwhile, the testing group will begin developing the test cases.
It will email it to the Test Lead for evaluation once it is completed.
The product is then turned over to the testing team once the developers
have finished building it.
Because testing is consistent and does not depend on the mood of the
person rather than the quality of the test engineer, test engineers never
glance at the requirement when testing the product document.
What is a Test Scenario, and how does it work?
Any functionality that may be tested is specified as a Test Scenario. It is a
collection of test scenarios that assists the testing team in determining the
project’s positive and negative features.
The Test Scenario provides a high-level overview of what has to be tested.
In liner statements, a test scenario is a complete list containing test cases
that cover the end-to-end functionality of a software program. A scenario is
defined as a linear statement. The test scenario is a categorization of
testable requirements at a high level. These criteria are categorized
according to a module’s functionality and derived from use cases.
Because there are so many test cases in the scenario, there is a thorough
testing process. The tester must evaluate the test cases for each scenario
before completing the test scenario.
Testers must put themselves in the shoes of the user in the test scenario
since they are testing the software application from the user’s perspective.
The most important aspect of the process is scenario preparation, which
necessitates seeking advice or assistance from consumers, stakeholders,
or developers.
Test Scenarios: How to Write Them
-
To build Test Scenarios as a tester, follow these steps
-
Examine the software’s requirement documents, such as the BRS
(Business Requirement Specification), SRS (System Requirement
Specification), and FRS (Functional Requirement Specification). -
For each need, determine all technical factors and objectives.
-
Find every feasible way for the user to interact with the software.
-
Determine all conceivable scenarios in which the system might be
abused, as well as users who could be hackers. -
Make a list of possible test cases to check each function of the
program after reading the requirement document and completing the
planned analysis. -
Create a traceability matrix once you’ve identified all of the available
test scenarios to see if each requirement has a matching test scenario or not. -
All possibilities are reviewed by the project supervisor. They are then
reviewed by the project’s other stakeholders.
Characteristics of the Test Scenario
-
The test scenario is a one-liner that directs testers through the testing
process. -
The product’s complexity and repetition are reduced by using a test
scenario. -
A test scenario is when you speak and think about tests in great
detail yet write them down in linear statements. -
It’s a series of procedures threaded together.
-
When the tester does not have enough time to develop test cases
and the team agrees on a comprehensive liner scenario, the test
scenario becomes more significant. -
The test scenario is a useful exercise for saving time.
-
It is simple to maintain since adding and modifying test cases is
simple and self-contained.
Exercising a Test Scenario
A few test cases for an eCommerce application might be −
-
Scenario 1 − Examine the Search Functions
-
Check the Payments Functionality in Scenario 2
-
Check the Login Functionality in Scenario 3
The Main Difference
-
A test case is a collection of actions that are carried out to check
certain features or functionality, whereas a test scenario is any
capability that may be evaluated. -
Test Scenarios are derived from test artifacts such as BRS and SRS,
whereas Test Cases are derived from test scenarios. -
Test Cases aid in the thorough testing of an application, whereas
Test Scenarios aid in the testing of end-to-end functionality in a more
agile manner. -
Test Cases are more concerned with what to test and how to test,
whereas Test Scenarios are more concerned with what to test. -
Low-level activities are Test Cases, whereas high-level actions are
Test Scenarios. -
Test Cases necessitate more resources and time to execute,
whereas Test Scenarios necessitate fewer resources and time. -
Test Cases include test procedures, data, and anticipated outcomes,
whereas Test Scenarios contain end-to-end functionality to be
evaluated.
Test Cases as an Example
There would be test cases for the Test Scenario: «Check the Login
Functionality.»
-
When a valid email address and password are entered, observe the
system’s reaction. -
When an incorrect email address and a legitimate password are
supplied, observe the system’s behavior. -
When a legitimate email address and an incorrect password are
submitted, observe the system’s behavior. -
Check the system’s response when an incorrect email address and
password are submitted. -
Examine the system’s behavior when the email address and
password are left blank and the Sign-in button is pressed. -
Make sure Forgot your password is working properly.
-
When a valid or incorrect phone number and password are entered,
observe the system’s behavior. -
When «Keep me signed» is selected, observe the system’s actions.
Why do we write Test Cases in the first place?
Here are a few compelling reasons to develop a Test Case
-
Test cases aid in the verification of compliance with relevant
standards, guidelines, and client needs. -
Assists you in validating client expectations and requirements.
-
Control, logic, and data flow coverage have all been improved.
-
You may play around with real end-user scenarios.
-
exposes flaws or faults
-
The test engineer’s job will be more structured and simpler when test
cases are developed for test execution.
What is the purpose of writing a Test Scenario?
The following are some compelling reasons to build a Test Scenario
-
The primary goal of writing a test scenario is to ensure that the
software application’s whole functioning is verified. -
It also aids in ensuring that business processes and flows are in
compliance with functional requirements. -
To guarantee that the Application Under Test is adequately tested,
multiple stakeholders such as Business Analysts, Developers, and
Customers can approve Test Scenarios. It assures that the program
functions properly in the most prevalent scenarios. -
They are useful for determining the testing work effort and, as a
result, creating a proposal for the customer or organizing the
workforce. -
They aid in the identification of the most crucial end-to-end
transactions or the actual use of software programs. -
Test cases may simply be produced from these Test Scenarios once
they’ve been finalized.
What is the difference between a test case and a test scenario?
There are important distinctions between a Test Case and a Test Scenario.
| Test Scenario | Test Case |
|---|---|
| A test scenario is a high-level document that defines the functionality to be tested from beginning to end. |
For evaluating all of an application’s functionality, test cases contain specified test procedures, data, and expected results. |
| It emphasizes «what to test» rather than «how to test.» |
The emphasis is entirely on «what to test» and «how to test.» |
| A one-liner is a test case. As a result, there is always the risk of ambiguity during testing |
A step, pre-requisites, intended outcome, and so on are all described in test cases. As a result, there is no room for misunderstanding in this procedure |
| BRS, SRS, and other test artifacts are used to create test scenarios. |
The majority of test cases are derived from test scenarios. A single Test Scenario might provide several test cases. |
| It aids in the rapid testing of end-to-end functionality. |
It aids in the thorough testing of an application. |
| High-level actions are used in test scenarios. |
Low-level actions are what test cases are. |
| Creating and testing scenarios requires significantly less time and money. |
More resources are required for test case documentation and execution. |
Example of a Test Case
-
Test cases should be clear and easy to understand.
-
Create a test case with the end-user in mind.
-
Repetition of test cases should be avoided.
-
You must ensure that test cases are written to ensure that all
software requirements specified in the specification document are met. -
When creating a test case, never make assumptions about the
functioning and features of your software application. -
The test cases must be easily distinguishable.
Example of a Test Scenario
-
The majority of test cases are single-line statements that specify what
should be tested. -
The scenario description should be straightforward and easy to
comprehend. -
A thorough examination of the specified criteria should be carried out.
-
Before commencing the testing process, gather the necessary tools
and resources.