Панбагон. Sysdate вместо Fly_date в напоминалке

В апреле я лечу в Екатеринбург, на конференцию DUMP — http://dump-conf.ru/.

Вчера купила билеты в S7 Airlines, перепроверила даты, вроде все хорошо...

Упорный бот пытался впарить мне отель через их сайт и отказ не принял. Сегодня он прислал мне «напоминалку», что у меня скоро полет... И поставил дату... Сегодня о_О

Когда-когда мой полет?? Эй, але, он в апреле!

Эй, але, я покупала билеты на апрель! Холодный мороз по коже — а вдруг я ошиблась? Нашла письмо с билетами, нет, все хорошо:

Вот же, 13.04

Значит, просто накосячили в письме. Благо понятно как, раз дата сегодняшняя — то вместо моего реального времени полета вставили SYSDATE. Или там и должно быть sysdate, но письмо должно было быть отправлено в апреле...

Предположим, что письмо генерится на следующий день триггером OneDayAfterBuyTicket. И в нем ошибка, дата сегодняшняя и летим то мы сразу из "откуда" в некий "7". Оформим баг по шаблону:

=============================================================

Sysdate вместо Fly_date в напоминалке OneDayAfterBuyTicket

Шаги для воспроизведения

1. Покупаем билеты в другой город и обратно на любое число кроме "сегодня". Например, Москва — Екатеринбург на 01.03.2017. Отель не берем. 
2. Запускаем триггер OneDayAfterBuyTicket

Результат

Приходит письмо-напоминалка о полете с предложением забронировать отель через наш сайт. Но вместо реальной даты и времени полета видим в письме:

• Сегодняшнюю дату — SYSDATE
• "Куда" в полете указан город 7, см рис "Напоминалка"

Ожидаемый результат

Указана реальная дата отлета из Москвы в Екатеринбург. Потому что именно на эту дату нужен отель, а не на дату возвращения и уж точно не на "сегодня". 

=============================================================

Как выявить такой баг?

Особых усилий не нужно, просто проверяем весь сценарий и альтернативы. Допустим, основной сценарий — пользователь заказал и билеты на самолет, и отель итд. Альтернатива — отель не заказал. Тогда послать ему письмо-напоминалку. Вот когда проверяем эту альтернативу, тогда сразу и обнаруживаем баг. 

А если альтернатива не записана и вообще требований нет — мб стоит их оформить? Хотя бы минимально. Запись в виде варианты использования заставляет задуматься об альтернативах, фактически мы придумываем наши тесты!

См также:

Как составлять вариант использования → он бы помог найти баг!

Шаблон бага → использовался в статье

Шаблон улучшения — Как продумывать свое улучшение с примером, когда это приводит к отказу от постановки задачи.

Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.

PS — добавила пост в общую копилку багов.