Шрифт:
Освободившись от этих навязчивых мифов, ты теперь можешь приступить к освоению нелегкого ремесла игрового тестировщика. Я помогу тебе освоиться с важнейшими, фундаментальными принципами и подходами в нашей профессии, помогу даже подготовиться в сдаче экзамена и получения международного сертификата игрового тестировщика ISTQB® Certified Tester Game Testing. Но опыт ты должен будешь приобрести сам. И я очень рассчитываю, что по прошествии времени ты войдешь в число лучших специалистов в области игрового тестирования.
Глава 02. Самая большая ошибка – не исправлять ошибки
Чем больше надежд мы возлагаем, тем сильнее может быть разочарование…
Genshin Impact• Что такое дефект?
• Чем дефекты отличаются друг от друга?
• Что такое баг-репорт и для чего он нужен?
• Что такое критичность дефекта и как ее правильно определить?
• Что такое приоритет дефекта?
• Что такое жизненный цикл дефекта?
• Когда и почему появляются дефекты?
• Как снизить риск их появления?
• Где место тестирования в разных моделях разработки?
• Как тестировщик взаимодействует с заинтересованными лицами проекта?
Выше я говорил о процессе тестирования как о процедуре сравнения ожидаемого результата с реально полученным и заявил, что любое расхождение между ними и есть дефект, если разработчик игры громко не утверждает обратного.
Пришло время поговорить о дефектах подробнее, ведь баг багу рознь. Один может запросто привести к крашу [10] игры, а другой будет выглядеть как «невинная» опечатка в слове на кнопке. «Какая разница? – скажешь ты. – Любой баг – это враг, которого нужно беспощадно уничтожать!» Это правда, но, как ты помнишь, над игрой могут трудиться множество людей, которые заняты множеством важных дел. И, наверное, они не будут очень рады, если каждый раз, получая от тебя отчет о дефектах, они будут видеть там бескомпромиссное «Свистать всех наверх! Бросайте все дела и срочно исправьте опечатку в меню!» Дефекты можно классифицировать по ряду признаков. Зачем это нужно? Чтобы лучше понимать, насколько большую опасность для проекта они представляют и как нужно с ними бороться. Другими словами, чтобы правильно определять их критичность.
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. Что произошло и в чем суть неполадки?