Комментарии 17
Я вот не понял: если у вас баги заводят тестировщики — их же можно проинструктировать, ка делать хорошо. Логи, скриншоты, термины общепринятые… Если баги заводят пользователи — для чего тогда нужны тестировщики, непонятно.
На этапе тестирования не всегда можно отловить все ситуации. Некоторые (например, если речь про мобильную версию сайта или мобильное приложение) могут быть специфичными для конкретного устройства, системы или оператора связи.
Имхо очень многие проблемы из перечисленных пропадают если тестировщиков и разработчиков объединить в одну скрам команду и работать не по-одиночке, а совместно:
- баги на этапе функционального тестирования новой фичи вообще можно не заводить — достаточно дейли митинга, командного чатика и общения с разработчиком напрямую
- если багу таки решают завести в системе — скорей всего она некритичная и/или не может быть исправлена во время разработки (как вариант — решили не чинить сознательно). При этом разработчик уже в курсе событий и помогает оформить так, чтоб было понятно другим разработчикам
- баги от клиентов проходят через команду (включая разработчиков) и, точно так же, как и баги на этапе разработке — оформляются более подробно
- благодаря постоянному сотрудничеству и общению разработчиков и тестировщиков, последние лучше понимают технические детали реализации, а также на что обращать особое внимание во время тестирования
- если дать тестировщикам возможность писать интеграционные тесты на стадии разработки, синергия становится ещё сильнее
- в идеале, тестировщики также должны уметь читать и анализировать не слишком сложный код — это позволяет находить нетривиальные проблемы
Дошел до пункта 7, то есть если у меня не ожидаемый хром, а скажем фаерфокс и сайт разъезжается на масштабе отличном от 100%, то я должен ломать глаза уменьшая
масштаб? Мда, с таким начальством тестировщики не нужны, сколько багов не найдут всё будет фичей.
Бнопня а не кракозябра. Это называется бнопня.
Случай из практики. Разрабатывал backend сервиса доставки уведомлений. Заказчик и ПМ — 100% уведомлений должны придти вовремя. Ок, понятно. Тестировщик гоняет приложение днями и ночами. И иногда прибегает ко мне с глазами полными ужаса — у меня половина уведомлений недоставлена, я тебе тикетов наделал. Садимся, рассказываю flow, еще раз кидаю ссылку на документацию с описание бизнес-логики, показываю, что это нормальная ситуация, уведомления недоставлены потому, что их мобильное устройство получателя выключено, поэтому backend перевел уведомления в состояние "недоставлено в срок". Прошу, почитай доки, спроси меня, прежде чем тикеты создавать, от количества которых у ПМ уже нервный тик. Ок? Ок. Как вы понимаете, итерации повторялись с определенной периодичностью.
Вывод, тестируя бизнес-логику надо понимать бизнес-логику, а не додумывать ее. Очевидное, но порой невероятное открытие для некоторых тестировщиков.
"пользователи будут так же поднимать это вопрос"
Задокументированные баги становятся фичами. Если недоставленное уведомление это норма — надо делиться этим знанием. А то будет как с тем принтером, который не печатает, потому что бумага кончилась. а положить пачку бумаги в лоток умеет только Главный Администратор.
Второй пункт был очень поучительный и он о том, чтобы описывать баги полностью
При заведении бага следует прикладывать ссылки на логи с целью уменьшения экономии времени.
Но все-таки, наверно, формулировку лучше поправить ;-)
четко описанную версию бага.У свеженайденных багов есть версии? Не понял этот пункт.
6. Актуализация критериев приёмкиЧетыре абзаца текста, на мой взгляд, можно было свести к одному, донеся простую мысль — указывайте ожидаемый результат.
заведение бага без ожидаемого результата.Этот абзац относится к пункту 6, а не 8.
Как не надо заводить баги. Часто встречающиеся ошибки