История из жизни 
Делаем новую функцию, все добавили, настроили, проверяем. Я смотрю — в одном из полей склеены два списка, которые выглядят по-разному. Данные берутся из базы, где в одном случае заполнено поле «label», а в другом нет. А в списке лейбл выводится. Ну, допустим, это поле с таймзонами. Тогда на выходе мы получаем что-то похожее:
Пишу об этом внутри задачи на эту нашу новую функцию. Но фишка в том, что раньше этот баг тоже был. Просто раньше этот список был где-то далеко, на «десятой странице оферты, докуда никто не читает», а теперь на видном месте.
Разработчик пишет комментарий — «Это было и раньше, Так что если менять, то в рамках отдельной задачи и с минорным приоритетом...».
С одной стороны — логично. Задача и правда отдельная, и приоритет вроде небольшой... НО! Сейчас то поле на видном месте, после реализации новой функции. Значит, после выдачи релиза заказчик пойдет его тестировать и увидит эту проблему. И придет к нам с вопросом "Это почему так?". Но зачем ждать этого вопроса, если мы можем это поправить, причем быстро? Просто заполнить лейбл у одного списка по аналогии со вторым.
Написала все это в комменте к задаче. Далее диалог в скайпе:
[9:02:31] тестировщик: ссылка на джиру — что за отмазки
[11:14:05] разработчик: ладно, напишу скриптец для обновления, пристыдила))
Мораль сей басни такова — не бойтесь отстаивать свои баги! Разработчикам только дай шанс не фиксить
Но вообще, если уверены — стоит обсудить и попробовать доказать свою точку зрения. Конечно, во время обсуждения может оказаться, но это тоже нормальное развитие событий =)
Делаем новую функцию, все добавили, настроили, проверяем. Я смотрю — в одном из полей склеены два списка, которые выглядят по-разному. Данные берутся из базы, где в одном случае заполнено поле «label», а в другом нет. А в списке лейбл выводится. Ну, допустим, это поле с таймзонами. Тогда на выходе мы получаем что-то похожее:
Вроде список один, а написано по разному...
Пишу об этом внутри задачи на эту нашу новую функцию. Но фишка в том, что раньше этот баг тоже был. Просто раньше этот список был где-то далеко, на «десятой странице оферты, докуда никто не читает», а теперь на видном месте.
Разработчик пишет комментарий — «Это было и раньше, Так что если менять, то в рамках отдельной задачи и с минорным приоритетом...».
С одной стороны — логично. Задача и правда отдельная, и приоритет вроде небольшой... НО! Сейчас то поле на видном месте, после реализации новой функции. Значит, после выдачи релиза заказчик пойдет его тестировать и увидит эту проблему. И придет к нам с вопросом "Это почему так?". Но зачем ждать этого вопроса, если мы можем это поправить, причем быстро? Просто заполнить лейбл у одного списка по аналогии со вторым.
Написала все это в комменте к задаче. Далее диалог в скайпе:
[9:02:31] тестировщик: ссылка на джиру — что за отмазки
[11:14:05] разработчик: ладно, напишу скриптец для обновления, пристыдила))
Мораль сей басни такова — не бойтесь отстаивать свои баги! Разработчикам только дай шанс не фиксить
Но вообще, если уверены — стоит обсудить и попробовать доказать свою точку зрения. Конечно, во время обсуждения может оказаться, но это тоже нормальное развитие событий =)
а тестировщику самому такое поправить - грешно? :)
ОтветитьУдалитьнет :)
Удалитьно у разработчика в тот момент времени было больше свободного времени