Еще один пример – высокая повторяемость дефекта. Если незначительный дефект становится чересчур назойливым для большого количества пользователей, то, скорее всего, стоит повысить приоритет и исправить его, пока это не переросло в более серьезную проблему. Как раз для этого и служит атрибут Reproducibility или Repro Frequency.
Важно знать, что ответственность по определению приоритета дефекта почти всегда лежит на стороне менеджеров проекта, поскольку тестировщик не может обладать знаниями о текущей загрузке команды разработки, приоритетов заинтересованных лиц, последствий, которые может вызвать тот или иной дефект в релизе, и т. д. Однако никто не запрещал даже в такой ситуации высказать свое мнение, особенно если ты уверен в этом на 100 % и тебя поддерживают коллеги.
2.1.4. Признаки плохого баг-репорта
Отчет о дефекте – это фактически задача для разработчика по устранению выявленного тестировщиком дефекта. Для того чтобы задача была решена эффективно и быстро, она должна быть корректно сформулирована.
Представь, что, будучи программистом, ты получаешь от коллеги-тестировщика задачи по исправлению дефектов со следующими описаниями.
1. Персонаж погибает
2. Противник не атакует
3. Транспортное средство отказывается ехать[16]
Кроме проблем с выражением собственных мыслей на родном языке, можно выделить дополнительные признаки того, что существенно ухудшает восприятие и понимание баг-репорта разработчиками.
1. Непредоставление точной информации, которая может помочь в устранении дефекта.
2. Непредоставление критически важной информации, например в какой тестовой среде проводилась проверка.
3. Обнаружение дефекта в функционале, не предназначенном для тестирования.
4. Предоставление в любых полях баг-репорта недостоверной информации.
5. Отчет содержит сленговые и жаргонные слова, а также различные аббревиатуры и термины, понятные не всем.
6. Дефект содержит критику в сторону разработчиков.
7. Выставление заведомо неверного уровня критичности.
8. Отчет содержит большое количество языковых ошибок, не позволяющих понять смысл.
9. Непредоставление вложений: логов, дампов, скриншотов, без которых разработчик не видит дефекта.
10. Тестировщик не смог убедить разработчиков в критичности дефекта.
Сравни два примера ниже. Это два реальных баг-репорта, написанных тестировщиками-новичками. Какой из них ты считаешь более правильным?
Пример № 1
Пример № 2
Хорошая практика для тестировщика – перечитывать, а еще лучше рецензировать (а в самом начале карьеры тестировщика это обязательно должен делать руководитель проектной группы – лид) написанное в отчете о дефекте на предмет понятности, лаконичности и наличия важной информации.
2.2. Жизненный цикл дефекта (Defect Life Cycle)
Жизненный цикл дефекта – это период существования бага с момента, когда он был найден и описан тестировщиком, до момента, когда дефект был исправлен одним из игровых разработчиков. Схема ЖЦД важна для понимания того, что может произойти на этом пути. Часто эту схему называют модным словом workflow.
Жизненный цикл дефекта
Хотя из приведенной схемы все довольно понятно, давай рассмотрим ее детально.
Первый статус, который получает дефект после обнаружения и описания, – «Открыт». Этим ты ответственно заявляешь, что обнаружил нечто, что ты считаешь дефектом, и ставишь задачу по его исправлению одному из разработчиков. Дальше ты должен выбрать того разработчика, которого считаешь ответственным за появление этого бага в игре, и поставить эту задачу ему (выбрав из списка Assigned To). Потом наступает момент истины. Разработчик может отклонить баг по разным причинам, в том числе заявив, что это вообще не баг. А может быть, он просто не смог найти его по твоему описанию. Или ты назначил эту задачу не тому разработчику. Как бы то ни было, далее есть два пути: 1) согласиться с разработчиком и закрыть задачу и 2) не согласиться, внести исправления в задачу, если нужно, и переоткрыть (ReOpen) ее, назначив этому же или другому специалисту. Далее часть, описанная выше, может повторяться до тех пор, пока дефект не будет принят в работу (In Work). Кстати, в жизни это происходит гораздо быстрее, чем тут написано. Казалось бы, дальше у дефекта не остается ни одного шанса на выживание, и он получает статус «Исправлен» (Resolved). Но иногда при повторном тестировании тестировщик видит, что дефект не был исправлен или был исправлен не до конца, и тогда баг снова переоткрывается. Если же мы больше не обнаруживаем дефект после проведения повторного тестирования, то задача закрывается, а дефект помечается как исправленный.