Баги во время гарантийного обслуживания и тестирования
Категории: Практики
Зачем вам уметь классифицировать баги?
Уже пару раз спрашивали про баги в Капсуле, в частности - если баг классифицирован как “низкой” критичности. Означает ли это что мы его можем не исправлять?
Важно разделять процессы: Тестирование и передача, и Гарантийное обслуживание.
Все баги, которые вы нашли во время тестирования и приемки продукта - вы обязаны исправить. Независимо от критичности бага. Это может быть минорный баг, это может быть низкий - неважно. Именно для этого вы проводите этап тестирования, чтобы выявить расхождения между Требованиями и Продуктом в конечном итоге.
Во время Гарантийного периода - вам важно ограничить скоуп услуг, которые вы предоставляете клиенту. Клиент под видом бага может потребовать перекрасить интерфейс, переделать функциональность, потому что она не решает задач, которые были изначально прописаны. На этом этапе вам важно понимать:
- Запрос клиента - это баг или запрос на улучшение?
- Запрос клиента соответствует исходных требованиям?
- Если это расхождение с требованиями - почему это было пропущено во время тестирования?
- Баг, который был найден - причина в продукте или в некорректном использовании продукта (например, Клиент вручную внес изменения в Базу данных, что привело к поломке отображения информации на главной странице)?
- Если это баг - он критичный или минорный? Какова его критичность? Если это опечатка на сайте, которую пропустили на этапе тестирования - то тут можно сказать, что это действительно некритично и продукт может работать дальше.
Выяснив эти детали вы можете дать ответ клиенту - исправляете ли вы его сами, или это будет выполнено за дополнительную плату.
Почему некоторые баги лучше не трогать?
Если вы работаете в студии заказной разработке, то, вероятно, разработчики которые разрабатывали продукт Капсулы работают над другим проектом. Для другого проекта, каждое отвлечение разработчика означает:
- воссоздать контекст - о чем был проект Капсулы?
- Потратить время на поиск бага в продукте, его исправление
- Вероятно, уже может не быть тестовой среды, нужно создать тестовую среду, чтобы протестировать
- Провести тестирование продукта (разработчик мог внести исправления в код, тем самым сломал другую область продукта)
В результате, в экстремальном случае, исправление опечатки на сайте может привести к тому, что серия фич перестанет работать. Поэтому, “дешевле” не трогать продукт в принципе, если он не влияет на функциональность.
Можете ли вы не предлагать гарантийную поддержку продукта?
По закону - вы обязаны предоставить 6 месяцев гарантийного обслуживания продукта. Как и любой продукт, который вы покупаете в магазине.
Все посты написаны мной. Если вам интересно узнать больше, подписывайтесь на мою рассылку о менеджменте. Один-два раза в месяц я пишу статьи о разных аспектах проектного управления или менеджмента в целом. Или вы можете просто написать мне :)