Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты
Привет, Хабр! Меня зовут Сергей, я тестировщик в «Петрович-Тех». В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.
На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.
В статье постараюсь простым языком рассказать о своем опыте работы с техниками тест-дизайна на примере проверки оплат — расскажу, как проверяю интеграционные сервисы и всё, что этого касается.
В известном смысле это основы тестирования, но по моему опыту как раз из-за этого («это база, ну что там может быть такого») о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат — налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы.
Приступим!
О каких техниках тест-дизайна будем говорить
Какие подходы существуют, чем отличаются — освежить в памяти основы можно по статьям от коллег по индустрии по запросу «тест-дизайн» в поиске на Хабре. Например, мне нравится вот такая статья.
В своей работе, в зависимости от требований, я использую и комбинирую следующие техники тест-дизайна:
1. Классы эквивалентности.
2. Граничные значения.
3. Причинно-следственный анализ.
4. Прогнозирование ошибок.
В п.3 речь о составлении так называемых карт влияния — визуализации того, какие события на какие части исследуемой системы воздействуют. По моему опыту особенно полезно делать подобные карты при тестировании изменений на бэкенде, а также при проверке больших систем, когда происходит сразу много изменений в различных местах.
Что использую редко (и на чем не буду подробно останавливаться в статье):
I. Попарное тестирование.
Специфика моих задач такова, что довольно редко появляется потребность в регулярной проверки сервиса с разными входными параметрами — их вариабельность в моих кейсах небольшая, так что обычно мне хватает классов эквивалентности.
Вот если бы нужно было тестировать систему, где может быть много не совпадающих конфигураций входных условий — тогда без «попарки» не обойтись.
II. Диаграмма состояний.
Здесь снова все дело в количестве: кейсов, связанных с состоянием системы (статусы заказа, оплаты) — у меня не так много; для проверки хватает причинно-следственного анализа.
III. Таблица принятия решений.
Использую только тогда, когда появляется объемная задача, затрагивающая множество старых зависимостей или создающая значительное число новых.
Перед началом тестирования: декомпозиция
Итак, давайте потестируем систему оплаты.
Первым делом декомпозируем систему. Здесь дело вкуса: кто-то декомпозицию записывает текстом, другие — рисуют, третьи — держат в голове. Как угодно, главное — ответить на вопрос «Что конкретно нам нужно протестировать?».
Сферическая в вакууме декомпозиция системы оплаты может выглядеть вот так:
Декомпозиция системы оплаты — картинка из xmind
В зависимости от проекта, тут можно менять детали — например, стрелками визуализировать зависимости. Минутка байта: что бы вы добавили, убрали или изменили на этой схеме — напишите в комментариях?
В моем случае уточненная декомпозиция выглядит вот так:
Пример детализации схемы декомпозиции системы оплаты под конкретные задачи
Как сделать хорошую декомпозицию: собираешь в кучу всё, что знаешь о тестируемой системе, делишь на удобные тебе категории, расписываешь известные тебе детали. А дальше корректируешь в процессе работы.
Идеальной декомпозиции мне встречать не доводилось: все учесть крайне сложно, и даже для досконально расписанной детализации появляются неучтенные нюансы — система развивается. На мой взгляд ключевой момент для успеха декомпозиции — твое персональное удобство для работы с информацией.
Тест-дизайн для системы оплаты
После декомпозиции перейдем к тест-дизайну. Давайте пройдёмся по техникам в том порядке, как они были перечислены выше.
(1) Классы эквивалентности
Разобьем тестирование на четыре проверки по типам оплат:
1. Карта + бонусные баллы (программа лояльности Петровича): товар, товар-подарок, услуга платная/бесплатная; возврат полный (когда возвращается сумма за весь заказ целиком).
2. СБП + промокод: товар, товар-подарок, услуга платная/бесплатная; возврат неполный (когда возвращается часть средств за товар или услугу).
3. Кредит: возврат полный.
4. Частями: возврат неполный.
Не будем трогать сценарии с юридическими лицами, это отдельная вселенная. Баллы и промокоды объединим с другими способами оплаты.
Такое разбиение позволит нам покрыть тестами значительную часть системы. Набор вводных данных достаточно большой и сложносоставной, это может спровоцировать ошибки.
С каждой итерацией проверки можно немного менять условия, чтобы избежать так называемого «парадокса пестицида» (если к какой-либо функциональности применять постоянно повторяющийся набор тестов, то эти проверки в скором времени будут неэффективны для нахождения новых дефектов).
(2) Граничные значения
Посмотрим, какие граничные значения бывают в оплатах, на что стоит обратить внимание. В зависимости от услуги или товара у вас могут быть разные виды оплат: подписка, разовый платеж, настраиваемый тариф.
Здесь важно учесть несколько моментов:
1. Стандартные границы оплаты: от минимальной до максимальной суммы.
2. Скидка: от минимума к максимуму (аналогично — корзина).
3. Проверка курса бонусных баллов к реальным деньгам.
В моём случае смотрю курс «баллы — рубль». Пример: 1 балл = 4 рубля.
4. Доступность возможности рассрочки и кредита.
Кейс: рассрочку можно взять при корзине с суммой заказа от 1000 до 5000 рублей, кредит — от 3000 до 70000.
5. Наличие возможности использования баллов.
«Включается для корзины на сумму от 280 рублей».
6. Суммы больше или меньше установленных лимитов.
Эту проверку формально можно было бы перенести в «Прогнозирование ошибок», но тут в «Граничных значениях» мне кажется тоже уместным это рассмотреть.
7. Минимальная и максимальная сумма корзины для использования баллов (бонусов).
Все эти проверки можно разбить на подклассы, что-то объединить, изменить. Например, в рамках нашей декомпозиции можно сделать несколько проверок: набрать корзину на 5000 рублей, применить минимальную скидку, использовать баллы.
(3) Причинно-следственный анализ
Представим себе ситуацию: есть корзина, в ней есть товар, человек создает заказ, оплачивает, получает чек об оплате.
Для большинства пользователей всё это выглядит «вот так просто», но мы с вами понимаем, что имели место сотни, а то и тысяч операций, с хождением данных туда-сюда, с прохождением множества проверок, с обращениями в сторонние интеграционные сервисы и прочими манипуляциями.
Причинно-следственный анализ поможет нам иметь представление, где и на каком этапе у нас создаются и меняются записи, всё ли происходит вовремя и в правильной очередности.
Давайте вглядимся:
1. Есть корзина, в ней есть товар: у корзины есть кэш, он меняется; может жить в базе данных, эластике или логах.
2. Пользователь создает заказ: в результате делаются записи в определенные таблицы базы данных, в CRM-систему и другие места.
3. Человек оплачивает заказ: на нашей стороне меняются и создаются новые записи, происходит обмен информацией между платежными системами, имеет место множество проверок, и в финале заказ либо оплачен, либо нет.
4. Клиент получает чек об оплате: еще одна интеграционная операция с множеством записей — у нас, на стороне банка и в платежной системе.
Вот один из вариантов, как это можно визуализировать:
Схема для причинно-следственного анализа оплаты
На мой взгляд в случае проверки систем оплаты причинно-следственный анализ нужно использовать всегда — очень уж тут много операций и связей, сложно всё держать в голове. А с визуализацией, в случае ошибки, мы быстрее сможем предположить, где и что у нас могло сломаться, сразу будем знать, к чему обращаться и что мы должны посмотреть.
(4) Прогнозирование ошибок
Здесь задача не столько в том, чтобы воспроизвести ошибку, сколько получить правильную реакцию системы и нужную запись в логах о типе и причинах неполадки.
Ситуация: у вас есть оплаченный клиентом заказ, по какой-то причине проведенная оплата потеряла одно из свойств. Например, если вы работали с »1С-Предприятие», там вы могли встретить подобное, когда оплата «распровелась».
Потеря свойства не обязательно имеет серьезные последствия; особенно, если это произошло после оплаты или получения чека. Но что, если пользователь захочет оформить возврат товара? Потеря свойства оплаты в таком случае может усложнить весь процесс.
Как лучше всего работать с прогнозированием ошибок? Серебряная пуля и волшебная таблетка для этого мне не попадались — очень уж сильно могут различаться тестируемые системы.
Ключевое здесь — знать, какие ошибки бывают; как они воспроизводятся; как отображаются в системе и фиксируются. Поговорите об этих вещах с разработчиками.
Какими техниками тест-дизайна я буду пользоваться сегодня?
Для различных техник тест-дизайна «знать» и «уметь» — не одно и то же. Слишком часто я в своём прошлом опыте для той или иной проверки использовал одну, максимум, две из них. Из-за этого может возникнуть упомянутый выше «эффект пестицида»: одни и те же тесты, методы и подходы к проверке создают иллюзию того, что всё работает хорошо, но на самом деле это не так.
Как это победить — использовать больше доступных техник тест-дизайна, применить максимум из них. Задействовав сразу несколько подходов и чередуя их, вы будете иметь более широкий контекст тестирования и в конечном итоге получите возможность добиться большего, чем если постоянно пользоваться одним-двумя вариантами.
Надеюсь, разговор об использовании техник тест-дизайна для проверки систем оплаты пригодится вам — если не на практике, для решения соответствующих задач тестирования, то хотя бы даст лишний раз повод задать себе вопрос «А какими техниками тест-дизайна я буду пользоваться сегодня?».
