Грабли тестирования. Какие ошибки чаще всего совершают разработчики при тестировании игр?

В этом докладе я поделюсь кейсами из своего опыта.

Но сначала немного обо мне. В IT попала 25 лет назад, когда была студентом инженерного факультета. В геймдеве — 20 лет. Из них 15 лет занимаюсь тестированием.

В «ГостТим» я с нуля подняла QA-отдел и довела его численность до 250 сотрудников.

Я с командой принимала участие в тестировании игр (в том числе ААА-тайтлов и программ, ориентированных на детей) и различных неигровых решений (онлайн-касс, онлайн-кинотеатров и прочего).

В этом докладе пойдет речь о:

• работе с требованиями;
• работе со стратегией тестирования;
• разработке тестовой документации.

Глубоко в тему самого тестирования я заходить не буду. Очень уж она обширная.

Работа с требованиями

Это, наверное, самый сложный этап работы для любой команды тестирования, поскольку на нем происходит максимальное количество коммуникаций.

На этом этапе важно:

• проговорить, какие элементы нужно протестировать;
• указать, какие именно виды тестирования необходимо провести;
• не упустить ни одной детали и не потерять коммуникацию;
• при изучении требований — выделить и уладить все неясности и спорные места.

Нередко первые проблемы появляются уже на этом этапе.

Я сталкивалась с тем, что у команды, заказывающей у нас тестирование, не оказывалось проектной документации. Иногда мне говорили, что она на самом деле есть, но в голове эксперта, который пару месяцев назад уволился.

Из-за этого приходится самостоятельно анализировать проект, готовить по нему документацию, а затем по каждому элементу или фиче просить уточнение у заказчика, правильно ли мы поняли то, как этот элемент должен работать.

Бывает, что документация есть, но представляет собой набор отдельных документов, которые находятся у разных специалистов в разных форматах и с разной степенью готовности. Как правило, это в том случае, когда у заказчика нет единой платформы, на которой бы велась документация. В итоге работа с ней обычно ведется примерно так:

• часть разделов документа находится в разработке у одного эксперта;
• другая часть — у другого эксперта;
• как только любой из них завершает работу с документом, то файлом сбрасывает в единый канал для коммуникаций;
• в итоге команда получает несколько файлов с одним названием, но разным содержанием.

Следующая проблема – это роадмап.

Но тут сразу важно понять: дорожная карта является эталоном или ориентиром, рассчитанным в первую очередь на руководство и менеджмент.

Очень распространена практика, когда получаешь документ с дорожной картой, а на деле уже — и сроки сдвинуты, и совсем иная фича в разработке, и актуализация документа не ведется.

Следующая проблема, с которой я сталкивалась на этапе работы с требованиями: не определена игровая платформа.

Например, приходит заказчик и говорит: «Вот вам игра, вам нужно пройти обучение, прогуляться по карте, пособирать лут, поубивать противников, посмотреть, какие дефекты появятся, и зафиксировать их в рамках баг-репортов». Начинаешь расспрашивать, как работает та или иная фича, ведь проектная документация как раз отсутствует. В итоге выходишь на специалистов-разработчиков, чтобы выяснить, как должен работать тот или иной элемент. После этого выясняется, что игре требуется далеко не только функциональное тестирование. Помимо этого, нужно определить системные требования, протестировать производительность, а самое главное — провести регрессионное тестирование.

Зачем нужно регрессионное тестирование? Дело в том, что продукт находится в активной стадии разработки, активно идут спринты, новые фичи вводятся и проверяются, а вот работу старых после обновлений никто не проверяет — регресс то заложить забыли.

Какие возможны решения?

В первую очередь необходимо выбрать единую платформу для ведения документации и хранения данных.

Совместная работа над документом упрощает работу всех отделов: и отдела аналитики, и маркетинга, и, конечно, отдела QA, чьи сотрудники в этом случае сразу видят оунеров фичи и описание того, как она работает.

Естественно, важно всячески способствовать тому, чтобы документация велась. Ее поддержка позволяет обнаруживать расхождения в требованиях к тестированию.

