Создание отчетов и багобаза
#21
Отправлено 24 января 2005 - 08:19
1.В баг-трекере фиксируются все баги.
В крайнем случае, если из-за недостатка требований непонятно, баг это или нет, сначала идет устный разговор с разработчиком, и если найденная проблема - баг, она фиксируется в баг-трекере. У каждой записи о баге есть категория - от критической до несущественной, и срочность исправления.
2.Я сначала заносила мелкие косметические ошибки по несколько штук в одну запись, но потом сами разработчики попросили все баги писать не больше одного на запись.
3.По поводу закрытия ошибок - сразу было сказано, что проверяются на исправление только те ошибки, которые переведены в состояние исправлено. Если состояние другое - значит ошибка не исправлена и я ее не проверяю и не закрываю.
4.Разработчики ошибки в баг-трекер не заносят.
#22
Отправлено 25 января 2005 - 14:26
Пример 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 человеко-часов.
На самом деле результат будет еще хуже.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#23
Отправлено 25 января 2005 - 16:12
На самом деле это болезнь многих небольших компаний, где над проектом работают несколько человек и все могут общаться друг с другом в режиме реального времени. Для них проще все записать в документ типа Excel, чем заниматься возней с базой дефектов.Иногда занесение всех багов в 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 человеко-часов.
На самом деле результат будет еще хуже.
Есть несколько возражений против ведения дел таким образом.
1. Очень легко потерять, забыть, не успеть оформить/исправить/проверить ошибки, записанные на отдельных бумажках.
2. Такие дефекты невозможно учесть в отчете о готовности системы в продакшн.
3. Трудно учитывать активности разработчиков и тестировщиков по недокументированным задачам.
4. Трудно отслеживать статистику наиболее распространенных ошибок с целю выработки единого решения.
Возражения типа, нужно занести 30 однотипных багов, не выдерживают критики.
Во-первых, в любой уважающей себя системе есть функция создания бага на базе уже имеющегося.
Во-вторых, как правило, 30 однотипных багов связаны с одной или несколько систем (компонент) и фиксятся они в одном месте. Так что 30 багов, в реальности, оказываются одним или несколькими дефектами.
#24
Отправлено 25 января 2005 - 19:32
Голос от представителя большой, очень большой компании :)На самом деле это болезнь многих небольших компаний, где над проектом работают несколько человек и все могут общаться друг с другом в режиме реального времени. Для них проще все записать в документ типа Excel, чем заниматься возней с базой дефектов.
Есть несколько возражений против ведения дел таким образом.
Сергей, отчего такие наезды? Почему сразу болезнь? Это не болезнь, это норма для маленьких компаний.
Более того, для них излишняя формализация и бюрократизация -- это болезнь. Что русскому хорошо, то немцу смерть.
Я уже писал, когда мы обсуждали проектный подход, что формализация процессов в большой комании происходит не от хорошей жизни, это условие выживания, цена, которую приходится платить за большой размер.
Неформальные отношения в маленькой проектной компании способствуют более высокой скорости взаимодействия, это нельзя отрицать. И я уже писал, что сейчас в менеджменте появился относительно новый (возможно, просто хорошо забытый старый, не в этом дело) принцип проектных команд, когда для выполнения определённой работы создаётся небольшая команда, которая внутри общается неформально, а с остальными членами организации в соответствии со всеми положенными бюрократическими правилами. Оказывается, такой похдод позволяет решать задачи гораздо более эффективно. И умение в большой компании воспользоваться премуществами маленьких команд -- вот искусство менеждмента.
А осудить всякий может :)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#25
Отправлено 26 января 2005 - 07:45
Полностью согласен, что некоторая бюрократизация процессов в больших компаниях это вопрос жизни или смерти. Так же согласен, что медаль о двух сторонах. В любом можно найти как плюсы так и минусы.Неформальные отношения в маленькой проектной компании способствуют более высокой скорости взаимодействия, это нельзя отрицать. И я уже писал, что сейчас в менеджменте появился относительно новый (возможно, просто хорошо забытый старый, не в этом дело) принцип проектных команд, когда для выполнения определённой работы создаётся небольшая команда, которая внутри общается неформально, а с остальными членами организации в соответствии со всеми положенными бюрократическими правилами. Оказывается, такой похдод позволяет решать задачи гораздо более эффективно. И умение в большой компании воспользоваться премуществами маленьких команд -- вот искусство менеждмента.
Мало того, я на собственном опыте испытал все "прелести" различных подходов к организации процесса и даже полное отсутствие оных. Именно с позиции опыта я и пытаюсь оценивать ситуацию.
Уменьшение бюрократии в команде разработчиков, работающих над одним проектом, это безусловно плюс. Обеими руками за. Но обсуждается немного другая ситуация. В данном случае - это координация работы между службами. Причем, результат работы одной из них виден "не вооруженным взглядом", а второй - нет. Нужен дополнительный механизм, что бы увидеть и оценить работу тестировщиков. Значит без отчетности (подтвержденной документально) никак не обойтись, иначе будут правомерны вопросы типа: "Покажите мне, что вы сделали за отчетный период?"
Если документация необходимо, то что эффективней - иметь один механизм ведения учета или несколько? Очевидно, что один.
Пример.
Обычно пишут только одну инструкцию о том, что выностить в первую очередь во время пожара. Что произойдет, если таких инструкций будет две, три, да еще с вариациями?
Так же очевидно, что не возможно в одном процессе предусмотреть все варианты развития событий. Значит нужно разработать несколько стандартных вариантов единого процесса в зависимости от исходных данных.
Другими словами, баг трекинговая система должна быть одна и все баги должны в нее заноситься. Но при этом возможны варианты полноты описания бага или другие условия. Для каждого они могут быть свои.
#26
Отправлено 26 января 2005 - 07:47
Как я ранее показал, это не всегда оправдано по трудозатратам. Что же касается:
1. Очень легко потерять, забыть, не успеть оформить/исправить/проверить ошибки, записанные на отдельных бумажках.
2. Такие дефекты невозможно учесть в отчете о готовности системы в продакшн.
3. Трудно учитывать активности разработчиков и тестировщиков по недокументированным задачам.
4. Трудно отслеживать статистику наиболее распространенных ошибок с целю выработки единого решения.
Ну и что?
1. Заранее известно, что софт будет поставлен с кучей известных и неисправленных ошибок. И с кучей еще не найденных.
2. А такой отчет и не делается. Т.к. нет человека, который его будет анализировать.
3. Нет человека, который учитывает активности разработчиков и тестировщиков.
4. Нет человека, который отслеживает статистику наиболее распространенных ошибок.
Рассматривалась ситуация характертерная для малых фирм и внутренних отделов разработки, когда готовы простить огромное количестко недоделок, но не простят отставание на день.
Когда Макаренко спрашивали как он поступил бы в той или иной ситуации, он отвечал: "Я не знаю какая у вас была погода".
Можно придумать ситуацию, когда использование BTS совершенно неэффективно и, более того, гарантированно приводит к краху проекта. Но это не значит, что так будет в при любых условиях.
PS. Если вы не можете придумать десяток ситуаций с разной эффективностью BTS и посчитать эти эффективности, то пользуйтесь первым правилом тестера:
BTS необходима. Всегда.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#27
Отправлено 22 февраля 2005 - 11:42
скажем я подхожу к моему программисту, чтоб показать и обсудить найденный баг..
он говорит "без проблем, ща исправим" .. и таки исправляет. Зачем же мне тогда заносить баг(а это куча времени )
+ на этот баг потом будет тратить время разработчик, т.к. сходу может быть и не понятно, то ли это, что он уже исправил или что-то новенькое.. :(
QA manager
#28
Отправлено 22 февраля 2005 - 16:36
Вот для того, чтобы у разработчика было документальное подтверждение на что он тратил время, и имеет смысл заводить баг. Так же как документальное подтверждение того, что вы потратили время на нахождение это бага.+ на этот баг потом будет тратить время разработчик, т.к. сходу может быть и не понятно, то ли это, что он уже исправил или что-то новенькое.. :(
#29
Отправлено 23 февраля 2005 - 09:03
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных