Как правильно решать проблемы критичных багов на проекте?

Question

[deadyshk]

Всем привет. Не так давно, скажем на одном "интервью", меня спросили следуюший вопрос.

"Есть некий т.н. сценарий "Saturday morning bug". Допустим, есть небольшой проект, состоящий из нескольких разработчиков и QA, а вы на проекте играете роль Team Leader-a. В пятницу у вас был релиз, а в субботу новый билд на продакшене начали тестировать QA и нашли весьма критичный баг. И вот вы пришли в понедельник на работу и узнали, что после релиза на проде нашли критичный баг. Что делать с этим багом решать вам, "над вами" только заказчик."

Как разработчику в роли Team Leader-a нужно поступить в данной ситуации ?

Answer 1

[Vov Vov]

Я Team-Leader - у нас часто обновления по пятницам :))) Шутка. Давайте примем за условие, что это уже произошло и что нельзя было сработать на упреждение. Просто перед Вами ситуация, ок. Поймём, что критичный баг - этот баг, который блокирует ключевой функционал, т.е. N-пользователей не могут каждую секунду выполнить свою ежедневную работу или N-клиентов не заплатило компании денег. Это так вольные вводные, чтобы страшнее было. Какие решения мы можем принять в данной ситуации? Их всего два: сделать роллбек или пофиксить баг. Принимаю решение о роллбеке, если в milestone-версии критичный баг - это значит, что всю версию надо выкидывать в помойку - он там не единственный, если версия так себе, то фиксим, если это в течение 1-2 часов происходит, если нет, то роллбек. Основная причина таких действий - компания уже потеряла деньги/репутацию и надо выбраться из болота за меньший ценник.

Answer 2

[Олег Гамега]

я не Team Leader, но мне кажется вопрос с подвохом, как вариант ответа я бы не выпустил в релиз билд пока его не оттестировали QA

Comments

[God Emperor]

Это к слову, правильный ответ

[deadyshk]

согласен, в теории все баги должны быть найдены после код-фриза и перед релизом.. в теории..

[deadyshk]

согласен, в теории все баги должны быть найдены после код-фриза и перед релизом.. в теории..

[DevMan]

не стоит воспринимать QA как богов и панацею. баги случаются на продакшене и с офогительным QA поскольку лучший тестер - реальный юзер.

[pi314]

На месте тимлида я бы подал заявление об уходе по причине вопиющего служебного несоответствия... т.к. тестирование, вообще-то, проводится до, а не после, и уж никак не на продакшене.

[ronniezt]

На продакшене можно и нужно тестить (smoke тестирование), но по началу все же надо провести регрессионное тестирование перед выкатыванием на прод.

Answer 3

[Ranwise]

я не Team Leader, но нужно смотреть после обнаружения бага, насколько он критичен
- потери финансов\приватной информации
ну а решения:
- есть ли этот баг в предыдущей версии, если нету то насколько сложно откатить версию и заниматься решением
- оценки времени\затрат на устранения

Answer 4

[Тим]

Если бы в этой ситуации оказался я. Я бы предупредил заказчика, исправил баг, прогнал бы еще раз полностью тестирование и обновил бы прод.

Answer 5

[Дмитрий]

на практике делается откат до последней рабочей версии, параллельно команда пытается понять и пофиксить баг, что бы пофиксить проблему.