Создание отчетов и багобаза

Как у нас:
1.В баг-трекере фиксируются все баги.
В крайнем случае, если из-за недостатка требований непонятно, баг это или нет, сначала идет устный разговор с разработчиком, и если найденная проблема - баг, она фиксируется в баг-трекере. У каждой записи о баге есть категория - от критической до несущественной, и срочность исправления.

2.Я сначала заносила мелкие косметические ошибки по несколько штук в одну запись, но потом сами разработчики попросили все баги писать не больше одного на запись.

3.По поводу закрытия ошибок - сразу было сказано, что проверяются на исправление только те ошибки, которые переведены в состояние исправлено. Если состояние другое - значит ошибка не исправлена и я ее не проверяю и не закрываю.

4.Разработчики ошибки в баг-трекер не заносят.

Иногда занесение всех багов в BTS неэффективно.

Пример 1.
Приложение формирует 30 отчетов. Функционал отлажен, система отправлена клиенту. Клиент наконец сформировал требования по оформлению:
1) Номер документа выделить полужирным.
...
155) Название реквизитов печатать шрифтом 12 пт.

Итак, у нас 30*155= 4650 ошибок (отчеты реализованы через Cristal Report). Будем писать? Нет. В документ "Требования к ПО" переписываем требования, в BTS записываем ОДНУ ошибку "Привести отчеты в соответствие с требованиями".
Когда программист закроет эту ошибку будем последовательно проверять все отчеты и, уже тогда, писать замеченные ошибки.

Здесь мы рассмотрели прием свернуть несколько ошибок в одну.

Пример 2.
Все отчеты работали прекрасно, но в очередной версии часть оформления отьехала (неприятная особенность Cristal Report). Пусть мы имеем в среднем 3 ошибки на отчет.
Самый простой вариант:
1) Распечатать все документы. 30 мин
2) Маркером пометить все ошибки без описания. 30 мин
3) Подойти к программисту и в режиме штурман-водитель исправить весь пакет ошибок. 120 мин
4) Проверить исправления (Повторить 1) и 2).) 60 мин.
Итого 4 часа общего времени и 0,5+0,5+2*2+1=6 человеко-часов
Цифры взяты из реальной практики общения с Cristal Report.

Теперь изменим схему работы.
2) Каждый дефект оформляем как положено либо описывая его либо делая скриншоты. На занесение каждого минимум 3 мин. Это не 30, а 270 мин.
3) Программист будет тратить на исправление каждой ошибки те же примерно 3 мин. (основное время - возня с BTS). 270 мин.
4) Кроме собственно проверки придется возиться с BTS плюс потом проверять не появились ли новые. 30 мин (печать) + 90 мин (проверка ошибок) + 30 мин (не появились ли новые).
Итого: 0,5+4,5+4,5+2=11,5 человеко-часов.
На самом деле результат будет еще хуже.

Иногда занесение всех багов в BTS неэффективно.

Пример 1.
Приложение формирует 30 отчетов. Функционал отлажен, система отправлена клиенту. Клиент наконец сформировал требования по оформлению:
1) Номер документа выделить полужирным.
...
155) Название реквизитов печатать шрифтом 12 пт.

Итак, у нас 30*155= 4650 ошибок (отчеты реализованы через Cristal Report). Будем писать? Нет. В документ "Требования к ПО" переписываем требования, в BTS записываем ОДНУ ошибку "Привести отчеты в соответствие с требованиями".
Когда программист закроет эту ошибку будем последовательно проверять все отчеты и, уже тогда, писать замеченные ошибки.

Здесь мы рассмотрели прием свернуть несколько ошибок в одну.

Пример 2.
Все отчеты работали прекрасно, но в очередной версии часть оформления отьехала (неприятная особенность Cristal Report). Пусть мы имеем в среднем 3 ошибки на отчет.
Самый простой вариант:
1) Распечатать все документы. 30 мин
2) Маркером пометить все ошибки без описания. 30 мин
3) Подойти к программисту и в режиме штурман-водитель исправить весь пакет ошибок. 120 мин
4) Проверить исправления (Повторить 1) и 2).) 60 мин.
Итого 4 часа общего времени и 0,5+0,5+2*2+1=6 человеко-часов
Цифры взяты из реальной практики общения с Cristal Report.

