Один из ярких примеров эффекта пестицида на практике я встретил в начале своего пути тестировщика. При работе над своим первым проектом – шутером – команда QA была поделена по игровым уровням, которые ежедневно проверялись с точки зрения прохождения. В какой-то момент уровень решил пройти коллега, который его не смотрел, и практически в самом начале нашел баг, который блокировал прохождение, так как его персонаж «застревал в геометрии» и не мог больше двигаться.
А произошло это потому, что ребята, которые регулярно проверяли уровень, проходили его практически с закрытыми глазами, знали, куда бежать, что активировать в игре, и эти маршруты для них изо дня в день были одинаковые. А для того, чтобы персонаж «застрял», нужно было всего-то сделать шаг в сторону.
6. Тестирование зависит от контекста
Разное по своей сути и назначению программное обеспечение требует разного подхода и методологии тестирования. Сузив этот принцип до тестирования видеоигр, можно утверждать, что не только тестовое окружение (то есть программно-аппаратная часть, необходимая для проведения тестовых активностей), но и методология будет отличаться в зависимости от жанра и типа игры.
7. Заблуждение об отсутствии ошибок
Даже если представить невозможную ситуацию, при которой были найдены и исправлены 100 % дефектов (мы помним, что такое невозможно в принципе!), не будет никаких гарантий того, что тестируемая нами видеоигра будет успешной у пользователей. Наша работа – обеспечить качество продукта, но привлекательность самого продукта мы обеспечить не в силах.
Ты скажешь: «Ладно, я понял, что не все так просто и что тестирование – это настоящая профессия, которая, как любая другая, требует времени на овладение и приобретение опыта, чтобы стать настоящим профессионалом. Но скажи честно: я что, буду тестировать игры до 60 лет? Я с трудом представляю себе дедушку, который увлекается тем же, что его внуки, и днями напролет торчит в компьютере, играя и тестируя, тестируя и играя».
Среди моих коллег есть поговорка: «Нет ни одного тестировщика, который не хотел бы стать разработчиком». И это вовсе не значит, что тестировщики стоят на более низкой ступени эволюции в игровой индустрии. Это значит, что ребята, которые стремятся любым способом попасть в игровую индустрию, не понимают, что тестирование – это важная и неотъемлемая часть разработки, без которой последняя невозможна, и имеют весьма отдаленное представление о связях профессий в индустрии. Кроме того, у большинства разработка ассоциируется с программированием и заблуждением о том, что программисты – это и есть люди, которые целыми днями занимаются креативом. На самом деле это миф № 1 в игровой индустрии, который необходимо развеять.
С точки зрения производства разработка видеоигры очень похожа на съемку кинофильма. И если в кино мы видим происходящее так, как это задумал режиссер, то в игровой индустрии такую функцию выполняет человек, профессия которого называется гейм-дизайнер. Именно он придумывает в игре практически все, и именно он является главным игровым демиургом.
А еще нужно знать, что в разработке игр принимают участие люди не одного десятка профессий, и они занимаются реализацией различных частей проекта. Кто-то пишет сценарии и диалоги персонажей (сценаристы), продумывает игровые механики и экономику (гейм-дизайнеры), кто-то воплощает задумки в программном коде (программисты), кто-то делает 3D-модели (3D-моделлеры, риггеры, аниматоры), а кто-то записывает музыку и звуки (звукоинженеры и композиторы).
Есть и те, кто фиксируют ошибки, появляющиеся на разных этапах разработки и помогают определить первопричину их появлений. Так вот, это и есть мы – тестировщики. И, научившись со временем понимать первопричины ошибок, начинаешь также понимать, как делать игру НЕ нужно и как правильно выстраивать процессы, чтобы минимизировать количество ситуаций, которые приводят к появлению дефектов.
Миф № 2: лучшие тестировщики получаются из лучших игроков. Это не так. Да, тестировщики проводят сотни и тысячи часов за игрой, но, как правило, у них нет предпочтений, они «всеядны». Они исследователи. Им нравится копаться в играх, развиваться и получать достижения, а не совершенствоваться в искусстве дуэли. Тестирование – это дисциплина, умение переключаться в режим, в котором получение удовольствия от игрового процесса не является больше основным. Это способность проходить один и тот же путь десятки раз, отслеживая на нем малейшие дефекты. Кроме того, ты должен быть довольно настойчивым, потому что собираешься играть в сломанную и, возможно, скучную и часто незаконченную игру просто потому, что хочешь, чтобы она была качественной и доставляла удовольствие другим людям. Геймеры, которые ставят перед собой цель добиться победы и стать лучшим на игровой арене, скорее, испытают разочарование от такой работы.
Миф № 3: тестировщики – в подавляющем большинстве случаев мужчины. По собственному опыту скажем, что это утверждение не имеет под собой никаких оснований. По моим наблюдениям, пропорция скорее выглядит как 65 к 35 или даже 60 к 40 в пользу мужчин, но при этом девушки часто гораздо более успешны в профессии. Возможно, это связано с большей устойчивостью женской психики к стрессам, большей внимательностью к деталям, терпеливостью и настойчивостью.
Миф № 4: тестирование – это, несмотря ни на что, все-таки довольно легкое занятие. Со временем ты нарабатываешь некий алгоритм работы и все идет по накатанному. Это довольно странное заблуждение, потому что то же самое можно сказать вообще о любой профессии. Сказать можно вообще все что угодно. Важно, чтобы сказанное имело смысл. А смысл в том, что врач, принимая десяток пациентов ежедневно, несомненно, приобретает опыт и совершенствуется в профессии. Однако этот опыт не дает ему права назначать лечение одному пациенту просто на основании некоторой схожести симптомов с симптомами другого. Поэтому хороший доктор каждый раз очень тщательно проводит исследования и диагностику, чтобы лечение было наилучшим в каждом случае. Так и тестировщик пусть и знает особенности жанра тестируемого продукта, все равно проводит тщательную проверку всех областей и деталей, стараясь не упустить ошибок.
И, наконец, миф № 5: игровое тестирование – это удел молодых людей, пока еще не получивших образования и могущих себе позволить образ жизни, сочетающий несложную работу и развлечение. На самом деле это совсем не так. В последние годы игры стремительно меняются: они становятся сложнее, технологичнее и, самое главное, становятся очень-очень похожими на реальный мир. Во время тестирования таких игровых продуктов в качестве ожидаемого результата часто выступает наша реальность со всеми ее законами. И нужно очень хорошо понимать, как устроена эта реальность. Без жизненного опыта это, увы, невозможно. Возможно, именно поэтому средний возраст тестировщика сейчас приблизился к 25–26 годам (а зачастую и гораздо больше).
Освободившись от этих навязчивых мифов, ты теперь можешь приступить к освоению нелегкого ремесла игрового тестировщика. Я помогу тебе освоиться с важнейшими, фундаментальными принципами и подходами в нашей профессии, помогу даже подготовиться в сдаче экзамена и получения международного сертификата игрового тестировщика ISTQB® Certified Tester Game Testing. Но опыт ты должен будешь приобрести сам. И я очень рассчитываю, что по прошествии времени ты войдешь в число лучших специалистов в области игрового тестирования.
Глава 02. Самая большая ошибка – не исправлять ошибки
Чем больше надежд мы возлагаем, тем сильнее может быть разочарование…
• Что такое дефект?
• Чем дефекты отличаются друг от друга?
• Что такое баг-репорт и для чего он нужен?
• Что такое критичность дефекта и как ее правильно определить?
• Что такое приоритет дефекта?
• Что такое жизненный цикл дефекта?
• Когда и почему появляются дефекты?
• Как снизить риск их появления?
• Где место тестирования в разных моделях разработки?
• Как тестировщик взаимодействует с заинтересованными лицами проекта?
Выше я говорил о процессе тестирования как о процедуре сравнения ожидаемого результата с реально полученным и заявил, что любое расхождение между ними и есть дефект, если разработчик игры громко не утверждает обратного.
Пришло время поговорить о дефектах подробнее, ведь баг багу рознь. Один может запросто привести к крашу[10] игры, а другой будет выглядеть как «невинная» опечатка в слове на кнопке. «Какая разница? – скажешь ты. – Любой баг – это враг, которого нужно беспощадно уничтожать!» Это правда, но, как ты помнишь, над игрой могут трудиться множество людей, которые заняты множеством важных дел. И, наверное, они не будут очень рады, если каждый раз, получая от тебя отчет о дефектах, они будут видеть там бескомпромиссное «Свистать всех наверх! Бросайте все дела и срочно исправьте опечатку в меню!» Дефекты можно классифицировать по ряду признаков. Зачем это нужно? Чтобы лучше понимать, насколько большую опасность для проекта они представляют и как нужно с ними бороться. Другими словами, чтобы правильно определять их критичность.
Тот самый мотылек, закоротивший контакты реле в компьютере. Запись гласит: «Первый подтвержденный случай обнаружения бага»
2.1. Отчет о дефекте (баг-репорт)
Отчет о дефекте (также известный как баг-репорт) – это документ, который описывает ошибку, неисправность или проблему, найденные в программном продукте, в том числе игровом. Это важный инструмент для команд разработки и тестирования, поскольку он помогает им понять, исправить и отслеживать проблемы в продукте. Это документ, который ты должен научиться разрабатывать в первую очередь. Отчет создается только для ОДНОГО дефекта.
2.1.1. Атрибуты отчета о дефекте
Описание дефекта, а фактически задача для разработчика, как правило, содержит следующие обязательные атрибуты.
1. Краткое описание (Summary)
2. Подробное описание (Description)
3. Шаги воспроизведения (Steps)
4. Ожидаемый результат (Expected Result)
5. Фактический результат (Result)
6. Критичность (Severity)
7. Приоритет (Priority)
В разных компаниях и проектах могут использоваться дополнительные атрибуты для описания дефекта, но перечисленные выше составляют обязательное ядро. Рассмотрим их подробнее.
Краткое описание (Summary) – название атрибута говорит само за себя. Задача тестировщика – максимально кратко и в то же время понятно описать найденный дефект. Иногда тестировщики говорят: «Всегда есть Description, где можно описать баг во всех деталях», но разработчики считают суперабилкой тестировщика именно его способность описывать баги кратко и понятно. Это объясняется простым фактом: в Jira и других баг-трекерах разработчик видит задачи списком, каждая задача представлена кратким описанием. Теперь представь, что таких задач (баг-репортов) несколько сотен, больше половины из которых непонятны без прочтения Description. Представь только, сколько времени потеряет разработчик для вникания в суть проблемы. И как он будет называть при этом тестировщика. Кроме того, при грамотном написании Summary в огромном списке задач довольно легко находить дубликаты.
Способность описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.
Метод «Что? Где? Когда?»
Нет, это не связано с привлечением знатоков из одноименного интеллектуального клуба. Этот способ подразумевает описание, которое дает ответы на три следующих вопроса.
1. Что произошло и в чем суть неполадки?
2. Где был обнаружен дефект?
3. Когда и при каких обстоятельствах возник дефект?
Это довольно действенный способ, и я рекомендую взять его на заметку.
Метод выделения ключевой информации
Весьма действенный метод, особенно когда у тебя уже есть длинное описание дефекта.
1. Попробуй описать дефект со всеми необходимыми деталями.
2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.
3. Попробуй сложить эти ключевые моменты вместе.
То, что получится в итоге, и будет составлять Summary.
Метод тождественности атрибутов
Составь описание дефекта по следующей схеме.
1. Шаги воспроизведения
2. Ожидаемый результат
3. Полученный результат
Если все описано правильно, то «Полученный результат» и будет являться Summary дефекта. Если нужно, можешь добавить пару важных деталей.
Но вернемся к прочим атрибутам дефекта.
Подробное описание (Description) – это поле служит для того, чтобы тестировщик мог добавить более подробное описание и дать больше деталей. Здесь указывается любая дополнительная информация, относящаяся к багу, которая может помочь в исправлении дефекта.
Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.
Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.
Критичность (Severity) – это основное, чем баги отличаются друг от друга. Определяя Критичность, ты информируешь разработчика, что тобой был выловлен баг, бажик или бажище.
Приоритет (Priority) – это фактически скорость, с которой разработчики должны отреагировать на найденный дефект. Похоже на то, как скорая помощь реагирует на разных больных: на скорость реагирования влияют признаки, характеризующие степень тяжести больного. В большинстве случаев определением приоритета занимается менеджер проекта или тест-менеджер, обладающий большей информацией о проекте и продукте, но иногда тестировщик также может выразить свое мнение по этому вопросу.
Про эти два важнейших атрибута я расскажу более подробно чуть ниже.
Традиционно ответственность за определение критичности найденных дефектов лежит на тестировщиках. Они обладают исчерпывающими знаниями контекста, в котором появился баг, и того, насколько серьезно его влияние на игровой процесс.
А вот чтобы определить приоритет, нужно гораздо больше информации: понимание загруженности команд разработки, потенциального влияния дефекта на репутацию разработчика и массу другого. Поэтому определением приоритета занимается как минимум руководитель той команды, которая допустила и будет исправлять дефект, а в идеальном случае – менеджер проекта или продюсер, ответственный за разработку.
Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.
Повторяемость (Reproducibility)[12] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 20 % (из 5 проверок) и когда он повторяется 2 из 5 раз. В первом случае повторяемость дефекта будет равной 1 из 5 раз, а во втором – в два раза чаще.
Дарья Касиманова, QA-менеджер Saber Interactive
Аналогом Reproducibility является Repro Frequency (частота воспроизведения) в описании дефекта компьютерной игры. Это мера, которая указывает на то, как часто возникает или воспроизводится определенный дефект или проблема в игре. Это важный параметр при тестировании и отладке игр: он помогает разработчикам определить, насколько критична проблема и как срочно ее необходимо решать.
Чем выше Repro Frequency, тем более часто возникает проблема и, возможно, тем более важно ее устранение, особенно если это критический дефект, который может повлиять на игровой процесс или создать негативное впечатление у игроков. Разработчики игр стремятся уменьшить Repro Frequency до минимума, чтобы обеспечить более стабильный и приятный опыт игры для всех пользователей.
Вложения (Attachments) – это материалы, иллюстрирующие проблему.
Для начала посмотрим, что именно может быть использовано в качестве Вложений.
1. Изображения
2. Видеофрагменты
3. Логи (файлы системных журналов)
4. Звуковой файл
5. Другие файлы
Все эти файлы нужны в основном для того, чтобы лучше продемонстрировать возникшую проблему. Как говорится, лучше один раз увидеть, чем три раза прочитать баг-репорт. Тестировщики используют разнообразное программное обеспечение (ПО) для создания таких файлов. Например, для создания изображений часто используется ПО, позволяющее делать снимки произвольных областей экрана и редактировать их «на лету».
Для создания видеофрагментов в тех случаях, когда нужно продемонстрировать дефект в динамике (например, когда персонаж упирается в невидимые стены на уровне), используется ПО, позволяющее записывать и обрабатывать видеофрагменты.
В нагрузочном тестировании не обойтись от встроенных системных утилит для демонстрации загрузки процессора или памяти.
В общем, во время тестирования используются десятки различных вспомогательных программ, пользоваться которыми необходимо уметь всем игровым тестировщикам для проведения качественного тестирования и составления хорошего отчета о дефектах.
Вложения в баг-репорте обязательны и играют важную роль по нескольким причинам.
• Скриншоты, видео и логи помогают точно показать, что происходит при возникновении ошибки. Это позволяет разработчикам видеть проблему глазами пользователя и лучше понимать контекст.
• Вместо того чтобы тратить время на попытки воспроизвести проблему по текстовому описанию, благодаря вложениям разработчики могут сразу же увидеть, что не так. Это сокращает время на нахождение и исправление бага.
• Текстовые описания могут быть интерпретированы по-разному. Визуальные и другие вложения уменьшают неоднозначность, предоставляя конкретные доказательства проблемы.
• Логи и дампы памяти могут предоставить ценную информацию о состоянии системы в момент возникновения ошибки. Это помогает разработчикам понять, какие процессы или условия могли способствовать возникновению проблемы.
• Вложения помогают обеспечить более четкое и эффективное общение между теми, кто сообщает о баге, и теми, кто его исправляет. Это сокращает количество необходимых вопросов и уточнений.
• Вложенные файлы могут быть использованы для анализа тенденций и выявления корневых причин проблем, выходящих за рамки конкретного баг-репорта.
• В целом вложения делают баг-репорты более информативными, упрощают и ускоряют процесс их обработки и увеличивают шансы на то, что баг будет успешно исправлен.
Нина Резниченко, QA-менеджер Saber Interactive
В идеале после чтения саммари бага и просмотра вложения (прикрепленный файл – скриншот, видео, логи и т. д) должно быть понятно, в чем проблема и как ее фиксить. Если при взгляде только на прикрепленный к багу файл понятно, в чем баг, то поздравляю, вы достигли вершины искусства. Не стоит пренебрегать скринами даже, казалось бы, в простых проблемах. Сделать скрин и прикрепить его к багу занимает всего пару секунд, а бонус выходит +100 к ясности.
Часто можно встретить баги с названиями вроде «Неправильное отображение иконки». У меня к таким багам сразу вопрос: что значит неправильное? А как правильно? Или «Работает некорректно». Хорошо, а как корректно? Почему бы сразу не написать, в чем проблема, избегая выход на такие абстракции?
Уточнив, в чем проблема (например, иконка отображается лоу-резно, с темными краями и т. д.), и прикрепив дополнительно скрин или видео, вы сэкономите время как себе (потому что за уточняющим вопросом придут к вам), так и исполнителю.
Мой совет: всегда старайтесь уйти от широких понятий или давайте конкретные числа и данные, если все же их используете. Например, вы описываете баг про Low FPS. Укажите в цифрах, сколько это Low – 10–15 (5 и т. д.)? Кому-то и 60 мало:)
2.1.2. Критичность дефекта (Severity)
Суммируя сказанное выше, любая ошибка, найденная тестировщиком, должна быть описана как можно подробнее. Для этого в отчете о дефектах, который может представлять собой как обычную таблицу, так и задачу типа «баг» в одном из баг-трекеров[13], у любой ошибки есть атрибуты, которые необходимо заполнить. Эти сведения должны помочь тому, кто будет исправлять эту ошибку, сделать это наиболее рациональным способом.
Давай посмотрим на дефект с точки зрения степени его влияния на возможность использования игры, то есть попытаемся определить его критичность. Для этого тестировщику нужно проанализировать совокупность следующих факторов.
1. Степень влияния на работоспособность игры, то есть насколько сильно дефект затрудняет игровой процесс.
2. Степень заметности для пользователя – насколько дефект заметен для большинства игроков[14].
3. Степень влияния на удобство использования – насколько дефект ухудшает удобство игрового процесса.
Только анализ всех этих факторов вместе позволит получить правильное представление о критичности бага.
С точки зрения критичности принято выделять следующие виды дефектов.
Blocker (Блокирующий, Блокер) – самый критичный и самый заметный дефект, который вызывает самые большие трудности при использовании игрового продукта. Более того, блокер, как правило, – это такой дефект, который не позволяет нам больше играть, и обойти это препятствие не представляется возможным. Помнишь синий экран смерти в Windows? Вот это как раз пример блокера! Другими примерами могут стать «вечный» фриз, утечка памяти и многие другие неприятные вещи. Но есть и хорошая новость для тестировщика: ты никогда не пропустишь блокер, если увидишь его, это просто нереально. Ты внезапно теряешь контроль над игровым процессом и получаешь его назад только после полной перезагрузки. Хотя и в этой ситуации, если подходить строго, блокеры можно разделить на софтлок (softlock) и хардлок (hardlock).
Софтлок – это случаи, когда игрок, например, постоянно погибает в месте воскрешения или автосохранение игры происходит как раз в момент гибели персонажа. Другими словами, формально игра продолжает работать, но все, что может делать игрок, – бесконечно повторять одни и те же действия без прогресса и возможности откатиться назад.
Хардлок – это ситуация, при которой игра перестает воспринимать любые команды ввода и единственный выход из ситуации – перезагрузка.
Представь, что ты находишься в комнате, в которой нет окон, дверь заперта, а ключа нет: выйти из нее невозможно.
Critical (Критический) – этот баг очень похож на предыдущий. Он тоже может превратить игровой процесс в кошмар и выглядит как начало Армагеддона, но, в отличие от предыдущего дефекта, предполагает некий способ выхода из ситуации. Например, появляющееся каждые пять минут окно с ошибкой, останавливающее игровой процесс, можно закрыть, нажав Alt+F4, и продолжить игру.
В той же комнате, в которой ты оказался в первый раз, кроме запертой двери есть окно, в которое можно с трудом выйти. Люди не должны выходить в окна, но это альтернативный приемлемый выход из ситуации, не так ли?
Major (Значительный). Значительными называются дефекты, которые осложняют использование основных функций игры: движение персонажа, использование необходимых предметов, переходы на другие уровни, получение наград и т. д. Они также могут полностью блокировать второстепенный функционал: выполнение отдельных квестов, способы перемещения по карте, взаимодействие моделей и т. д.
В комнате есть дверь, но она открывается только на такую ширину, что тебе придется выдохнуть весь воздух и снять часть одежды, чтобы протиснуться в проем. Ужасно неудобно, но выйти все же можно.
Minor (Незначительный). Обычно такие баги не относятся к функционалу игры или влияют на него в очень незначительной степени. Тем не менее баг заметен и очевиден для тестировщика и для пользователя. Чаще всего так определяется дефект, который затрудняет нам удобство использования игрового продукта, раздражает игрока или связан с недочетами интерфейса. Очень часто в эту категорию попадают мелкие рендер-баги[15], отсутствие коллизий с какими-то неважными объектами на сцене и т. п.
В комнате есть и окна, и дверь, и последняя открывается довольно широко. Но вот замочная скважина в ней находится на уровне колен, и ключ при открывании немного заедает в замке. И если дверь не заперта, то на это и не обращаешь внимание, но когда замок закрыт… Впрочем, все это сущие мелочи.
Trivial (Тривиальный, Мелкий). Баг также не относится к функционалу игры, и иногда его можно принять за незначительный дефект. Его сложнее обнаружить, а кто-то даже вообще не посчитает его багом (что, конечно, неверно). Чаще всего к подобным дефектам относят различные опечатки, несовпадение цветов (конечно же, если речь не идет об опечатке в названии игры, в названии официальной консольной периферии или, например, цвета являются официальными, как цвета национального флага или логотипа фирмы) и т. д.
Дверь в комнате выглядит шикарно! Отличный замок, который безупречно открывается таким же отличным ключом. Впечатление может испортить разве что цвет внутренней ручки, на полтона отличающийся от цвета ручки на внешней стороне двери.
2.1.3. Приоритет дефекта (Priority)
Обнаружив дефект и оценив его критичность, необходимо понять, как быстро этот дефект должен быть устранен. Это важный вопрос, поскольку не всегда устранить дефект можно немедленно. Более того, обычно тут же это сделать не удается никогда, потому что разработчики заняты разработкой новых версий игры (билдов) или функционала. Поэтому нужно понять, как требование по немедленному устранению дефекта повлияет на весь процесс разработки.
Как правило, приоритет дефекта бывает трех видов.
1. High (Высокий)
2. Medium (Средний)
3. Low (Низкий)
и он часто (но не всегда) совпадает с критичностью. Например, Блокирующий или Критический дефект будет в обычной ситуации иметь самый высокий приоритет для исправления. И если с определением приоритета для упомянутых дефектов трудностей не возникает, то с дефектами другой степени критичности могут быть проблемы. Для определения приоритета исправления дефекта необходимо учитывать следующие факторы или их совокупность.
• Финансовые потери компании
• Репутационные потери компании
• Воспроизводимость дефекта
• Увеличение сроков разработки либо трудозатрат
Установка приоритета – это довольно сложный процесс, который отличается от определения критичности и относится к техническим аспектам. Приоритет вполне легко может быть определен по совокупности технических параметров. Давай рассмотрим несколько примеров.
Пример № 1. В игре только у одного персонажа имеется изображение свастики. Это дефект локализации; нужно определить его критичность и приоритет.
Дефект вообще никак не влияет на техническую сторону игрового процесса. Он малозаметен (есть только у одного персонажа) и не ухудшает удобство использования продукта. Здесь мы будем выбирать между Minor и Trivial в зависимости от того, насколько сложно найти этого персонажа в игре.
Но мы планируем выпуск этой игры на рынок Германии, где изображения «антиконституционной символики», к которой относится вся символика национал-социалистической партии, запрещены под угрозой уголовного наказания. Так что приоритет меняется: такой дефект должен быть исправлен немедленно.
Пример № 2. При попытке купить дополнительную колоду карт в игре пользователь случайно выбрал государство Науру из выпадающего списка в качестве региона местонахождения, и это привело к крашу игры.
Очевидно, что любой краш, приводящий к отказу работы может быть сразу же отнесен к блокирующим дефектам. Но стоит ли выставлять максимальный приоритет, если вероятность его повторения в реальной жизни весьма призрачна?
Еще один пример – высокая повторяемость дефекта. Если незначительный дефект становится чересчур назойливым для большого количества пользователей, то, скорее всего, стоит повысить приоритет и исправить его, пока это не переросло в более серьезную проблему. Как раз для этого и служит атрибут Reproducibility или Repro Frequency.
Важно знать, что ответственность по определению приоритета дефекта почти всегда лежит на стороне менеджеров проекта, поскольку тестировщик не может обладать знаниями о текущей загрузке команды разработки, приоритетов заинтересованных лиц, последствий, которые может вызвать тот или иной дефект в релизе, и т. д. Однако никто не запрещал даже в такой ситуации высказать свое мнение, особенно если ты уверен в этом на 100 % и тебя поддерживают коллеги.
2.1.4. Признаки плохого баг-репорта
Отчет о дефекте – это фактически задача для разработчика по устранению выявленного тестировщиком дефекта. Для того чтобы задача была решена эффективно и быстро, она должна быть корректно сформулирована.
Представь, что, будучи программистом, ты получаешь от коллеги-тестировщика задачи по исправлению дефектов со следующими описаниями.
1. Персонаж погибает
2. Противник не атакует
3. Транспортное средство отказывается ехать[16]
Кроме проблем с выражением собственных мыслей на родном языке, можно выделить дополнительные признаки того, что существенно ухудшает восприятие и понимание баг-репорта разработчиками.
1. Непредоставление точной информации, которая может помочь в устранении дефекта.
2. Непредоставление критически важной информации, например в какой тестовой среде проводилась проверка.
3. Обнаружение дефекта в функционале, не предназначенном для тестирования.
4. Предоставление в любых полях баг-репорта недостоверной информации.
5. Отчет содержит сленговые и жаргонные слова, а также различные аббревиатуры и термины, понятные не всем.
6. Дефект содержит критику в сторону разработчиков.
7. Выставление заведомо неверного уровня критичности.
8. Отчет содержит большое количество языковых ошибок, не позволяющих понять смысл.
9. Непредоставление вложений: логов, дампов, скриншотов, без которых разработчик не видит дефекта.
10. Тестировщик не смог убедить разработчиков в критичности дефекта.
Сравни два примера ниже. Это два реальных баг-репорта, написанных тестировщиками-новичками. Какой из них ты считаешь более правильным?
Пример № 1
Пример № 2
Хорошая практика для тестировщика – перечитывать, а еще лучше рецензировать (а в самом начале карьеры тестировщика это обязательно должен делать руководитель проектной группы – лид) написанное в отчете о дефекте на предмет понятности, лаконичности и наличия важной информации.