ReninsIns Apr 14 2021 at 15:15

Как не надо заводить баги. Часто встречающиеся ошибки

5 min

14K

«Ренессанс страхование» corporate blogWeb services testing*

Recovery Mode

+14

Comments 17

Marfapr Apr 14 2021 at 15:37

памятка супер

UFO just landed and posted this here

yarkov Apr 14 2021 at 16:34

Краткость сестра та…

unsignedchar Apr 14 2021 at 16:35

Я вот не понял: если у вас баги заводят тестировщики — их же можно проинструктировать, ка делать хорошо. Логи, скриншоты, термины общепринятые… Если баги заводят пользователи — для чего тогда нужны тестировщики, непонятно.

Vitaly83vvp Apr 15 2021 at 09:33

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

unsignedchar Apr 15 2021 at 12:34

Тем более. У каждой ошибки есть фамилия, имя и отчество ;). Плохо оформленный баг можно вернуть автору для уточнения. Можно отбросить с пометкой "not reproduced". Ошибаются все, нет смысла делать из этого трагедию.

Wyrd Apr 14 2021 at 21:23

Имхо очень многие проблемы из перечисленных пропадают если тестировщиков и разработчиков объединить в одну скрам команду и работать не по-одиночке, а совместно:

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

lost55 Apr 15 2021 at 02:08

Если IT специалист не знает слова кракозябра (а применительно к шрифтам я синонима в одно слово сам не подберу, подскажите а?), то он наверное не видел даже BSoD WinXP. Так что проверьте возраст, возможно с ним еще нельзя заключать трудовой договор.

Дошел до пункта 7, то есть если у меня не ожидаемый хром, а скажем фаерфокс и сайт разъезжается на масштабе отличном от 100%, то я должен ломать глаза уменьшая
масштаб? Мда, с таким начальством тестировщики не нужны, сколько багов не найдут всё будет фичей.

foal Apr 15 2021 at 15:42

Согласен, «кракозябра» нормальный термин для компаний в которых программистов не заставляют ходить в костюмах. Надеюсь, таких большинство. Остальные могут использовать «нечитаемый/непонятный символ».

ondister Apr 15 2021 at 08:07

Бнопня а не кракозябра. Это называется бнопня.

lost55 Apr 15 2021 at 09:49

не путайте бнопню и кракозябру, бнопня это когда cp1251 читается как кои8, а кракозябра это когда русификатор не прогрузили, и пишут будто подгрузили (для однобайтных кодировок).

Nialpe Apr 15 2021 at 09:03

Случай из практики. Разрабатывал backend сервиса доставки уведомлений. Заказчик и ПМ — 100% уведомлений должны придти вовремя. Ок, понятно. Тестировщик гоняет приложение днями и ночами. И иногда прибегает ко мне с глазами полными ужаса — у меня половина уведомлений недоставлена, я тебе тикетов наделал. Садимся, рассказываю flow, еще раз кидаю ссылку на документацию с описание бизнес-логики, показываю, что это нормальная ситуация, уведомления недоставлены потому, что их мобильное устройство получателя выключено, поэтому backend перевел уведомления в состояние "недоставлено в срок". Прошу, почитай доки, спроси меня, прежде чем тикеты создавать, от количества которых у ПМ уже нервный тик. Ок? Ок. Как вы понимаете, итерации повторялись с определенной периодичностью.
Вывод, тестируя бизнес-логику надо понимать бизнес-логику, а не додумывать ее. Очевидное, но порой невероятное открытие для некоторых тестировщиков.

foal Apr 15 2021 at 15:49

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

unsignedchar Apr 15 2021 at 17:21

"пользователи будут так же поднимать это вопрос"

Задокументированные баги становятся фичами. Если недоставленное уведомление это норма — надо делиться этим знанием. А то будет как с тем принтером, который не печатает, потому что бумага кончилась. а положить пачку бумаги в лоток умеет только Главный Администратор.