Очень часто бывает, когда в рамках проектной документации существует, допустим, 25 разделов. В разделе N1 описывается работа фичи, в разделе N25 дается отсылка на эту фичу, при этом дается иное ее описание.

Одна из задач отдела тестирования — как раз анализ подобных моментов, выявление несоответствия параметров, уточнение, как должно быть на самом деле, и указание оунеру фичи на разночтения.

Так QA-отдел выявляет дефекты функционала и способствует коррекции регламента запуска фичи в дорожной карте, актуализирует ее, позволяя понять, на работе с каким аспектом лучше ориентироваться в данный момент. В соответствии с этим перераспределяются ресурсы и их объем на решение той или иной задачи.

Все это выливается в следующий этап.

Разработка стратегии тестирования

Это очень важный этап для любой команды, поскольку определяет объемы необходимых на разработку ресурсов.

Мы сталкивались с ситуациями, когда у игры, находящейся в релизе, раз в месяц выходила новая фича, но при этом отсутствовали план тестирования и понимание того, что именно необходимо тестировать.

Бывало, когда заказчик отводил на QA только две-три недели перед релизом. В ходе тестирования выяснялось, что в игре огромное количество критических ошибок и команде приходилось идти на перенос срока релиза.

Как этого избежать?

Необходимо четко понимать, какие типы тестирования и зачем необходимо провести в рамках данного цикла разработки, расставить приоритеты.

Например, была ситуация, когда нас попросили провести тестирование производительности на этапе прототипирования. Это было экономически невыгодно, поскольку перед проектом стояла задача заинтересовать инвесторов, найти дополнительный бюджет на разработку. Это мы объяснили заказчику и посоветовали сделать акцент на функциональном тестировании.

Еще из рекомендаций, естественно, разработка тест-плана, с помощью которого как раз и возможно определить бюджет тестирования.

Следующий этап, который очень сильно влияет на бюджетирование в рамках тест-плана — это определение среды тестирования.

Как я уже упоминала, бывает так, что заказчики не задумываются о том, на какой платформе, на каком оборудовании должно проводиться тестирование.

Например, был случай: постучался к нам заказчик, который вел разработку веб-проекта. Он рассчитывал, что его игру будут запускать в основном на десктопных устройствах, поэтому хотел протестировать ее исключительно в нескольких браузерах на Windows и Mac.

В ходе переговоров выяснилось, что заказчик не в курсе о том, что сейчас огромная доля веб-трафика приходится на мобильные устройств. В итоге наша линейка конфигураций увеличилась в два раза. Появилась потребность протестировать игру и на мобильных устройствах.

В моей практике также часто бывало, когда заказчик хотел сэкономить. Он предлагал собрать для тестирования минимальную из возможных конфигурацию. Дескать, пусть специалист сразу проведет и функциональное тестирование, и оценит производительность.

К чему это приводило?

Тестировщик на минимальных спеках запускает игру. Она три минуты грузится. Сама производительность на уровне слайд-шоу. Специалист вместо багов постоянно ловит фризы. В итоге затягивается время тестирования, а вместе с этим растет его бюджет.

Какой вывод: не экономьте на тестовом окружении. Да, устройства с минимальными конфигурациями тоже должны быть, но в качестве отдельных тестовых стендов, на которых, допустим, раз в две недели будут совершаться прогоны проверки того, как произошедшие в игре изменения повлияли на производительность.

Переходим к работе с инструментами тестирования.

Сейчас очень сложно подбирать на старте проекта какие-либо инструменты из-за санкций (не знаешь, будет ли инструмент работать через полгода или год в стране). Плюс, как правило, стоимость этих инструментов довольно высока.

Про стоимость я не просто так заговорила. Поделюсь одним из наших кейсов. Около трех лет назад постучалась команда разработки, которой нужно было протестировать совместимость и производительность одного продукта в течение года. Закладывалось около 100 часов на это тестирование. При этом они хотели использовать конкретный очень нишевый инструмент, который делал определенные замеры по игре. Лицензия на инструмент стоила 5000 долларов.

Что произошло потом?

Компания потратила деньги на 100 часов тестирования и на покупку этого инструмента. В конце года мы предоставляем отчет, вот только он оказывается не нужен команде.