Теперь изменим схему работы.
2) Каждый дефект оформляем как положено либо описывая его либо делая скриншоты. На занесение каждого минимум 3 мин.  Это не 30, а 270 мин.
3) Программист будет тратить на исправление каждой ошибки те же примерно 3 мин. (основное время - возня с BTS). 270 мин.
4) Кроме собственно проверки придется возиться с BTS плюс потом проверять не появились ли новые. 30 мин (печать) + 90 мин (проверка ошибок) + 30 мин (не появились ли новые).
Итого: 0,5+4,5+4,5+2=11,5 человеко-часов.
На самом деле результат будет еще хуже.

На самом деле это болезнь многих небольших компаний, где над проектом работают несколько человек и все могут общаться друг с другом в режиме реального времени. Для них проще все записать в документ типа Excel, чем заниматься возней с базой дефектов.

Есть несколько возражений против ведения дел таким образом.

1. Очень легко потерять, забыть, не успеть оформить/исправить/проверить ошибки, записанные на отдельных бумажках.

2. Такие дефекты невозможно учесть в отчете о готовности системы в продакшн.

3. Трудно учитывать активности разработчиков и тестировщиков по недокументированным задачам.

4. Трудно отслеживать статистику наиболее распространенных ошибок с целю выработки единого решения.

Возражения типа, нужно занести 30 однотипных багов, не выдерживают критики.
Во-первых, в любой уважающей себя системе есть функция создания бага на базе уже имеющегося.
Во-вторых, как правило, 30 однотипных багов связаны с одной или несколько систем (компонент) и фиксятся они в одном месте. Так что 30 багов, в реальности, оказываются одним или несколькими дефектами.

На самом деле это болезнь многих небольших компаний, где над проектом работают несколько человек и все могут общаться друг с другом в режиме реального времени. Для них проще все записать в документ типа Excel, чем заниматься возней с базой дефектов.

Есть несколько возражений против ведения дел таким образом.

Голос от представителя большой, очень большой компании :)

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

Более того, для них излишняя формализация и бюрократизация -- это болезнь. Что русскому хорошо, то немцу смерть.

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

Неформальные отношения в маленькой проектной компании способствуют более высокой скорости взаимодействия, это нельзя отрицать. И я уже писал, что сейчас в менеджменте появился относительно новый (возможно, просто хорошо забытый старый, не в этом дело) принцип проектных команд, когда для выполнения определённой работы создаётся небольшая команда, которая внутри общается неформально, а с остальными членами организации в соответствии со всеми положенными бюрократическими правилами. Оказывается, такой похдод позволяет решать задачи гораздо более эффективно. И умение в большой компании воспользоваться премуществами маленьких команд -- вот искусство менеждмента.

А осудить всякий может :)

Неформальные отношения в маленькой проектной компании способствуют более высокой скорости взаимодействия, это нельзя отрицать. И я уже писал, что сейчас в менеджменте появился относительно новый (возможно, просто хорошо забытый старый, не в этом дело) принцип проектных команд, когда для выполнения определённой работы создаётся небольшая команда, которая внутри общается неформально, а с остальными членами организации в соответствии со всеми положенными бюрократическими правилами. Оказывается, такой похдод позволяет решать задачи гораздо более эффективно. И умение в большой компании воспользоваться премуществами маленьких команд -- вот искусство менеждмента.

Полностью согласен, что некоторая бюрократизация процессов в больших компаниях это вопрос жизни или смерти. Так же согласен, что медаль о двух сторонах. В любом можно найти как плюсы так и минусы.

Мало того, я на собственном опыте испытал все "прелести" различных подходов к организации процесса и даже полное отсутствие оных. Именно с позиции опыта я и пытаюсь оценивать ситуацию.

