Когда создавать баг репорт?

Как принято.
Популярный ответ на этот вопрос прост и лаконичен: "сразу же, как только обнаружил баг". Причём, аргументация такого подхода выглядит как "куй железо пока горячо" или "так принято". Но вот многострадальный лоб, в очередной раз столкнувшись с великими граблями реальности заставляет пересмотреть данное утверждение.

Почему не стоит так поступать.
При использовании выше обозначенного подхода приходится сталкиваться со следующими сложностями:
1. Замедление процесса тестирования. Когда прогоняешь тест-кейсы или проходишь по чек-листам, вообщем активно тестируешь приложение, у тебя всё настроено именно под этот процесс, даже мозг активно работает в ключе тестирования. Перерыв после каждого бага для создания репорта сильно отвлекает от процесса, мешает сосредоточиться и в конечном итоге сильно растягивает процесс.
2. Видна лишь часть проблемы. Баг, в классическом понимании - это не соответствие ожидаемого результата и полученного. На практике же часто можно видеть лишь следы деятельности бага и вместо описания оного наделать множество репортов о его следах. Хорошо, если программист окажется добросовестным и докопается до сути, а если нет, то следы бага будут аккуратно убраны, а сам баг спрячется до часа X.
3. Однобокость. Если сразу создавать репорт, то у нас не будет времени, что бы взглянуть на баг с другой стороны, в другом контексте. Не получится спросить мнения других участников разработки, ведь они могут быть заняты в данный момент. При отсутствии точного технического задания это особенно актуально.

Мой подход.
Берётся логическая часть объекта тестирования, функциональность. Полностью тестируется, для каждого потенциального бага создаётся запись, если нужно скриншот. В дальнейшем такая запись пополняется, уточняется. После окончания тест-сессии начинается работа с претендентами на звание бага. Отойдя от прогона тест-кейсов, можно заново взглянуть на найденные баги, точнее локализовать их, в случае сомнений обсудить их с разработчиками, тестировщиками, менеджерами. В результате белого шума становится меньше и разработчики получают более качественные баг-репорты.

Мнения?

Мой подход. Берётся логическая часть объекта тестировани...

Поначалу все так делают. Записи в блокноте, например. Но чем дальше в лес, тем яснее становится обоснование мантры "Заводи сразу".

Меняется контекст. Меняется состояние приложения. Можно потерять цепочку действий, которые привели к багу (иногда они очевидны, а иногда нет). Можно забыть. Можно не воспроизвести (вы же первым делом баг воспроизводите при обнаружении, нет?!).

ПОЭТОМУ:

1) Скриншот с понятным названием.
2) Репорт где и как угодно. Лучше сразу в трекер, особенно если окружающие ждут от вас информации. Если что - потом можно будет дополнить. "Не бойтесь ошибиться - бойтесь пропустить".
3) Научитесь делать репорты максимально быстро. Поначалу это кажется сложным, но это возможно.
4) Перестаньте придумывать самому себе обоснования того, почему "это не возможно" :)

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

>>> "сразу же, как только обнаружил баг"
Делаю так и считаю подход правильным и удобным, не приходиться по нескольку раз возвращаться к одному и тому же багу. А для того чтобы мнение не было однобоким, нужно попробовать его воспроизвести по разному и поисследовать данное место и когда все на данном этапе будет понятно - переходить дальше.

astenix, спасибо за ответ
Не посчитайте нахальством, буду дискутировать :)

>Меняется контекст. Меняется состояние приложения.

Так ведь тестирование и заключается в проверке, как работает приложение с различным окружением и в различных состояниях. В запись так и заносится "запустил Open Office, программа x закрылась, когда в ней происходил процесс y"

>Можно потерять цепочку действий, которые привели к багу (иногда они очевидны, а иногда нет). Можно забыть.

Что забыть? Всё же записывается, с деталями. Если цепочка действий не очевидна, то как же описывать её в репорте без дополнительных проверок и локализации?

>Можно не воспроизвести (вы же первым делом баг воспроизводите при обнаружении, нет?!).

Если баг не воспроизводится то о нём тем более не следует сразу же сообщать. А стоит внести в заметки и отложить для дальнейшего рассмотрения. Или я не прав?

>Перестаньте придумывать самому себе обоснования того, почему "это не возможно" :)

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

[i] Лучше сразу в трекер, особенно если окружающие ждут от вас информации. Если что - потом можно будет дополнить. "Не бойтесь ошибиться - бойтесь пропустить".
3) Научитесь делать репорты максимально быстро. Поначалу это кажется сложным, но это возможно.

Я абсолютно согласна с человеком. Вот какие проблемы случаются если я не занесла баг сразу:
1) Второй раз , ну например, вечером баг не воспроизвелся - потому, что шаги полностью я не записала, а сделала лишь пометку в блокноте. Пытаюсь вечером ( или на следующий день ) повторить и не выходит. Но это не значит , что проблема исчезла.
2)Часто отвлекают. Позвонили из тех. поддержки, из другого офиса, заказчик и т.д. Планировал баг занести вечером, а из-за выше перечисленных проблем не занесла. Через пару дней програмеры говорят где ошибки? Я им "вроде заносила". А в bug trackere их нет.
3)Никогда не надейся на свою "отличную" память. Думаешь "вроде эту ошибочку я уже где-то видел, поэтому по-новой заносить не буду". Лучше иметь дубль , чем не занести баг вообще.

