понедельник, 1 февраля 2016 г.

Ладно, исправлю, убедила

История из жизни Smile :) 

Делаем новую функцию, все добавили, настроили, проверяем. Я смотрю — в одном из полей склеены два списка, которые выглядят по-разному. Данные берутся из базы, где в одном случае заполнено поле «label», а в другом нет. А в списке лейбл выводится. Ну, допустим, это поле с таймзонами. Тогда на выходе мы получаем что-то похожее:

Вроде список один, а написано по разному...

Пишу об этом внутри задачи на эту нашу новую функцию. Но фишка в том, что раньше этот баг тоже был. Просто раньше этот список был где-то далеко, на «десятой странице оферты, докуда никто не читает», а теперь на видном месте.

Разработчик пишет комментарий — «Это было и раньше, Так что  если менять, то в рамках отдельной задачи и с минорным приоритетом...».


С одной стороны — логично. Задача и правда отдельная, и приоритет вроде небольшой... НО! Сейчас то поле на видном месте, после реализации новой функции. Значит, после выдачи релиза заказчик пойдет его тестировать и увидит эту проблему. И придет к нам с вопросом "Это почему так?". Но зачем ждать этого вопроса, если мы можем это поправить, причем быстро? Просто заполнить лейбл у одного списка по аналогии со вторым.

Написала все это в комменте к задаче. Далее диалог в скайпе:

[9:02:31] тестировщик: ссылка на джиру — что за отмазки
[11:14:05] разработчик: ладно, напишу скриптец для обновления, пристыдила))

Мораль сей басни такова — не бойтесь отстаивать свои баги! Разработчикам только дай шанс не фиксить Smile :)

Но вообще, если уверены — стоит обсудить и попробовать доказать свою точку зрения. Конечно, во время обсуждения может оказаться, но это тоже нормальное развитие событий =)

2 комментария:

  1. а тестировщику самому такое поправить - грешно? :)

    ОтветитьУдалить
    Ответы
    1. нет :)
      но у разработчика в тот момент времени было больше свободного времени

      Удалить