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

[OVA]

Не любой багтрекер)

[Undi]

Недавно столкнулась с мнением что видеозапись или скриншот есть следствие неправильно локализованного бага, так вот я с этим мнением согласна только частично :)
Попрошу мнения на этот счет.

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

[Undi]

Не любой багтрекер)

например?

[Undi]

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

можете привести пример такой ситуации? просто что-то из Вашего опыта

[Куатор]

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

Эмм.. регрессионное тестирование вроде ж никак не связано с багами, описанными тестировщиками на предыдущем цикле..

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

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

[OVA]

например?

FogBugz. Могу еще привести, если нужно.

[Clauster]

например?

FogBugz. Могу еще привести, если нужно.

В FogBugz можно :)

[Undi]

Эмм.. регрессионное тестирование вроде ж никак не связано с багами, описанными тестировщиками на предыдущем цикле..

Смотря что понимать под регрессионным тестированием: http://www.protestin...regression.html

[Undi]

например?

FogBugz. Могу еще привести, если нужно.

А вот здесь написано, что версии билдов есть http://support.fogcr...gbugz.4.91588.8 (первая попавшаяся ссылка из гугла) и здесь тоже: http://rpmsoftware.c...dex.php/FogBugz

[OVA]

Гугль зло. Там написано что можно сделать через кастом филд. Проблема в том что кастом филдов в FogBugz можно сделать весьма ограниченное количество и если их поставить под версию, то не влезет что-то еще.

По умолчанию поле отсутствует, так что...

[notProgrammer]

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

можете привести пример такой ситуации? просто что-то из Вашего опыта

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

[Undi]

Гугль зло. Там написано что можно сделать через кастом филд. Проблема в том что кастом филдов в FogBugz можно сделать весьма ограниченное количество и если их поставить под версию, то не влезет что-то еще.

По умолчанию поле отсутствует, так что...

И как это относится к обсуждаемой теме?
Вы утверждали, что FogBugz версионность не поддерживает. Вам ответили, что версионность отслеживать в FogBugz можно.
Если у Вас другие приоритеты и Вы не хотите настраивать версии - это уже другая тема.
Еще примеры будут?

[Undi]

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

1. Как Вы сами видите, скриншот не спасает от программистов, которые не читают шаги воспроизведения :) Даже со скриншотом баги возвращаются, так что картинки - не панацея.
2. На самом деле всё работать может потому, что исправлена другая ошибка, которая ликвидировала эту. Или потому, что у программиста другое окружение (другая версия ОС, браузера, офиса и т.п.) Возможно, Вы не указали что-то в описании или программист не прочитал.
3. Скриншот не поможет исправить баг, если нет описания (говорю о UI). Даже если разработчику показать картинку, он не сможет исправить, если на его компьютере баг не воспроизводится. Либо же ему нужно будет самому проводить тестирование, что не хорошо.
4. Часто при разработке не-коробочных продуктов предъявляются требования к окружению. Например, у пользователей стоит лицензионная Vista и заказчик не собирается ее менять на Windows 7, а Вы тестируете на Windows 7. Но это самый простой пример.

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

[OVA]

И как это относится к обсуждаемой теме?
Вы утверждали, что FogBugz версионность не поддерживает. Вам ответили, что версионность отслеживать в FogBugz можно.
Если у Вас другие приоритеты и Вы не хотите настраивать версии - это уже другая тема.
Еще примеры будут?

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

Но по большому счету ерунда все это. Как и сам вопрос в топике.

[Clauster]

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

можете привести пример такой ситуации? просто что-то из Вашего опыта

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

А цели вы своей добились? Ошибка-то не выявленной оказалась в итоге. У нормального программиста не создастся впечатления что тестировщику ошибка показалась, если это только не ваши личные домыслы. Не бойтесь оказаться в дурацком положении, бойтесь оказаться в более дурацком положении.

[notProgrammer]

3. Скриншот не поможет исправить баг, если нет описания (говорю о UI). Даже если разработчику показать картинку, он не сможет исправить, если на его компьютере баг не воспроизводится. Либо же ему нужно будет самому проводить тестирование, что не хорошо.

Да, я с Вами согласна: картинка - не панацея. Я и не говорю, что должна быть ОДНА картинка. Но описание + картинка по-моему достаточное количество информации для исправления. Тем более, что программисты часто сами просят скриншот...

В идеальной ситуации - взять разработчика за руку и показать ему по шагам ошибку на тестовом окружении.

Не всегда получается... Иногда они сидят за океаном...

[notProgrammer]

А цели вы своей добились? Ошибка-то не выявленной оказалась в итоге.

Она выявлена. Я описала ещё раз и... в этот раз внимательнее читали, наверно...

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

Вот этого не поняла...

[Clauster]

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

Вот этого не поняла...

Относится к

у программиста создаётся впечатление, что тестеру показалось...

Не зацикливайтесь на том, что о вас могут подумать, если вы напишете неполноценный баг, зададите глупый\бессмысленный (на первый взгляд) вопрос, переспросите что-то 10-й раз и т.д. Программист и вы - заодно, нет у него права на домыслы, как и у вас - если вы обнаружите глупую ошибку, нет права сомневаться в компетенции разработчика. Смысл в том, что если вы лишний раз что-то "постесняетесь" сделать из-за каких-то домыслов, можете попасть в более дурацкое положение, чем когда это сделаете, т.к. цена последствий обычно возрастает в геометрической прогрессии и часть вины за них может быть за вами.

[Clauster]

А цели вы своей добились? Ошибка-то не выявленной оказалась в итоге.

Она выявлена. Я описала ещё раз и... в этот раз внимательнее читали, наверно...

Не с первого раза, и скриншот не помог, как уже сказали выше. Т.е. если разработчик не может воспроизвести, то ни скриншот, ни видео ошибки не помогут, т.к. разработчик вряд ли будет заниматься вниканием в проблему, анализом и исследованием - вы в эту проблему уже вложились, поэтому дешевле будет вернуть её обратно вам на воспроизведение, и тут он прав на 100%.

[Drag]

Не с первого раза, и скриншот не помог, как уже сказали выше. Т.е. если разработчик не может воспроизвести, то ни скриншот, ни видео ошибки не помогут, т.к. разработчик вряд ли будет заниматься вниканием в проблему, анализом и исследованием - вы в эту проблему уже вложились, поэтому дешевле будет вернуть её обратно вам на воспроизведение, и тут он прав на 100%.

А видео? Разве в таком случае оно было бы лишним? Да и спорный это вопрос - некоторые вещи почти не реально воспроизвести. А то что это было не НЛО все же доказать надо.