Сообщений в теме: 14

[KInnaO]

Привет!

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

Обязательно ли Bug Report должен содержать сценарий?

Что правильней:

• Если можно написать сценарий, то нужно его написать
• Если можно не написать сценарий, то нужно его не писать (если кому-то не понятно, то пусть спрашивают)

Конечно бывают случаи, когда сценария просто быть не может. Например если баг звучит так: Make Providers class public.

Что скажете по поводу темы?

[Oldman]

... Например если баг звучит так: Make Providers class public. ...

А баг может звучать как сделайте то-то?

[anz]

"Make Providers class public." - это не баг а request, в таком случае конечно можно не писать.

Сценарий aka Steps to Reproduce лучше писать всегда, даже если не предполагается что на описания дефектов будут смотреть люди со стороны (для которых дефект без "сценария" бессмысленен), а только внутренние разработчики и тестеры на проекте. В конце концов может смениться команда, или другую версию будут разрабатывать другие люди и для них понимание дефекта без repro steps будет очень затруднено.

[KInnaO]

... Например если баг звучит так: Make Providers class public. ...

А баг может звучать как сделайте то-то?

У нас может... есть разные типы багов (bug, task, wish, behavior confirmation etc.)

[Oldman]

как написал anz выше это не баг и то что вы его называете багом ничего не меняет

попробуйте тогда переформулировать вопрос с учетом того что читающие тему не знают как у вас внутри все бывает


P.S. Это кстати может быть багом но тогда это должно звучать примерно так

модуль такой-то
Providers class определен как private
Согласно документа "Правила написания кода" он должен быть определен как public

P.P.S Описание выше не претендует на полноту

[Case]

У нас может... есть разные типы багов (bug, task, wish, behavior confirmation etc.)

У вас есть разные типы запросов на изменение (change request), один из которых и есть баг.

[KInnaO]

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

Согласна, что пример не удачный.
Вопрос остается тем же (но без этого примера).

[rlabs]

Вопрос остается тем же (но без этого примера).

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

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

[Oldman]

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

Согласна, что пример не удачный.
Вопрос остается тем же (но без этого примера).

правильней: Если можно написать сценарий, то нужно его написать

Ситуаций в которых нельзя написать сценарий достаточно редки.

По поводу непонятно пусть спрашивают:
1. Это дополнительные затраты времени
2. Это неуважение к человеку который будет исправлять дефект и который будет проверять исправление

Если вы так будете делать то у вас никогда не будет хороших отношений с программистами

В дополнение почитайте статью http://it4business.ru/articles/106/

[greesha]

Реальный пример.

Добавил: Greesha
Проект: xxx8583
Приложение: xxx8583
Краткое описание: Зависание при чтении карты
Принято к исправлению в:
Исправлено в версии:
Важность: Critical
Статус: Open
Добавлено: 14/05/2008 11:35:12

При выполнении операции Sale при проведении тестовой магнитной картой xxx №1 (старой, exp. date 06/06) терминал xxx зависает и не реагирует ни на какие клавиши до выключения.

Воспроизводится не всегда, но часто. По другим картам зависаний пока не замечено.

Приложение 5.50 в варианте xxx8583_en, xxxLib 1.12.l, база параметров xxx терминал T0000001.

Нужен ли здесь какой-то дополнительный сценарий? Нет, не нужен, потому что все сотрудники, которые будут заниматься этим багом, заведомо знают, как его воспроизводить - собрать приложение 5.50 по метке xxx8583_en с библиотекой xxxLib 1.12.l, загрузить его в терминал xxx, ввести ID T0000001, загрузить параметры из базы xxx и попытаться выполнить операцию Sale по карте xxx №1.

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

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

[Oldman]

Реальный пример.

Добавил: Greesha
Проект: xxx8583
Приложение: xxx8583
Краткое описание: Зависание при чтении карты
Принято к исправлению в:
Исправлено в версии:
Важность: Critical
Статус: Open
Добавлено: 14/05/2008 11:35:12

При выполнении операции Sale при проведении тестовой магнитной картой xxx №1 (старой, exp. date 06/06) терминал xxx зависает и не реагирует ни на какие клавиши до выключения.

Воспроизводится не всегда, но часто. По другим картам зависаний пока не замечено.

Приложение 5.50 в варианте xxx8583_en, xxxLib 1.12.l, база параметров xxx терминал T0000001.

Нужен ли здесь какой-то дополнительный сценарий? Нет, не нужен, потому что все сотрудники, которые будут заниматься этим багом, заведомо знают, как его воспроизводить - собрать приложение 5.50 по метке xxx8583_en с библиотекой xxxLib 1.12.l, загрузить его в терминал xxx, ввести ID T0000001, загрузить параметры из базы xxx и попытаться выполнить операцию Sale по карте xxx №1.

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

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

