Сегодня публикуем задачу от эксперта Садовского Артема (AQA). Это кейс на риск-ориентированное тестирование, который он разбирает с кандидатами на собеседовании👇

💶Кейс «Автоплатеж» (финтех-сервис)

🔹Контекст:
В веб-версии и мобильном приложении банка разрабатывается функциональность автоплатеж. Пользователь может настроить регулярное автоматическое перечисление фиксированной суммы со своего счета на счет другого клиента этого же банка.

Условия работы функции:
● Периодичность: ежедневно, еженедельно, ежемесячно.
● Дата старта: может быть выбрана начиная с завтрашнего дня.
● Окончание: без срока окончания, по количеству платежей, по дате.
● Списание: списание происходит в 10:00 утра по московскому времени в выбранный день.
● Контроль остатка: если на момент списания на счете отправителя недостаточно средств (сумма автоплатежа + возможная комиссия), списание не производится, и пользователю приходит push/e-mail уведомление о неудаче. Попытка НЕ повторяется на следующий день.
● Редактирование: пользователь может отключить автоплатеж или изменить его параметры (сумму, счет списания, счет зачисления) в любой момент. Изменения вступают в силу для будущих платежей.

🔹Задание:
Вы получили на тестирование эту фичу перед релизом. Опишите свой план тестирования, уделив особое внимание рискам, связанным со временем, деньгами и параллельными операциями.

Вопросы для размышления:
● Какие критические сценарии вы проверите в первую очередь (Smoke-тест)?
● Какие сценарии связаны с изменением времени и даты (таймзоны, перевод часов)?
● Какие проверки нужно сделать, чтобы убедиться в корректности работы при одновременных действиях пользователя (concurrency)?
● Предложите сценарий, связанный с изменением остатка на счете прямо перед списанием.

Подумали над решением? Тогда смотрите ответ👇

● Критические сценарии (Smoke-тест):
— Создание ежемесячного автоплатежа на завтра -> проверка, что завтра в 10:05 деньги ушли со счета и пришли получателю (проверка всей цепочки).
— Создание автоплатежа с суммой, превышающей остаток на счете -> проверка, что в назначенный день списания НЕ произошло, и пользователю пришло уведомление.
— Отключение активного автоплатежа -> проверка, что в следующий запланированный день списания не произошло.
— Проверка граничных значений дат: создание автоплатежа на 29 февраля (високосный год), на 31 число (в месяце 30 дней).

● Сценарии с изменением времени и даты (Time-shift тесты):
— Смена часового пояса пользователем: пользователь улетел в командировку в Нью-Йорк и сменил настройки в профиле. Будет ли автоплатеж срабатывать в 10:00 по его новому местному времени или по-прежнему в 10:00 MSK? (Нужно уточнять у аналитика, но проверить оба варианта).
— Срабатывание в "дыру": платеж настроен на 31 марта, а списание в 10:00. В ночь на 31 марта в некоторых странах переводят часы, и 10:00 может наступить дважды или ни разу.
— Условный "понедельник": проверить, что система правильно определяет день недели. Если сегодня воскресенье, и я ставлю "еженедельно по понедельникам" — первый платеж должен быть завтра.

● Одновременные действия пользователя:
— Редактирование в момент списания: пользователь зашел в 9:59 и начал менять сумму автоплатежа, а в 10:00 сработал джоб. Что произойдет? (Джоб должен либо заблокировать запись, либо взять снэпшот данных на момент старта. Важно, чтобы не списалось по старым реквизитам, а сохранились новые).
— Удаление получателя: пользователь удалил карточку получателя (счет физлица), на которого был настроен автоплатеж. Что будет с автоплатежом завтра в 10:00? (Логично: либо автоплатеж должен деактивироваться, либо система должна выдавать ошибку "Получатель не найден").
— Ручной перевод в момент списания: пользователь в 9:55 вручную перевел последние деньги со счета, оставив там ровно 0. В 10:00 пришел автоплатеж. Успеет ли система обработать блокировку средств?.
— Двойной клик сохранения: при создании автоплатежа пользователь дважды нажал "Сохранить". Создалось два одинаковых автоплатежа? (Бэкенд должен проверять идемпотентность запросов).