Откуда берутся баги?

Это жутко интересный вопрос, волнующий всю братию айтишников.


- Ошибки программистов

Программисты тоже люди, а людям свойственно ошибаться

- Изменения требований

Заказчик не всегда понимает, как те или иные изменения отразятся на программном продукте. Хотя он может это и понимать, но все равно настаивать на изменениях - переделки дизайна, смена разработчиков, добавление функционала и т. д.

Любые мелкие или крупные изменения требований влекут за собой новые баги, и нужны огромные усилия для сохранения целостности проекта после любых изменений.

В этих случаях менеджеры проекта должны понимать результирующие риски и тестировщки
должны адаптировать тест-план для интенсивного тестирования.

- Проблема времени

Не всегда время на проекты планируется правильно. Иногда все самое важное делается в последний момент. Когда на носу дедлайн и времени совсем нет - тогда и появляются баги.

- Элементарная нехватка коммуникаций

Программисты не поняли как правильно сделать, а не уточнили. Тестировщики подумали что программисты сделали правильно. Заказчик увидел и испугался. Этого бы ничего не было при правильной наладке процесса коммуникаций заказчик-менеджер-разрабочик-тестировщик.

Что любят говорить разработчики?

- Здесь нет ошибки. Винды у вас кривые.
- Это сделать раз плюнуть
- Да я за часик это все исправлю, а вы раздули глобальную проблему
- Проще будет обновить старый код...

Вместо...

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

Наша задача не только найти баг, но и правильно его описать. Как правильно описать баг?

Зачем нужен хороший баг репорт?

Если вы правильно описали баг, шансы на то, что его профиксят взлетают
до немереных высот. Поэтому существует зависимость от описания бага с исходным результатом (пофиксят или отложат до лучших времен). Чтобы правильно описать баг нужны определенные навыки и знания. Я постараюсь поведать вам это таинство.

"Цель описания бага в том, чтобы его профиксили" - Сэм Канер.

Если тестировщик некорректно опишет баг, то программист с большой вероятностью влепит ему статус "не воспроизводим" и пока-пока. Баг возвращается тестировщику и он опять должен его описывать - но уже более подробно. Цепочка может быть бесконечной, пока программист не даст щелбан тестировщику. А баг пойдет в релиз.

Где же критерии идеального баг репорта???

Каждый может описать баг. Но далеко не каждый может его описать эффективно. Вы должно тонко чувствовать разницу между обычным сереньким баг репортом и действительно хорошим баг репортом.

А как же это почувствовать? Седьмым чувством? Не обязательно, есть критерии, которым должен соответствовать хороший баг репорт.


1) Каждому багу - личный номерок

У каждого бага должен быть свой уникальный номер. Это поможет его отыскать и идентифицировать. Если вы используете какой-то инструмент для автоматизированного репорта багов - этот номер должен генерится автоматически, когда вы заносите баг.

Кто такая Багзилла (BugZilla)? Все не так страшно.

Багзилла (BugZilla) - это система управления багами (широко применяется как система менеджмента проектов и управления задачами).

Системы багтрекинга позволяют разработчику или группе разработчиков эффективно отслеживать задачи и проблемы разрабатываемого продукта.

Багзилла заменила недоразвитую и неудобною систему багтрекинга, которая использовалась в Netscape Communications. Сейчас большинство коммерческих систем багтрекинга требуют кучу лицензий, и Багзилла быстро стала любимицей из толпы систем с открытым кодом. Багзилла является сейчас стандартом де-факто для систем отслеживания ошибок.

А что ж в ней такого?

- мощный поиск

- возможность конфигурирования нотификаций о любых изменениях статусов багов

- полная история изменений для любой задачи/бага

- система зависимости багов

- отличное управление аттачами

- надежный и стабильный RDBMS бек енд

- мощная способность к изменению конфигурации

Официальный сайт - http://www.bugzilla.org/