грязная посуда

ГЛЕБ ДЕЙКАЛО

Спецвыпуск: Хакер, номер #073, стр. 073-020-5

Первый уровень систематизации багов – это проекты (сайты). Вполне логично отделять баги одного сайта от багов другого сайта. К проекту «привязаны» баги, которые имеют еще несколько уровней систематизации. На них остановимся подробнее.

Статус бага дает представление о том, какие меры по исправлению были приняты. При добавлении бага его статус определяется как «новый». Разработчик исправляет баг и определяет его статус как «решен». После этого тестировщик проверяет, действительно ли решен баг. И если баг решен, определяет его статус как «закрыт».

Категория бага – очень важное свойство для оптимизации трудозатрат. Для каждого проекта тестировщик может задать произвольный набор Категорий. Чаще всего используются:

- ПРОГРАММИРОВАНИЕ

- ВЕРСТКА

- ДИЗАЙН (В ОСНОВНОМ БАГИ О НЕСООТВЕТСТВИИ ДИЗАЙН-МАКЕТОВ ТЗ)

- FLASH (ВСЕ, ЧТО КАСАЕТСЯ FLASH-РОЛИКОВ)

- КОНТЕНТ (ВСЕ, ЧТО КАСАЕТСЯ ДИНАМИЧЕСКОГО КОНТЕНТА: ОПЕЧАТКИ, ОРФОГРАФИЧЕСКИЕ, СТИЛИСТИЧЕСКИЕ ОШИБКИ И Т.П.)

- ПРАВКА ТЗ (ОШИБКИ В ТЗ)

- ВОПРОС (ВОПРОСЫ К ПРОДЮСЕРУ ПРОЕКТА)

- НЕ БАГ (В ЭТУ КАТЕГОРИЮ ПОПАДАЮТ «ПАМЯТКИ» И ПРЕДЛОЖЕНИЯ ОПТИМИЗАЦИИ)

Правильно определенная категория бага значительно сокращает время на «поиск крайнего», но это не такая простая задача, как кажется на первый взгляд. Категории «Flash», «Контент», «Правка ТЗ», «Вопрос» и «Не баг» определяются без проблем. В категорию «Дизайн» баги, как правило, переходят из категории «Верстка». Трудности возникают при выборе между «Программированием» и «Версткой». Дело в том, что программист должен корректно вывести данные, а верстальщик – оформить их.

Пример 1: Новости должны выводиться в хронологическом порядке, но они выводятся хаотично – явный баг программирования.

Пример 2: Заголовок новости должен быть выделен жирным шрифтом, а он выделен курсивом – явный баг верстки.

Пример 3: Для новостей должен выводиться анонс, но он не выводится. Возможно, программист забыл вывести анонс, а возможно, верстальщик неправильно его оформил и вследствие ошибки на уровне HTML анонс не отображается.

И если ошибиться с категорией, то разработчик потратит некоторое время на поиски несуществующей ошибки. А теперь умножь «некоторое время» на количество багов... Вывод очевиден.

Баг-трекер Mantis также позволяет добавлять комментарии к багам (что бывает весьма полезно), назначать баги конкретным разработчикам (что бывает полезно при работе в группе), следить за багами (получать уведомления обо всех изменениях бага, что полезно для продюсеров).

[типичные багги.]

Для начала немного статистики. Независимые статистические исследования в компании DEFA Gruppe выявили несколько интересных фактов:

1 ОТНОШЕНИЕ КОЛИЧЕСТВА БАГОВ КО ВРЕМЕНИ, ЗАТРАЧЕННОМУ НА РАЗРАБОТКУ САЙТА, У ПРОГРАММИСТОВ И ВЕРСТАЛЬЩИКОВ СОВПАДАЕТ ДО СОТЫХ! ТО ЕСТЬ ВЕРСТАЛЬЩИКИ И ПРОГРАММИСТЫ «ПЛОДЯТ» БАГИ С ОДИНАКОВОЙ СКОРОСТЬЮ.

2 КОЛИЧЕСТВО БАГОВ ПО ОДНОМУ ПРОЕКТУ ПРЯМО ПРОПОРЦИОНАЛЬНО ОБЪЕМУ РАБОТ ПО ЭТОМУ ПРОЕКТУ, А ОТНЮДЬ НЕ СЛОЖНОСТИ РАБОТ.

3 У КАЖДОГО ТРЕТЬЕГО БАГА С КАТЕГОРИЕЙ «ПРОГРАММИРОВАНИЕ» ИЛИ «ВЕРСТКА» КАТЕГОРИЯ МЕНЯЛАСЬ.