@greesha у вас сотрудники не меняются?

А вообще в данном примере описан сценарий просто он не разбит на шаги

Ну а детальность описания сценария уже в каждой компании определяется самостоятельно

И зависит это в большей степени от квалификации сотрудников, динамики прихода/ухода сотрудников, сложности и объема проекта и процессов (одни и те же люди работают на данном проекте или выделяются те кто свободен в текущий момент)

[greesha]

@greesha у вас сотрудники не меняются?

А вообще в данном примере описан сценарий просто он не разбит на шаги

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

Компания у нас маленькая, все сидят в одном помещении, и обычно нет необходимости детального пошагового описания процедуры воспроизведения ошибки - достаточно её регистрации. Атрибуты бага, кстати, в этом примере перечислены все. В других атрибутах (приоритет, кому назначена, прочие статусы и т. п.) нет необходимости - опять же, из-за компактности команды.

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

[Oldman]

@greesha у вас сотрудники не меняются?

А вообще в данном примере описан сценарий просто он не разбит на шаги

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

Компания у нас маленькая, все сидят в одном помещении, и обычно нет необходимости детального пошагового описания процедуры воспроизведения ошибки - достаточно её регистрации. Атрибуты бага, кстати, в этом примере перечислены все. В других атрибутах (приоритет, кому назначена, прочие статусы и т. п.) нет необходимости - опять же, из-за компактности команды.

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

Я просто веду к тому что ваш пост никак не отменяет того что сценарии необходимы в описании дефекта :)

[VLana]

Ну и я расскажу до кучи :)
У нас в компании все зависит от рода сообщения в BugTracker, т.е задача/баг/пожелание итд.
Конкретно баги всегда описываются с шагами. Единственное на чем экономим это на описании интерфейсов.
Например, когда я говорю "Из главного меню выбрать пункт "Пункт"" я не описываю где находится это главное меню.
Или, напимер, "по контексному меню выбрать пункт.." а не "щелкнете правой кнопкой мыши по объекту, появится контекстное меню итд."
На последовательности шагов лучше не экономить. Иногда свои баги непонятно как воспроизвести через некоторое время.

[LeshaL]

Привет!

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

Обязательно ли Bug Report должен содержать сценарий?

Что правильней:

• Если можно написать сценарий, то нужно его написать
• Если можно не написать сценарий, то нужно его не писать (если кому-то не понятно, то пусть спрашивают)

Конечно бывают случаи, когда сценария просто быть не может. Например если баг звучит так: Make Providers class public.

Что скажете по поводу темы?

Здравствуйте.
Мне кажется, что задаваться вопросом "что правильнее" в данном случае не очень корректно. Есть случаи когда правильнее написать, а есть, случае когда можно и не писать шаги воспроизведения проблемы.
Вот, что точно не правильно, это описывать дефект думая о том, что "если кому-то не понятно, то пусть спрашивают". Если есть сомнения - то надо написать.
Советы:
1. Если действия тривиальные или очевидные - то можно съэкономить время и опустить описание действий.
2. Можно описать дефект таким образом, что дополнительное описание шагов становится излишним.
3. Поробуйте найти более простой способ воспроизвести проблему. Зачастую, последовательность шагов, которая привела к ошибке, может быть существенна сокращена.
4. Есть такое понятие как root cause analysis. Т.е. поиск истинной причины дефекта. Бывают случаи, когда одна проблема имеет несколько путей воспроизведения. Писать несколько дефектов в этом случае - неправильно. Но вот указать, что данный дефект имеет различные проявления лишним не будет.
5. Если в дефекте описан четкий алгоритм воспроизведения проблемы это может съэкономить время разработчика, который будет чинить проблему. Да и понизит вероятность закрытия разработчиком бага как not reproducible.
6. Помните, что наличие шагов воспроизведения проблемы в описании дефекта значительно упрощает верификацию данного дефекта, после того как его починят. Ведь не факт, что его будет верифицировать человек, который написал.
7. Старайтесь описывать проблему так, чтобы она была понятна...ну например новичку, недавно начавшему работать в вашей команде. В данном случае, если у вас есть такой новичок - ему без проблем можно поручить верикацию дефектов, а он будет задавать при этом меньше вопросов.

Как резюме - лучше один раз потратить 5 лишних минут и описать шаги воспроизведения в тот момент когда вы обнаружили и изучили проблему и пишите ее в дефект-трэкер; чем потом (через неделю, месяц, год) вспоминать или придумывать как же подтвердить то, что проблему реально починили.