И снова эта sysdate в письме... Сначала S7 Airlines, а через пару дней и Fast VPC туда же! Ну але, ребята! Если не умеете использовать параметры в письме, лучше и не надо...
Так вот, о птичках. Для приложений, которые тестируют на курсе «Техники и инструменты поиска и оформления дефектов», я купила у Fast VPC сервер. За две недели до оплаты мне приходит напомнилка. Зачем — отдельный вопрос, я вроде поставила автоматическую оплату, но не могу понять из интерфейса, включена она или нет. 😒 Но это уже отступление в тему юзабилити, а сегодня мы поговорим о функциональном баге.
Так вот!
Прихожу я, значицца, на работу. И тут такое письмо (сегодня 10.02.2017):
Эээээм, что?
Оплатить до сегодня «исключительно»? То есть максимум вчера? При том, что письмо пришло сегодня в 2 часа ночи?
Пошла в личный кабинет — нет, все норм, еще две недели до оплаты
Значит, точно косяк именно в письме. Вместо параметра ${billing_date} прислали ${sysdate}.
Предположим, что письмо можно отправить вручную, дернув триггер LetterAboutBilling. Оформим баг по шаблону:
**************************************************************
Шаги для воспроизведения
Результат
В письме указана текущая дата (см Дата в письме.jpg):
Дата оплаты: 10/02/2017 (Дата оплаты указывается исключительно, т.е. счет должен быть оплачен непосредственно до этой даты)
Ожидаемый результат
Дата оплаты: 10/03/2017. Потому что именно такую дату мы видим в личном кабинете, см Дата в личном кабинете.jpg
**************************************************************
Письмо-напоминалка → это тоже функционал. И его тоже надо тестировать, особенно, если оно не абстрактное, а с параметрами. Надо проверить, правильно ли отрабатывают эти параметры?
Конечно, нет смысла выставить себе дату следующей оплаты на сегодня и послать письмо — так баг найден не будет. А вот проверить основной сценарий пользователя нужно → что ему придет? А то мало ли, может, мне и ФИО другие добавят и вообще не мой сервер в счете пришлют!
Так вот, о птичках. Для приложений, которые тестируют на курсе «Техники и инструменты поиска и оформления дефектов», я купила у Fast VPC сервер. За две недели до оплаты мне приходит напомнилка. Зачем — отдельный вопрос, я вроде поставила автоматическую оплату, но не могу понять из интерфейса, включена она или нет. 😒 Но это уже отступление в тему юзабилити, а сегодня мы поговорим о функциональном баге.
Так вот!
Прихожу я, значицца, на работу. И тут такое письмо (сегодня 10.02.2017):
В письме вместо нормальной даты
явно подставлена SYSDATE
Эээээм, что?
Оплатить до сегодня «исключительно»? То есть максимум вчера? При том, что письмо пришло сегодня в 2 часа ночи?
Пошла в личный кабинет — нет, все норм, еще две недели до оплаты
До оплаты счета 2 недели
Значит, точно косяк именно в письме. Вместо параметра ${billing_date} прислали ${sysdate}.
Предположим, что письмо можно отправить вручную, дернув триггер LetterAboutBilling. Оформим баг по шаблону:
**************************************************************
В письме-напоминалке вместо даты оплаты счета SYSDATE
Шаги для воспроизведения
- Покупаем сервер — оплачиваем первый счет за сегодняшнюю дату. Следующая оплата — через месяц, 10.03.2017
- Вызываем вручную LetterAboutBilling, чтобы пришло письмо-напоминание
Результат
В письме указана текущая дата (см Дата в письме.jpg):
Дата оплаты: 10/02/2017 (Дата оплаты указывается исключительно, т.е. счет должен быть оплачен непосредственно до этой даты)
Ожидаемый результат
Дата оплаты: 10/03/2017. Потому что именно такую дату мы видим в личном кабинете, см Дата в личном кабинете.jpg
**************************************************************
Письмо-напоминалка → это тоже функционал. И его тоже надо тестировать, особенно, если оно не абстрактное, а с параметрами. Надо проверить, правильно ли отрабатывают эти параметры?
Конечно, нет смысла выставить себе дату следующей оплаты на сегодня и послать письмо — так баг найден не будет. А вот проверить основной сценарий пользователя нужно → что ему придет? А то мало ли, может, мне и ФИО другие добавят и вообще не мой сервер в счете пришлют!
См также:
Как составлять вариант использования → он бы помог найти баг!
Шаблон бага → использовался в статье
Шаблон улучшения — Как продумывать свое улучшение с примером, когда это приводит к отказу от постановки задачи.
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
PS — добавила пост в общую копилку багов.
Комментариев нет:
Отправить комментарий