2ksena:

>Для того чтобы сделать запись вы разве не отвлекаетесь?

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

>В итоге вы делаете двойную работу и тратите время дважды.

Белый шум, при таком подходе убивает время всех участников процесса.

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

Когда полностью протестирована одна функциональность и можно увидеть всю картину целиком разве не отпадёт потребность в таких зависаниях над каждым багом? А вдруг сомнения появятся, всё равно писать репорт?

2Tuchka_84:

>вечером баг не воспроизвелся - потому, что шаги полностью я не записала, а сделала лишь пометку в блокноте

А что мешало в блокноте сделать более детальную запись?

>Часто отвлекают...

Ну у нас же в заметке всё чётко записано. Причём заметку такую мы записали за 10 сек и посторонние факторы не помешают нам забыть об этом баге.

>Никогда не надейся на свою "отличную" память.

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

Что забыть? Всё же записывается, с деталями.

А что мешало в блокноте сделать более детальную запись?

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

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

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

Пока вы умалчиваете о найденных багах, разработчики пишут новые. Про 1-10-100-1000 слыхали?
С какой целью вы тестируете - прогнать тест-кейсы не отвлекаясь?

Как принято.
Популярный ответ на этот вопрос прост и лаконичен: "сразу же, как только обнаружил баг". Причём, аргументация такого подхода выглядит как "куй железо пока горячо" или "так принято".

Это чья аргументация? Ваша?

>Мне не понятно, какая разница где делать детальную запись в блокноте или в трекере?

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

>Сколько же у вас уходит время на то чтобы оформить баг?

Непосредственно на оформление не много времени, на локализацию часто много дольше.

>неужели это занимает меньше времени чем оформить баг?

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

>К тому же для разработчиков есть разница в том когда вы сообщите им о баге.

Вообщем всё верно, но я и не предлагаю выкатывать раз в день, просто по завершении тестирования некоторого логического элемента. А вот понравится ли разработчикам множество однотипных, неполных багов?

Как принято.
Популярный ответ на этот вопрос прост и лаконичен: "сразу же, как только обнаружил баг". Причём, аргументация такого подхода выглядит как "куй железо пока горячо" или "так принято". Но вот многострадальный лоб, в очередной раз столкнувшись с великими граблями реальности заставляет пересмотреть данное утверждение.

Почему не стоит так поступать.
При использовании выше обозначенного подхода приходится сталкиваться со следующими сложностями:
1. Замедление процесса тестирования. Когда прогоняешь тест-кейсы или проходишь по чек-листам, вообщем активно тестируешь приложение, у тебя всё настроено именно под этот процесс, даже мозг активно работает в ключе тестирования. Перерыв после каждого бага для создания репорта сильно отвлекает от процесса, мешает сосредоточиться и в конечном итоге сильно растягивает процесс.
2. Видна лишь часть проблемы. Баг, в классическом понимании - это не соответствие ожидаемого результата и полученного. На практике же часто можно видеть лишь следы деятельности бага и вместо описания оного наделать множество репортов о его следах. Хорошо, если программист окажется добросовестным и докопается до сути, а если нет, то следы бага будут аккуратно убраны, а сам баг спрячется до часа X.
3. Однобокость. Если сразу создавать репорт, то у нас не будет времени, что бы взглянуть на баг с другой стороны, в другом контексте. Не получится спросить мнения других участников разработки, ведь они могут быть заняты в данный момент. При отсутствии точного технического задания это особенно актуально.

Мой подход.
Берётся логическая часть объекта тестирования, функциональность. Полностью тестируется, для каждого потенциального бага создаётся запись, если нужно скриншот. В дальнейшем такая запись пополняется, уточняется. После окончания тест-сессии начинается работа с претендентами на звание бага. Отойдя от прогона тест-кейсов, можно заново взглянуть на найденные баги, точнее локализовать их, в случае сомнений обсудить их с разработчиками, тестировщиками, менеджерами. В результате белого шума становится меньше и разработчики получают более качественные баг-репорты.

Мнения?

Видать не зря я на конференции собираюсь рассказывать как правильно работать с дефект-трекером.

1. Замедление процесса тестирования. Когда прогоняешь тест-кейсы или проходишь по чек-листам, вообщем активно тестируешь приложение, у тебя всё настроено именно под этот процесс...
Скажите, пожалуйста, вы эти тест-кейсы гоняете просто чтобы прогнать или чтобы найти баги? У вас есть определенное _константное_ время, отведённое на прогон тест-кейсов и не учытывающее то, что в процессе будут найдены баги?

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

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

