Обычно о том, что тестов стало слишком много, задумываются после нескольких релизов, когда регресс превращается в мучение. У меня всё произошло иначе.
Я только получил первые прототипы экранов для новой заявки на нецелевой кредит под залог недвижимости. Это были лишь макеты и схемы, без API, без фронта. Уже тогда стало ясно, что калькулятор кредита будет перегружен параметрами. Поэтому я сразу заложил попарное тестирование в основу новой опции.
Наш продукт позволяет клиентам подавать заявки на нецелевой кредит под залог недвижимости.
Как выглядит экран калькулятора
На первом экране пользователь видит мобильную форму «Кредит под залог недвижимости». Для заполнения доступны поля:
Сумма кредита: вводится вручную, диапазон — от 300 тыс. руб. до 20 млн руб.
Срок кредита: предусмотрены быстрые кнопки (5 лет, 10 лет, 20 лет), а также опция «Другой срок», позволяющая выбрать значение от 1 года до 30 лет с помощью барабана выбора
Недвижимость под залог: необходимо выбрать объект из базы банка или добавить новый адрес недвижимости
Ежемесячный платёж: отображается автоматически после ввода всех параметров
Кнопка «Продолжить» становится активной при корректном заполнении формы.
Почему без попарного тестирования здесь легко «утонуть»? Потому что только на этом экране насчитывается более 100 комбинаций:
Параметр | Варианты |
Сумма | От 300 000 до 20 000 000 руб. |
Срок | 5 лет, 10 лет, 20 лет, «Другой срок» |
Тип клиента | Сотрудник банка, сотрудник дочерней компании, внешний клиент |
Недвижимость | Выбрана, новая, не выбрана |
А теперь умножим это на:
Мобильные платформы
Локали
Нестабильность стендов
Перерасчёт при смене каждого параметра
Как я готовил параметры под pairwise
Параметр | Классы эквивалентности |
Сумма | 300 000 руб., 1 500 000 руб., 20 000 000 руб. |
Срок | 5 лет, 10 лет, 20 лет, «Другой срок» |
Недвижимость | Выбрана, не выбрана |
Тип клиента | Сотрудник банка, сотрудник дочерней компании, внешний клиент |
От типа клиента зависит размер процент��ой ставки для расчёта платежа.
Пример попарного набора для этого экрана:
№ | Сумма | Срок | Недвижимость | Клиент |
1 | 300 000 руб. | 5 лет | Выбрана | Банк |
2 | 300 000 руб. | Другой срок | Не выбрана | Внешний клиент |
3 | 1 500 000 руб. | 10 лет | Выбрана | Дочерняя компания |
4 | 1 500 000 руб. | 20 лет | Не выбрана | Банк |
5 | 20 000 000 руб. | 5 лет | Выбрана | Внешний клиент |
6 | 20 000 000 руб. | Другой срок | Не выбрана | Дочерняя компания |
Тестовый сценарий для интерфейса
Сценарий:
Ввести сумму: 1,5 млн руб.
Выбрать срок: 10 лет
Оставить объект недвижимости выбранным из базы
Тип клиента: внешний
Ожидаемый результат:
Поле «Ежемесячный платёж» обновляется автоматически
Сумма соответствует расчёту по ставке 15%
Кнопка «Продолжить» активна
При изменении срока на 20 лет сумма ежемесячного платежа пересчитывается мгновенно
Сценарий с невыбранной недвижимостью
Шаги:
В поле «Сумма» ввести 300 тыс. руб.
В разделе «Срок» выбрать опцию «Другой срок» и установить значение 30 лет
Очистить поле выбора недвижимости
Указать тип клиента как «Сотрудник банка»
Ожидаемый результат:
Платёж рассчитывается корректно
Форма не блокируется
Кнопка «Продолжить» остаётся активной
Экономия времени на регрессе:
Подход | Калькулятор |
Без pairwise | ~100 сценариев, 2,5 часа |
С pairwise | 6—8 сценариев, ~20 минут |
За квартал только этот экран экономит 20—30 часов чистого времени тестировщика.
На первый взгляд, калькулятор кажется простым. Но именно такие экраны превращают регресс в катастрофу, если не применять тест-дизайн. Попарное тестирование позволяет контролировать сложность ещё на этапе макетов — до того, как появится первая строчка кода.
Для дальнейшей оптимизации процесса тестирования и повышения качества тестового покрытия были приняты следующие меры.
Что мы реально тестируем на этом экране
На скриншоте видно, что калькулятор живёт вокруг четырёх сущностей:
Параметр | Тип |
Сумма кредита | Числовое поле |
Срок кредита | Кнопки + барабан «Другой срок» |
Недвижимость под залог | Выбор из списка с формой ввода внутри |
Ежемесячный платёж | Вычисляемое поле |
1️⃣ Классы эквивалентности
Сумма кредита:
Класс | Примеры |
Валидное | 300 000 руб., 1 500 000 руб., 20 000 000 руб. |
Меньше минимума | 299 999 руб. |
Больше максимума | 20 000 001 руб. |
Невалидное | "", -100, abc |
Срок кредита:
Класс | Примеры |
Валидное | 5 лет, 10 лет, 20 лет, 30 лет |
Меньше минимума | 0 |
Больше максимума | 31 год |
2️⃣ Анализ граничных значений
Поле | Проверки |
Сумма | 299 999 руб., 300 000 руб., 300 001 руб. 19 999 999 руб., 20 000 000 руб., 20 000 001 руб. |
Срок | 0, 1 год, 2 года 29 лет, 30 лет, 31 год |
3️⃣ ��опарное тестирование (ключевая техника)
Параметры |
Сумма |
Срок |
Недвижимость (выбрана, не выбрана) |
Тип клиента |
Даёт около 6—10 тестов вместо 100+, но покрывает все важные пересечения.
4️⃣ Таблица принятия решений
Проверяем, что ставка и платёж считаются корректно.
Тип клиента | Ставка |
Сотрудник банка | 8% |
Сотрудник дочерней компании | 9% |
Внешний клиент | 11% |
5️⃣ Тестирование состояний формы
Состояние | Ожидаемо |
Пустая форма | Платёж не показан |
Введена сумма | Платёж пересчитан |
Сменили срок | Платёж обновился |
Убрали недвижимость | Платёж остался корректным |
6️⃣ Причинно-следственные связи
Причина | Следствие |
Изменили сумму | Платёж пересчитался |
Изменили срок | Платёж пересчитался |
Изменили тип клиента | Изменились ставка и платёж |
Убрали недвижимость | Платёж считается без ошибок |
7️⃣ Исследовательское тестирование
Самые частые баги здесь выявляются при следующих действиях:
Быстрый ввод суммы + переключение сроков
Выбор другого срока
Смену недвижимости после расчёта
Удаление недвижимости после того, как платёж уже появился
8️⃣ Негативные сценарии
Поле | Ошибка |
Сумма | Пусто, буквы, специальные символы |
Срок | 0, 31 год |
Недвижимость | Удалена после расчёта |
Платёж | Не обновился при изменении условий |
Итог
Комбинация «Классы эквивалентности + Границы + Pairwise + Состояния + Исследовательское тестирование» позволяет добиться максимальной плотности багов при минимальном количестве тестов, превращая сложный калькулятор в управляемый объект регресса.
Прямое тестирование без применения специализированных техник и тест-релиза превращает регресс в марафон. На практике это обычно выглядит так:
Проверка минимальной, средней и максимальной суммы
Тестирование всех возможных сроков
Перебор типов клиентов
Отдельное рассмотрение сценариев с выбранной и невыбранной недвижимостью
В результате только на этом экране может накопиться более 100 сценариев. Даже если каждый тест занимает всего полторы минуты, это уже почти три часа работы. И это лишь один экран в мобильном приложении.
Когда же подключаешь обдуманный тест-дизайн, картина кардинально меняется. Попарное тестирование сокращает количество ключевых сценариев до 6—8. Добавьте граничные значения и несколько негативных сценариев — и получится около 20 проверок. А это уже не два часа, а максимум полчаса.
Что это даёт в долгосрочной перспективе? В обычных проектах регресс запускают минимум раз в неделю, у нас — примерно раз в две недели. За квартал это около 12 прогонов. Если на каждом экономить по два часа, то за три месяца вы сэкономите почти три полноценных рабочих дня, которые раньше просто «сгорали» в калькуляторе.
И это мы считаем только один экран.
Учитывая, что опция работает на iOS и Android, время можно умножать на два.
Самое главное, что эти техники можно применять везде. Они помогут командам, в которых нет тестировщиков или тестирование работает неэффективно, улучшить свой продукт.
В какой-то момент приходит осознание: тест-дизайн — это не про красивые таблицы, а про возможность уходить с работы вовремя и спокойно, не переживая о том, что что-то могло быть упущено.