Так что я рекомендую перед тем, как собирать какие-то данные и тратить деньги на их сбор, взвесить все за и против, подумать, а действительно ли они потребуются.

Плюс, на фоне санкций, рекомендую присмотреться к отечественным инструментам, чтобы снизить риски.

Тестирование

Сам этап тестирования — очень многогранный, включает в себя много этапов.

Я бы хотела заострить внимание на менеджменте качества, на том, какие проблемы мы ловили командой в рамках тестирования игровых продуктов.

Очень часто мы сталкивались с тем, что не были определены критерии качества продукта. Приходилось самим составлять матрицу верификации, определять, что является блоком для релиза проекта.

Еще одна проблема: отсутствие параллельного ведения двух веток — ветки разработки и ветки стабилизации. Должно быть так: разработка фичи идет в ветке, соответственно, разработки. После релиза билд с новой фичей должен переходить в ветку стабилизации. К сожалению, очень многие разработчики этого не делают.

Также забыта практика ведения таблицы решений. Это таблица, в которой зафиксировано, какие именно объекты необходимо протестировать, а какие уже проверены.

Про игнорирование регрессов мы уже говорили. На стадии активной разработки у команд зачастую не хватает времени на то, чтобы вернуться и посмотреть, в каком состоянии находятся остальные части контента, находящиеся в игре. Больше внимания уделяется новым фичам, из-за чего могут страдать другие, ранее уже реализованные элементы. Для того, чтобы это не случилось — важно закладывать время и ресурсы на регрессионное тестирование.

Также при фокусе на функциональном тестировании некоторые забывают о том, что игра в первую очередь должна быть интересна. Для этого как раз и делается фокус-тестирование. Оно тоже должно быть заложено в план. Нужно определить целевую аудиторию и понять, интересен ли функционал тому пользователю, на которого игра ориентирована.

Распространенной проблемой является и то, что разработчики забывают об актуализации тестовой документации. Очень многие считают, что это не так уж важно, что на это нет времени, дескать, лучше пофиксим баги. Так документы сначала не обновляются месяцами, а потом годами. В итоге, когда меняется специалист, выясняется, что документация ничего не имеет общего с реальностью, а за что браться — неясно.

Тут же отмечу, что всегда нужно делать ревью тест-планов, потому что любой проект — живой. Любое появление нового контента, появление новых фич, оно требует изменения тест-плана.

Еще часто сталкиваюсь с тем, что заказчик не анализирует полученные отчеты. Почему – неясно, возможно, из боязни, что придется отсрочить релиз. Так что приходится частенько напоминать: ребята, обратите внимание, здесь у вас присутствуют такие то проблемы, их надо закрыть.

Следующая проблема в рамках менеджмента качества – это коммуникация.

Был недавно следующий кейс: команда тестирования тратила из восьми часов работы над проектом по пять часов на созвоны и обсуждения. Из-за этого страдали сроки.

Также часто сталкивалась с тем, что команды разработки на каждый созвон, который происходил, собирали всех — и разработчиков, и аналитиков, и маркетологов, и дизайнеров. Из-за этого впустую тратилось огромное количество времени на обсуждение мелочей.

Впрочем, были и обратные ситуации, когда полностью отсутствовало взаимодействие. Команды отказывались созваниваться и что-либо обсуждать. Это было не менее пагубно для проекта. Менеджмент не понимал, что происходит с продуктом. Тестировщик не понимал, как работают элементы игры. Разработчик не понимал, что ему делать, что править.

Чтобы такого не было:

• уточните каналы и форматы взаимодействия для участников команды;
• предварительно определяйте, какие моменты на каких созвонах и с кем будут обсуждаться.

После этого сократится время на коммуникацию, а задачи начнут быстрее решаться. Больше на обсуждение тасков не будет тратиться по полдня.

Ну и, соответственно, очень важна грамотная подготовка подробных баг-репортов. Чем подробнее расписан баг-репорт, тем меньше вопросов возникает у специалистов, которые разрабатывают фичу.

У меня все. Большое спасибо за внимание.