четверг, 2 февраля 2017 г.

Панбагон. 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 — добавила пост в общую копилку багов. 

Комментариев нет:

Отправить комментарий