Всем привет!

Сегодня стартуем наш недельный марафон по техникам тест дизайна!

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

Готовы?
Начинаем уже сегодня!

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

Требования и макет формы прилагаются.
И обратите внимание, всё как на настоящем проекте - всё на английском ;)

И если есть вопросы, пишите.

Задание «Таблица решений» (decision table testing)

Примените полученные знания и создайте Таблицу решений для функции «Скидка» в интернет-магазине игр. Эта функция будет выпущена на рождественской распродаже.

Предположим, что в этом игровом магазине действует следующая политика стимулирования продаж:
1. Клиенты, потратившие на покупку игр в прошлом месяце более 200$, имеют право на скидку 10%. Также они могут получить дополнительную скидку 5%, если у них День Рождения через 10 дней или меньше.
2. Клиенты, заказывающие игры на сумму более 400$, имеют право на скидку 20%.
3. Клиенты, расплачивающиеся картой «БестБанк», получают купон на 15$ независимо от суммы заказа.
4. Клиенты, расплачивающиеся картой «БестБанк» и чей заказ на сумму 150$ и выше, получают купон на 30$.
5. Все остальные клиенты получают купон на 5 долларов.

State Transition Diagram task

Создайте диаграмму перехода состояний для следующей системы.

Система «Лучшая химия» предоставляет возможность заказать химию для исследовательских лабораторий крупной компании.
Когда пользователь размещает запрос на новый химикат, система может выполнить запрос либо из запасов химикатов на складе, либо путем размещения заказа у коммерческого поставщика химикатов. Каждый такой запрос пройдет через ряд состояний между моментом его создания и моментом его выполнения или отмены.
Все возможные состояния будут отображены для пользователя в его таблице заказов.
Когда пользователь создает новый запрос, добавляя необходимые химикаты в список заказов, система отображает статус «В подготовке». На этом этапе запрос может быть отменен, или запрашивающая сторона может сохранить частичный запрос для будущего выполнения, не отправляя запрос в систему и не отменяя операцию запроса (статус «Отложено»).
Если пользователь отправляет полностью действительный запрос на химию, то система принимает его в обработку: в таблице заказов отображается статус «Принято».
Запрос должен быть удовлетворен внешним поставщиком, когда покупатель разместил заказ у поставщика. Если все пройдет хорошо, следующий статус перейдет к «Размещено». Если у поставщика не будет химиката в наличии, он уведомит покупателя о том, что он был заказан для будущей поставки.
Если заявка удовлетворена либо химическим складом, либо поставщиком (одно терминальное состояние), ее статус меняется на «Выполнена».
Но также если запрашивающая сторона отменила принятый запрос до того, как он был выполнен, либо покупатель отменил заказ поставщика до того, как он был выполнен, то статус запроса меняется на «Отменён».

Задание: Тестирование с помощью методов, основанных на опыте

В предыдущие дни мы с вами усиленно потрудились, применяя для тестирования разные техники чёрного ящика.
В тоже время не всегда доступны полные требования, на которые эти методы опираются.
Бывает, что и требований хороших на проекте нет, да и мало времени вообще на тестирование, а руководство хочет получить отчёт о качестве приложения.
Что делать в таких ситуациях?
Использовать методы, основанные на опыте!
И это наше любимые исследовательское тестирование прежде всего!
Ведь работа тестировщика включает в себя творчество, полёт фантазии и аналитические способности 😉

Давайте сегодня проверим эти ваши качества 😇

И задание простое - протестировать сайт и найти баги в нём:
https://guru.qahacking.ru/

Найденные дефекты пишите в комментариях 😉

Марафон по техникам тест дизайна: подводим итоги

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

Сегодня в течение дня я буду постить ответы на задания.

Но сначала, конечно, квизы 😇

Готовы проверить себя? 😉

И ответы, советы и рекомендации по заданиям

По порядку ⬇️

Советы и рекомендации по Доменному тестированию

Независимо от того, какую вид документации по тестированию вы выбрали - чек-листы или тест-кейсы, есть несколько правил, которым вы должны следовать.
Прежде всего, помните об основных принципах доменного тестирования: можно объединять положительные проверки, но нельзя объединять отрицательные. Например, возможно проверить разрешённые английские, испанские буквы и знаки препинания в одном тесте, но не стоит пытаться вставить в текстовое поле «Mobile phone» неразрешённые английские буквы длиной более допустимой (>14). Эта ошибка довольно распространена среди новичков.

При создании тестовой документации не пытайтесь проверить все варианты возможных входных значений - это просто невозможно и даже может считаться бесполезным.
Собственно основная идея доменного тестирования - протестировать приложение с помощью минимального количества тестов. И здесь классы эквивалентности будут очень кстати.
Например, возьмем текстовое поле «First name» и разделим возможные входные данные на несколько групп наборов, которые можно считать одинаковыми - разделим домен на поддомены (классы эквивалентности).
Первый класс будет содержать количество допустимых символов 0–4 (<минимальная длина), второй класс будет состоять из 5–25 целых чисел (допустимая длина), третий класс будет содержать количество символов 26–∞.
Поэтому вам нужно создать 3 тест кейса и указать диапазон допустимых значений каждого класса эквивалентности. Помните, в шагах тест кейсов нельзя писать точные значения. Поэтому в тест кейсе мы указываем диапазон, а уже при тестировании выбираем по 1 представителю от каждого класса (пусть будет 2, 12, 45 например).
Если одна проверка в классе эквивалентности обнаруживает дефект, все остальные проверки в том же классе эквивалентности, скорее всего, обнаружат ту же ошибку. Если одна проверка в классе эквивалентности не обнаруживает дефект, то никакие другие проверки в том же классе эквивалентности вряд ли смогут обнаружить дефект. Итак, еще раз - не нужно создавать огромное количество проверок - они, скорее всего, покажут те же результаты, что и эти три.
Еще один важный момент: не забывайте проверять граничные значения. Метод граничных значений фокусируется на границах просто потому, что гораздо больше ошибок возникает на краях определенных входных значений, а не где-то посередине. Обратимся к нашему примеру с текстовым полем «First name». Граничными значениями для этого случая будут 4, 5 и 25, 26. Для проверки этих значений необходимо создать отдельные тест кейсы.

У вас еще есть вопросы? Задайте их в комментариях.