3 (Операционные системы) × 3 (Браузеры) × 3 (Языки) = 27 тестов.
Попарное тестирование дает высокую вероятность того, что при правильной комбинации данных качество проверок не пострадает. Для этого нужно, чтобы каждая пара значений была проверена хотя бы один раз. В таком случае результатом будут 9 тестов, представленные ниже.
4.8.4. Техника таблицы принятия решений
В примере попарного тестирования система имела только один ожидаемый результат поведения: форма работает корректно. Однако отклик системы нередко имеет множество вариантов, которые зависят от самых разных факторов, и при тестировании сложного функционала есть вероятность упустить один из результатов корректной работы приложения. Техника таблицы принятия решений переиспользует технику парного тестирования и расширяет ее описанием того, какой отклик системы ожидается. Цель техники — акцентироваться на результате работы системы, ее задача — визуализировать, систематизировать и не упустить все отклики системы при различных наборах данных.
Пример
Вам необходимо протестировать работу системы скидок в магазине. Она принимает только два параметра, каждый из которых имеет несколько вариантов:
— Тип аккаунта пользователя: стандартный аккаунт, Премиум аккаунт.
— Итоговая сумма покупки пользователя: сумма покупки ниже 500$, сумма покупки от 500$.
После применения попарного тестирования таблица будет такой:
После применения техники таблицы принятия решения:
4.8.5. Техника состояний и переходов
Эта техника призвана визуализировать и делать акцент на состояниях с переходами между ними в приложении (если такие есть). Она необходима, чтобы эффективнее тестировать сложные системы, не забывая обо всех их частях. Примерами такой системы могут быть состояния заказанного товара на маркетплейсе или состояния заявки на открытие банковского счета.
Пример
Рассмотрим систему управления доступом, которая позволяет попадать в здание при успешном сканировании допустимого идентификатора (сканирование ID карты или ввода кода доступа) и блокирует вход при неудачной попытке. Система может находиться в различных состояниях, в зависимости от операций пользователя и её внутренних событий.
Состояния:
— Ожидание: система находится в покое и ожидает от пользователя ввода ID карты.
— Аутентификация: система получила ID и проверяет его на предмет подлинности и достаточности уровня прав доступа.
— Доступ разрешен: система закончила проверку ID и разрешает пользователю вход.
— Доступ запрещен: система закончила проверку ID и отказала пользователю в возможности входа.
— Блокировка: система временно заблокирована после трёх подряд неудачных попыток ввода.
Визуализация состояний ниже
Чтобы система начала менять свои состояния, необходимо совершать с ней определенные действия (переходы), либо же она должна выполнять их сама.
Переходы:
— Ожидание —> Аутентификация: при вводе ID и отправке его в систему.
— Аутентификация —> Доступ разрешён: если ID успешно прошел проверку системой.
— Аутентификация —> Доступ запрещён: если ID прошел проверку системой неуспешно.
— Доступ разрешён —> Ожидание: после успешного входа.
— Доступ запрещён —> Ожидание: после отклонения доступа.
— Доступ запрещён —> Блокировка: если число неудачных попыток превышает допустимый лимит.
— Блокировка —> Ожидание: после истечения времени блокировки.
Визуализация состояний с переходами ниже
Тестовые случаи, которые можно создать:
Тест ожидания ввода:
Тест использования допустимого ID:
Тест использования недопустимого ID:
Тест неудачных попыток ввода:
Тест разблокировки системы:
Тест повторного доступа после успешного входа:
Как вы могли заметить, техники тест-дизайна очень тесно связаны и позволяют всесторонне сократить количество тестовых проверок, при этом статистически не ухудшая их качество. И несмотря на то, что существует небольшая вероятность упустить ошибку из — за использования значительно меньшего количества проверок, эти техники уже много лет крайне эффективны и более чем оправдывают такой небольшой риск.
4.9. Ошибка, дефект и сбой
Обычно любое зарегистрированное несоответствие между ожидаемым и фактическим поведением системы называют “Баг”. То есть, место в коде, которое работает некорректно, называют “Баг” и сам Bug Report называют “Баг”. Качественное понимание того, как возникают “Баги” и где их можно ожидать, помогает находить эти самые несоответствия более качественно.
Ошибка обычно относится к проблеме в исходном коде, созданной программистом или любыми другими членами команды, участвующими в разработке требований или их реализации. Это может быть логическая ошибка, опечатка, неправильное использование API или любая другая проблема, приводящая к некорректному поведению программы. Ошибка указывает на расхождение между ожидаемым и фактическим поведением программы.
Примеры
— Программист случайно использует при сравнении значений оператор «>» вместо «>=», что приводит к непредвиденным результатам операции.
— Системный аналитик неверно понял требование заказчика к системе и создал такой алгоритм расчета цены на товар в магазине, работа которого приводит к погрешностям в вычислениях.
Дефект — это формально зарегистрированная проблема, обнаруженная в программном продукте, которая указывает на то, что программа не соответствует своим спецификациям или требованиям. Дефекты возникают, когда зарегистрированные результаты работы программы не соответствуют ожиданиям или когда в программе обнаруживают ошибку, влияющую на ее функциональность.
Примеры
— Функция калькулятора, которая должна складывать два числа, выдаёт неверный результат при сложении больших чисел из — за ошибки в коде.
— При заполнении формы регистрации, в систему не отправляются данные домашнего адреса пользователя, хотя для него все выглядит так, будто данные отправлены полностью.
Сбой — это событие, при котором система не выполняет одну или несколько заявленных функций. Сбой происходит, когда программное обеспечение перестает правильно функционировать из — за одного или нескольких дефектов. Сбои видны конечным пользователям и могут привести к потере данных, нарушению работы системы или другим критическим последствиям.
Примеры
— Веб — сайт выдает ошибку сервера и перестает обрабатывать запросы пользователей из — за дефекта, влияющего на этот процесс.
— Нельзя нажать на кнопку выхода из системы из-за дефекта в коде, который отрисовывает кнопку под другим элементом на веб-странице, то есть кнопка есть, но ее не видно.
Коротко, в чем разница?
— Ошибка — это неправильное действие или решение человека (не обязательно разработчика) на этапе разработки, которое потенциально может привести к дефекту.
— Дефект — это обнаруженный недостаток в программном продукте, который указывает на расхождение между фактическим и ожидаемым поведением программы.
— Сбой — это ситуация, когда из — за одного или нескольких дефектов программное обеспечение не выполняет требуемую функцию, видимую конечному пользователю.
4.10. Приоритетность и критичность
