Визуальные подтверждения багов

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

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

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

А кто автор данного мнения. Это есть лицо компетентное или нет?
у меня часто заказчики требуют запись видео

Да ради бога :) http://software-test...um/topic/18294/ Вот тут то все и началось, но т.к. там тема о другом ее перенесли сюда.
Я например считаю что в некоторых случаях запись (или скриншот) имеет место быть, и даже обязательно. Но не все с этим согласны.

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

Как по мне нельзя все ситуации да и под одну гребёнку..
Во многих случаях, снэпшоты и видео это действительно следствие неправильной локализации дефекта :) Но..
Ситуация (реальная).
Разрабатывается новое приложение. Тестировщик находит дефект, консультируется с девелопером.
Получает ответ - да дефект, надо постить.
Постит. Без видео, без снэпшотов (девелопер сразу понял в чём проблема, в глубоком описании она не нуждается).
Всё супер, если дефект тут же пофикшен.
Но эта история имела продолжение.
Таких дефектов накопилось около сотни (не были сразу же пофикшены по разнообразных причинам) не только в этом новом приложении, но и остальных тоже.
Проходит полгода. Всё эту ораву проблем над отсортировать по приоритету, что-то пофиксить, что-то закрыть как устаревшее, что-то перенести в патчи и так далее.
Этим занялись тил-лидеры тестировщиков (!).
Просматривают уже не одну сотню дефектов, натыкаются на этот (описанный выше). Функционал, который фигурирует в описании изменился, пройтись по стэпам и увидеть проблему не удаётся "сходу".
Тил-лиды в attachmnets - там конечно пусто.. Убивают полчаса (отрывают дэва, который может сообразить о чём вообще речь).
Результат - приходит гневное письмо о профессионализме сотрудников.
Вопрос, как решать такие ситуации?
Зависит от компании конечно, у нас такие ситуации нередки и уже действительно сформировалась своеобразная "культура" оформления дефекта.
Потому что:
Три команды разработчиков из трёх разных стран работают над одним продуктом.
Три команды тестировщиков из разных стран работают над тестированием этого продукта.
Языковый барьер тоже играет свою роль.
Дефекты не фиксятся мгновенно. Их просматривают люди, которые не только не писали этот код, но даже не тестировали эту фичу.
Как описать дефект, чтобы потом всем было хорошо и не нужны были ни снэпшоты ни мувики?
Посоветуйте, мы возьмём на вооружение

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

Если функционал настолько изменился, то нужно тестировать его заново. Разве не так?

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

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

Если функционал настолько изменился, то нужно тестировать его заново. Разве не так?

Конечно, так и происходит, постоянно тестирование. Но если дефекты занесены в базу и не пофикшены сразу, с ними надо что-то сделать. Они как бы подвисают.. :) И потом маемо що маемо :)

Конечно, так и происходит, постоянно тестирование. Но если дефекты занесены в базу и не пофикшены сразу, с ними надо что-то сделать. Они как бы подвисают.. :) И потом маемо що маемо :)

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

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

Как по мне нельзя все ситуации да и под одну гребёнку..
Во многих случаях, снэпшоты и видео это действительно следствие неправильной локализации дефекта :) Но..
Ситуация (реальная).
Разрабатывается новое приложение. Тестировщик находит дефект, консультируется с девелопером.
Получает ответ - да дефект, надо постить.
Постит. Без видео, без снэпшотов (девелопер сразу понял в чём проблема, в глубоком описании она не нуждается).

Как это не нуждается? Дальше вы пожинаете плоды "неглубокого" описания.

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

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

Как описать дефект, чтобы потом всем было хорошо и не нужны были ни снэпшоты ни мувики?
Посоветуйте, мы возьмём на вооружение

Хорошие логи наше всё.

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

Мнение перефразировано неверно.
Вот что было на самом деле, а мувики тут вообще не при чем.

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

Просто некоторые ошибки невозможно повторить по тем же шагам (из личного опыта) и потом выходит что баг "не воспроизводится" и закрывается. Но при этом он явно не фантомный :)

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

Хорошие логи наше всё.

Учту-с!

Хорошие логи наше всё.

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

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

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

Мне трудно представить тестировщика, который сидит, выдумывает баги и заносит их в БТС :)

Хорошие логи наше всё.

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

Для всего что угодно можно придумать ситуацию, когда оно не будет работать. Есть такая характеристика у ПО (наравне с кучей других) - testability. Чем оно лучше, тем всем легче. Для каждого конкретного случая будут свои рецепты, панацеи, увы, не существует. Я написал применительно к своему случаю.

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

It depends. Забивать багрепорт картинками, видео, кусками логов, прогнозами погоды с марса и так далее далеко не всегда корректно.

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

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

Убрать слабое звено: либо не просматривать дефекты (вообще недопонял, что значит просматривать) или дать приоритезировать тем кто в теме. Почитайте Крылова И.А.:

Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник,
И дело не пойдет на лад.
Да и примечено стократ,
Что кто за ремесло чужое браться любит.
Тот завсегда других упрямей и вздорней:
Он лучше дело все погубит,
И рад скорей
Посмешищем стать света,
Чем у честных и знающих людей
Спросить иль выслушать совета.

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

Если функционал настолько изменился, то нужно тестировать его заново. Разве не так?

Не надо путать функциональное тестирование и регресс-тестирование. Здесь речь идет о регрессионном тестировании. "Тестирование заново" не является аргументом для закрытия старых багов.

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

Любой багтрекер позволяет фиксировать номера версий (билдов). Соответственно, тестировщик отмечает в какой версии баг найден, разработчик отмечает в какой версии баг исправлен. Можно ввести какое-то количество билдов, за которое баг должен быть закрыт (например, 5). Т.е. если баг наден в версии 2.4, а в 2.9 он не исправлен, его нужно перепроверить на версии 2.9 и внести изменения в описание шагов воспроизведения и в номер версии. Главное - не запускать этот процесс и не иметь давно висящих багов в принципе.