Уменьшение бюрократии в команде разработчиков, работающих над одним проектом, это безусловно плюс. Обеими руками за. Но обсуждается немного другая ситуация. В данном случае - это координация работы между службами. Причем, результат работы одной из них виден "не вооруженным взглядом", а второй - нет. Нужен дополнительный механизм, что бы увидеть и оценить работу тестировщиков. Значит без отчетности (подтвержденной документально) никак не обойтись, иначе будут правомерны вопросы типа: "Покажите мне, что вы сделали за отчетный период?"

Если документация необходимо, то что эффективней - иметь один механизм ведения учета или несколько? Очевидно, что один.

Пример.
Обычно пишут только одну инструкцию о том, что выностить в первую очередь во время пожара. Что произойдет, если таких инструкций будет две, три, да еще с вариациями?

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

Другими словами, баг трекинговая система должна быть одна и все баги должны в нее заноситься. Но при этом возможны варианты полноты описания бага или другие условия. Для каждого они могут быть свои.

Вопрос изначально стоял: "Все ли баги надо заносить в BTS?" Каюсь, я отвечал на несколько другой вопрос: "Надо ли при любых условиях заносить все баги в BTS?" Мой ответ: "Нет, не всегда".

Как я ранее показал, это не всегда оправдано по трудозатратам. Что же касается:

1. Очень легко потерять, забыть, не успеть оформить/исправить/проверить ошибки, записанные на отдельных бумажках.

2. Такие дефекты невозможно учесть в отчете о готовности системы в продакшн.

3. Трудно учитывать активности разработчиков и тестировщиков по недокументированным задачам.

4. Трудно отслеживать статистику наиболее распространенных ошибок с целю выработки единого решения.

Ну и что?
1. Заранее известно, что софт будет поставлен с кучей известных и неисправленных ошибок. И с кучей еще не найденных.
2. А такой отчет и не делается. Т.к. нет человека, который его будет анализировать.
3. Нет человека, который учитывает активности разработчиков и тестировщиков.
4. Нет человека, который отслеживает статистику наиболее распространенных ошибок.

Рассматривалась ситуация характертерная для малых фирм и внутренних отделов разработки, когда готовы простить огромное количестко недоделок, но не простят отставание на день.
Когда Макаренко спрашивали как он поступил бы в той или иной ситуации, он отвечал: "Я не знаю какая у вас была погода".

Можно придумать ситуацию, когда использование BTS совершенно неэффективно и, более того, гарантированно приводит к краху проекта. Но это не значит, что так будет в при любых условиях.

PS. Если вы не можете придумать десяток ситуаций с разной эффективностью BTS и посчитать эти эффективности, то пользуйтесь первым правилом тестера:
BTS необходима. Всегда.

думаю, заносить или не заносить баг, тестеровщик определяет по ситауции.
скажем я подхожу к моему программисту, чтоб показать и обсудить найденный баг..
он говорит "без проблем, ща исправим" .. и таки исправляет. Зачем же мне тогда заносить баг(а это куча времени )
+ на этот баг потом будет тратить время разработчик, т.к. сходу может быть и не понятно, то ли это, что он уже исправил или что-то новенькое.. :(

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

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

Еще один существующий вариант работы: все баги заносятся в BTS. Когда баг только появляется, ему назначется некая severity, которая характеризует business standpoint. Исходя из этого, грамматическая ошибка в about будет иметь critical severity -- нельзя допустить , чтобы у пользователя, использующий наш продукт, сложилось негативное мнение о компании. Далее, дефект назначается на Development Team. Team Lead смотрит на дефект и назначет его программисту с некоторым приоритетом, который характеризует лишь очередность выполнения задачи. Назначенный программист получает дефект с очередностью выполнения, исправляет его и ставит резолюцию (Fixed, Functions as Designed etc). Дефект приходит назад к верифайеру, который проверяет, что дефект исправлен и либо закрывает его, либо режектит.