В преддверии старта курса "Game QA Engineer" публикуем текстовую расшифровку онлайн-интенсива, который провела Надежда Чертовских — руководитель отдела QA в компании BeresnevGames и преподаватель OTUS.   Цели интенсива: познакомиться с основными видами тестовой документации; проанализировать документ от game-дизайнера; попрактиковать составление чек-листа.  Для начала давайте обсудим такой животрепещущий вопрос: почему сегодня на курсе «тестировщик игр» мы обсуждаем документацию? Как тестировщик, который целый день только в игры играет и сообщает разработчикам об обнаруженных ошибках, связан с документацией? Какая вообще работа у тестировщика игры? Какие у тестировщика могут быть документы?  Существует распространённое заблуждение, что тестировщик игр целый день только и делает, что в игры играет. Но на самом деле это не так. Тестировщик в геймдеве точно  такой же тестировщик, как и в любой другой сфере, и работает точно по такому же принципу, но продукт у него не web-страничка, не application на операционной системе, а игра (мобильная, консольная, десктопная).  На интенсиве мы поговорим в целом об артефактах тестирования, с которыми работает тестировщик: План тестирования (Test Plan)  Тест-кейс (Test Case)  Чек-лист (Check-List) Баг-репорт (Bug Report) Отчёт о тестировании (Test Report) Инструкция (Manual) Из этого мы можем сделать вывод, что тестировщик не только читает требования, которые подготовили к продукту, но и сам генерирует документы.  В ходе интенсива мы более подробно поговорили о 6 типах документов, которые перечислили выше, обсудили, какие из них полезные, какие используются чаще, какие меньше и составили чек-лист по требованиям.  План тестирование (далее ПТ) или тест-план – это большой документ, который чаще всего описывает весь объем работ по тестированию проекта либо части проекта (например, релиза или предрелизного билда). ПТ описывает, что будет тестироваться, в какие сроки, какими инструментами, какая команда, обязанности и ответственности каждого члена команды. Также часто в ПТ включается стратегия тестирования, график релизов на  несколько ближайших спринтов. В зависимости от команды бывает разная степень детализации ПТ и его могут делать разные люди в команде. В каких-то компаниях ПТ делает менеджер, в каких-то middle-тестировщик, либо senior-тестировщик, либо тимлид отдела тестирования.  Всё, что мы далее обсудим по документам, которые генерирует тестировщик, может отличаться от компании к компании, от команды к команде. В зависимости от команды и компании форм-фактор всех документов может быть либо уже обговорён и установлен, либо, если вы приходите первым QA специалистом на проект, то вы сами устанавливаете, как удобно вам. Форм-фактор у тест-плана может быть разный (схема, интеллектуальная карта и т.д.) и зависит от того, как команде будет удобнее взаимодействовать с документами.  Чаще всего ПТ требуется именно для людей, которые принимают решения по проекту, чтобы они поняли, что в следующий момент мы делаем: релизим билд или нужно подвинуть сроки, добавить к тестированию, убавить к каким-то другим срокам. И лучше всего не делать ПТ огромным, чтобы человек, который будет его читать, смог осилить весь объём. Если посмотреть примеры тест-планов в интернете — часто это одностраничная схема, чтобы все в общем и целом понимали, какой объем тестирование предстоит. Обычно план тестирования делается до начала тестирования и до момента релиза.  Таким образом План тестирования: описывает стратегию тестирования, цели, график, оценку, результаты, а также ресурсы необходимые для тестирования; имеет разную степень детализации; имеет разный форм-фактор; составляется не более, чем на 2-х страницах; составляется до начала тестирования. Оставляю здесь шаблон на тест-план Пример тест-плана с сайта с сайта www.guru99.com Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно.  Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца.  Тест-кейсы можно группировать в смысловые блоки. Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента.  Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет. Составляющие тест-кейса:  идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться); название сценария (какое-то краткое, но ёмкое);  ссылка на требования ГДД; предусловия (опционально, если они требуются для тест-кейса); шаги сценария; ожидаемый результат; фактический результат (опционально). Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований.  Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного.  Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу. Небольшой пример из игры нашей студии: есть поле для ввода имени питомца и есть несколько условий на этом поле: имя питомца должно состоять из более чем 2 символов и только в этом случае кнопка из серой неактивной станет зеленой активной и можно будет питомца наименовать. Мы начинаем формировать чек-лист к этому полю если количество символов больше 2 то кнопка принять становится активное, если меньше 2 не активно. Первые 2 пункта чек-листа, которые можно проверить.  На скриншоте мы видим, как игрок из Китая захотел назвать питомца очень коротким ёмким именем и, к сожалению, не смог это сделать и обращался в тех. поддержку. В результате ему пришлось выдумывать более длинное имя. Ссылка на mindmap чек-лист для мобильной игры: Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов.  Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему.  В баг-репорте обязательно должны быть: Подробное описание проблемы – что, где, когда случилось.  Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков.  Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг. Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага.  Доказательства – скрины, видео, логи с устройств. Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании. Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы.  Отчет о тестировании может быть представлен как текст, таблица, график или диаграмма, если это позволяет инструмент.  Составляющая отчёта о тестировании: Кто тестировал (состав команды). Когда тестировал (даты проведения тестов). Как тестировал (процесс тестирования, описание применяемых методов и технологий). Какие возникли проблемы и как решились.  Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде. С помощью инструкции можно быстро сориентироваться в проекте.  Например, вышел новый функционал. Лучше написать инструкцию, как этот функционал проверить, как переключаться, если проверка нового функционала подразумевает переключение между версиями или предусматривает какой-то сложный алгоритм проверки. Это экономит время на объяснения, когда требуется делегировать задачу либо в команду пришел новый человек и нужно его обучить.  Также инструкция помогает выгрузить старое и не потерять. Скорость выпуска релизов в геймдеве довольно высокая и часто есть необходимость вернуться к старому функционалу, который ранее уже  тестировался, но прошло какое-то время и тестируется новый функционал, а нужно вернуться к проверке того старого. Поэтому лучше всего, чтобы было прописано, как  тестировать, где тестировать, что и куда переключать. Лучше всего все в картинках, гифках или видео. Сегодня современные инструменты всё это позволяют сделать быстро и без проблем. Также ели есть возможность сохранять какие-то состояния проекта, состояния продукта, то лучше где-то всё это фиксировать и выкладывать в общем доступе.  Инструкции лучше писать сразу. Это позволяет избежать множество проблем в дальнейшем. Где хранить: Google Docs, Google Sheets Cucumber (Hip Test) Test IT Zephyr, Test Management for Jira Qase Notion TestRail В геймдизайнерском документе гейм-дизайнер пишет требования к продукту или к отдельному функционалу.  Детализация у геймдизайнерского документа может быть разная. Форм-фактор также может быть разным.  Существует несколько способов проверки требований к игре: по принципу Что? Где? Когда? или по принципу проверки на полноту, однозначность, непротиворечивость, тестируемость, необходимость, осуществимость. После того как геймдизайнерский документ готов лучше всего, если его прочитают и вместе обсудят специалист по тестированию, разработчик и сам гейм-дизайнер.  Тестировщику в этом случае следует задавать следующие вопросы: не противоречит ли те требования, которые гейм-дизайнер написал, функционалу, который сейчас есть, не будут ли нововведения противоречить наративу, функциям и механикам, которые есть в игре сейчас.  Требования геймдизайнерского документы должны пониматься всеми однозначно, что исключает какого-либо двоякого толкования.  Важно смотреть на полноту содержания: все ли условия предусмотрены, все ли сценарии, которые могут возникнуть у игрока в связи с новым функционалом продуманы.   Разработчик смотрит на возможность реализации ГДД. Также необходимо  продумать, как новый функционал будет тестироваться, после того как разработчик его реализует.  Практическая часть интенсива. Мы попробуем сформировать чек-лист и вопросов гейм-дизайнеру по новому продукту на основе ГДД. На картинке мы видим 3 скрина игры.  скрин – изображение и кнопка Play, при нажатии на которую, мы попадаем в игровой mod скрин – на старте есть какое-то количество жизней и шагов скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.  Итоги интенсива: Узнали, какие бывают виды документации у тестировщика игр. Обсудили зачем тот или иной документ нужен. Попрактиковались в создании чек-листа.  Список материалов для самостоятельного изучения: Блог Ольги Назиной (Киселевой) Форум сайта Software testing  Блог LernQA   Шаблоны документов для тестирования программного обеспечения StrongQA Статьи на Habr, DTF Конференции (QualityConf, SQADays, …) Каналы и чаты в telegram Поиск в Google Узнать подробнее о курсе Game QA Engineer можно здесь. Редактор