Замечу - я всецело разделяю точку зрения, что (1)дефект должен быть исследован с разных сторон; (2)возможно лучше переговорить с программистом, архитектором, дизайнером итд. прежде чем заносить _сложный_ баг. Если вы отложите написание(официальное оформление в трэкере) на час-два-три - обычно в этом нет ничего абсолютно зазорного. Но если это релиз-кандидат и вы нашли серьёзный дефект - надо его заносить сразу же. А вот откладывать на завтра, ждать командного митинга в следующую среду или ответа по почте в течение недели конечно же никогда не надо. Это возможно только в редких исключительных случаях.

>Пока вы умалчиваете о найденных багах, разработчики пишут новые. Про 1-10-100-1000 слыхали?

Про "1-10-100-1000" не слышал, буду благодарен, если просвятите.
Видимо в наших компаниях по-разному устроен процесс работы над релизом. Пока я выкатываю баги, разработчики правят предыдущие.
Да и выкатка осуществляется не так и редко.

>Это чья аргументация? Ваша?

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

>Скажите, пожалуйста, вы эти тест-кейсы гоняете просто чтобы прогнать или чтобы найти баги?

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

>У вас есть определенное _константное_ время, отведённое на прогон тест-кейсов и не учытывающее то, что в процессе будут найдены баги?

Примерно. Всё рассчитывается так, что бы выкатка багов случалась регулярно.

>Что мешает найдя баг тут же его поисследовать, записать в трэкер и потом продолжить гонять?

1. Не видна вся картина целиком. Когда мы всю функциональность проверили, баг легче локализовывать.
2. Нарушается процесс тестирования. Вот запущена у меня груда всего, настроено окружение, мысли текут плавной рекой, а тут на тебе - начинаем метаться по всему приложению, заходить в баг-трекер. Потом всё заново настраивать. Зачем так гробить своё драгоценное время?

>А мнение своё другие участники скажут в комментариях к записи о дефекте.

Люди ленивы дальше некуда. Напишет максимум разработчик, который не смог повторить.

>Или вы считаете, что надо ждать когда человек писавший код вернётся, например, из отпуска и не писать баги в трэкер?

Ну зачем же в крайности? Офис же не опустеет, а если опустеет, то да сам приму решение. :)

>Но если это релиз-кандидат и вы нашли серьёзный дефект - надо его заносить сразу же.

Абсолютно согласен. Серьёзный баг, во время активной работы над релизом нужно максимально быстро локализовать и отправить на исправление.

>А вот откладывать на завтра, ждать командного митинга в следующую среду или ответа по почте в течение недели конечно же никогда не надо.

Я вроде как этого и не предлагал

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

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

>А вот откладывать на завтра, ждать командного митинга в следующую среду или ответа по почте в течение недели конечно же никогда не надо.
Я вроде как этого и не предлагал

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

Я понимаю, что вы хотите сказать. По аналогии - у меня есть несколько автоматизированных тестовых прогонов в разных конфигурациях. Я их запускаю и я не кидаюсь писать баг (тест №333 упал) сразу же после того как он упал, а дожидаюсь конца прогона и анализирую результаты и стараюсь понять: разные тесты попадали по одной причине или по разным в рамках одной конфигурации. Далее я запускаю тесты (или они сами запускаются) в других конфигурациях - это дает мне знание о том, где тот или иной тест падает и наводит на мысли от чего это зависит.
Конечно же я начнаю писать баги, когда у меня перед глазами есть полная картина. Это вполне очевидно. По некоторым из них я пишу письма на общий элиас или разговариваю с конкретными разработчиками, прежде чем занести баг в трэкер. Но я считаю, что я делаю это сразу, а никуда не откладываю. Или я не так вас понял?

PS: есть кнопка ответить на коментарий

Про 1-10-100-1000 слыхали?

Clauster, а что это такое? Я тоже не сталкивался.

>А мнение своё другие участники скажут в комментариях к записи о дефекте.

Люди ленивы дальше некуда. Напишет максимум разработчик, который не смог повторить.

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

2ksena:

>Тут я не совсем поняла, как баг-трекер сбивает настройки среды? Он встроен в ваше приложение?

Метаться - это я в основном про локализацию.

>Чего сложного то?

Ок. Попробую по-другому объяснить. Вы на стрельбище. Снайпер. Стреляете в мишень. Будете после каждого выстрела подходить проверять результат? Или сделаете несколько выстрелов, а потом подойдёте и посмотрите?

>Если у меня куча багов то к концу дня я с трудом вспомню все, не то что шаги воспроизведения, имхо.

1. Всё записывается
2. Почему к концу дня-то? Через час-два, после того, как будет проверена функциональность.

2LeshaL:

>Что касается всего остального, так я считаю, что гонять тесты которые не находят баги или не имеют цели найтии их - вот это точно пустая трата времени.

Цель тестирования найти баги? Может я конечно и не прав, но мне всегда казалось, что конечной целью тестирования является проверка работоспособности тестируемого объекта. А если ни одного бага не найдено, значит тестировщик зря работал?

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

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