Комментарии 16
похоже на старые споры типа, как креститься — слева на право или с право на лево :)
Проблема выглядит высосанной из пальца, но как и многие так выглядящие проблемы порождает крупные холивары. Лично я согласен с автором по всем пунктам, как и с тем что в каждом проекте желательно придерживаться единообразия, чтобы не искать нужные логические элементы каждый раз в новом месте. Думаю если ты пришёл в чужой монастырь, а там желаемый результат пишут первым, то максимум, что можно сделать это предложить правильный, с твоей точки зрения вариант, и смирившись с отказом писать как пишут остальные и не ерепениться.
У каждого свое.
Я привык к тому, что с теми разработчиками, с которыми я работаю — к каждому есть свой подход. Кому-то нужно расписывать баг по всем степам, со всеми пунктами, и т.д., а кому-то просто написать «там-то не работает то-то» и все. Это точно экономит кучу времени ввиду того, что разработчик знает свой кусок проекта, и мое время на детальное описание бага.
Я привык к тому, что с теми разработчиками, с которыми я работаю — к каждому есть свой подход. Кому-то нужно расписывать баг по всем степам, со всеми пунктами, и т.д., а кому-то просто написать «там-то не работает то-то» и все. Это точно экономит кучу времени ввиду того, что разработчик знает свой кусок проекта, и мое время на детальное описание бага.
В зависимости от того, как распределена команда. Например, сейчас я работаю на проекте, где все сидят в одной комнате: программисты, тестировщики, менеджеры, дизайнеры. Поэтому баг-репорты можно описывать поверхностно не вдаваясь в детали. Когда же я работал там, где тестировщики в одном офисе в Украине, программисты в Индии, а менеджеры в Англии, то тут проще будет полностью все расписать со всеми деталями и вытекающими, чем потом по скайпу объяснять отдельно в случае каких-то неясностей.
Считаю такой подход совершенно неправильным. Чтоб не отвлекать друг-друга от работы проще один раз все подробно расписать, чем потом несколько раз переспрашивать причем иногда одно и то же, т.к. когда на тебе висит, допустим, 50 багов, которые нормально не расписаны, то далеко не каждый сможет постоянно держать правильную и полную информацию по каждому из них, что опять таки ведет к отвлечению от работы тебя самого, потере времени.
кстати, а вы за описание багов на английском или русском? Понятно, что все сильно зависит от клиента, если он англоговорящий и ходит в баг-трекер, то должно быть понятно первым делом ему. Но почему-то многие QA инженеры владеют просто отвратительным английским (многие и русским :( ) и описания багов сводятся к предложениям типа «Нажимать на кнопка» (в дословном переводе). Ваше мнение?
это проблема не только QA инженеров(
Я за английский, т.к. по большому счету вся компьютерная терминология на нем, хотя сейчас работаю на проекте, где заказчик требует всю документацию и названия исключительно на русском. Даже во время тренингов по Scrum просил переводить такие термины, как Product Backlog(продуктовый заднесписок), Product Owner(властелин продукта).
Какой-то бред. В начале статьи поставлены глобальные вопросы о дизайне дефектов, а под катом детский лепет о правильной позиции ожидаемого результата. Есть куча интересных ситуаций, в которых действительно возникают вопросы о правильном дизайне дефекта в конкретном случае, но вот чтобы кто-то ругался по поводу положения expected result, которого, к слову, во многих случаях вообще не должно быть, — такое я встречаю впервые.
Не удивлюсь, что прежде чем потратить полчаса на написание поста на хабре, автор (будучи, вероятно, менеджером тестовой группы) целый час парил эту чушь на статус митинге с разрабами и менеджером проектов. Инмайхамблопинион, вам просто нечем заняться.
Не удивлюсь, что прежде чем потратить полчаса на написание поста на хабре, автор (будучи, вероятно, менеджером тестовой группы) целый час парил эту чушь на статус митинге с разрабами и менеджером проектов. Инмайхамблопинион, вам просто нечем заняться.
Честно, идея возникла написать пост, когда умнки с других проектов приходили и начинали доставать своим «феш-шуем». После подобных изъяснений успокаивались и тихо с миром уходили. Будучи на данный момент PM'ом, комманды работают спокойно и подобных споров ни у кого не возникает.
P.S. Философам тоже нечего было делать, вот они и размышляли.
P.S. Философам тоже нечего было делать, вот они и размышляли.
Пишите шаги, ожидаемый и актуальный результат в разных полях баг-трекера. Допилите его, если он этого не умеет, что бы он позволял настроить порядок следования этих полей.
Жизнь обычно все расставляет по своим местам.
Когда баг начинающего тестировщика девелопер завернет пару раз, поскольку «не смог воспроизвести» или «необходимы дополнительные данные о пользователе», — быстро научиться писать как надо. Ну или не задержится надолго, поскольку наука не бог весть какая сложная, чтобы еще по таким вопросам митинги собирать. Где-то скриншота достаточно, где-то — заголовок раскрытия не требует. А есть баги, где и условия воспроизведения заковыристые, и аналитика по числу пострадавших пользователей требуется, и и подборка ссылок на предыдущие баги есть они взаимосвязаны.
У нас ввели в качестве стандартного темплейта список вида:
Environment:
Browser:
User name:
Membership ID:
Screenshot:
Steps to reproduce:
В результате народ его по большей части игнорирует, поскольку какие-то данные смысла не имеют для конкретного бага, зато каких-нибудь иных вводных может не хватать.
Когда баг начинающего тестировщика девелопер завернет пару раз, поскольку «не смог воспроизвести» или «необходимы дополнительные данные о пользователе», — быстро научиться писать как надо. Ну или не задержится надолго, поскольку наука не бог весть какая сложная, чтобы еще по таким вопросам митинги собирать. Где-то скриншота достаточно, где-то — заголовок раскрытия не требует. А есть баги, где и условия воспроизведения заковыристые, и аналитика по числу пострадавших пользователей требуется, и и подборка ссылок на предыдущие баги есть они взаимосвязаны.
У нас ввели в качестве стандартного темплейта список вида:
Environment:
Browser:
User name:
Membership ID:
Screenshot:
Steps to reproduce:
В результате народ его по большей части игнорирует, поскольку какие-то данные смысла не имеют для конкретного бага, зато каких-нибудь иных вводных может не хватать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Философия бага – описание ошибки