Home

Автор: Герасимов Сергей Сергеевич, Петрович-Тех, блог компании

 Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

В известном смысле это основы тестирования, но по моему опыту как раз из-за этого (“это база, ну что там может быть такого”) о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат – налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы. 

Приступим!

О каких техниках тест-дизайна будем говорить 

Какие подходы существуют, чем отличаются – освежить в памяти основы можно по статьям от коллег по индустрии по запросу “тест-дизайн” в поиске на Хабре. Например, мне нравится вот такая статья. 

В своей работе, в зависимости от требований, я использую и комбинирую следующие техники тест-дизайна:

1. Классы эквивалентности.

2. Граничные значения.

3. Причинно-следственный анализ. 

4. Прогнозирование ошибок.

В п.3 речь о составлении так называемых карт влияния – визуализации того, какие события на какие части исследуемой системы воздействуют. По моему опыту особенно полезно делать подобные карты при тестировании изменений на бэкенде, а также при проверке больших систем, когда происходит сразу много изменений в различных местах.

Что использую редко (и на чем не буду подробно останавливаться в статье):

I. Попарное тестирование. 

Специфика моих задач такова, что довольно редко появляется потребность в регулярной проверки сервиса с разными входными параметрами – их вариабельность в моих кейсах небольшая, так что обычно мне хватает классов эквивалентности. 

Вот если бы нужно было тестировать систему, где может быть много не совпадающих конфигураций входных условий – тогда без “попарки” не обойтись.

II. Диаграмма состояний. 

Здесь снова все дело в количестве: кейсов, связанных с состоянием системы (статусы заказа, оплаты) – у меня не так много; для проверки хватает причинно-следственного анализа.

III. Таблица принятия решений. 

Использую только тогда, когда появляется объемная задача, затрагивающая множество старых зависимостей или создающая значительное число новых.

Перед началом тестирования: декомпозиция

Итак, давайте потестируем систему оплаты.

Первым делом декомпозируем систему. Здесь дело вкуса: кто-то декомпозицию записывает текстом, другие – рисуют, третьи – держат в голове. Как угодно, главное – ответить на вопрос “Что конкретно нам нужно протестировать?”.

Сферическая в вакууме декомпозиция системы оплаты может выглядеть вот так:

В зависимости от проекта, тут можно менять детали – например, стрелками визуализировать зависимости. Минутка байта: что бы вы добавили, убрали или изменили на этой схеме – напишите в комментариях?

В моем случае уточненная декомпозиция выглядит вот так:

Как сделать хорошую декомпозицию: собираешь в кучу всё, что знаешь о тестируемой системе, делишь на удобные тебе категории, расписываешь известные тебе детали. А дальше корректируешь в процессе работы. 

Идеальной декомпозиции мне встречать не доводилось: все учесть крайне сложно, и даже для досконально расписанной детализации появляются неучтенные нюансы – система развивается. На мой взгляд ключевой момент для успеха декомпозиции – твое персональное удобство для работы с информацией.  

Тест-дизайн для системы оплаты 

После декомпозиции перейдем к тест-дизайну. Давайте пройдёмся по техникам в том порядке, как они были перечислены выше. 

(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С-Предприятие”, там вы могли встретить подобное, когда оплата “распровелась”. 

Потеря свойства не обязательно имеет серьезные последствия; особенно, если это произошло после оплаты или получения чека. Но что, если пользователь захочет оформить возврат товара? Потеря свойства оплаты в таком случае может усложнить весь процесс.

Как лучше всего работать с прогнозированием ошибок? Серебряная пуля и волшебная таблетка для этого мне не попадались – очень уж сильно могут различаться тестируемые системы.

Ключевое здесь – знать, какие ошибки бывают; как они воспроизводятся; как отображаются в системе и фиксируются. Поговорите об этих вещах с разработчиками. 

Какими техниками тест-дизайна я буду пользоваться сегодня? 

Для различных техник тест-дизайна “знать” и “уметь” – не одно и то же. Слишком часто я в своём прошлом опыте для той или иной проверки использовал одну, максимум, две из них. Из-за этого может возникнуть упомянутый выше “эффект пестицида”: одни и те же тесты, методы и подходы к проверке создают иллюзию того, что всё работает хорошо, но на самом деле это не так.

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

Надеюсь, разговор об использовании техник тест-дизайна для проверки систем оплаты пригодится вам – если не на практике, для решения соответствующих задач тестирования, то хотя бы даст лишний раз повод задать себе вопрос “А какими техниками тест-дизайна я буду пользоваться сегодня?”.

Обсудить в форуме