Недавно довелось пообщаться с Алексеем Нелюбовым — QA-директором компании Datcroft Games. Сейчас ребята работают над мобильным ММО Action Pixel Wars, проект находится в стадии софтланча. Отдел тестирования сопровождал игру на каждом этапе ее развития, и я решил, что из рассказа Алексея выйдет неплохая статья на хабр.
Далее — прямая речь.
У Pixel Wars долгая и непростая история. Руководствуясь бизнес-целями, мы начали сборку первых прототипов игры в 2016 году. В дальнейшем концепция была полностью переработана с учетом изменившихся реалий рынка, и в софтланч “Пиксели” вышли в конце 2018-го. В ближайшем будущем планируется коммерческий релиз проекта.
Лид отдела распределяет задачи, присутствует на всех совещаниях, создаёт тестовые планы, ставит задачам приоритеты, а также выступает в роли тест-аналитика.
Далее есть три опытных сотрудника, не один год стоящих на страже качества игры. Один из них с недавних пор плотно подсел на автотесты — создаёт скрипты по кейсам на самописной тулзе.
Недавно к нашей команде присоединился молодой и перспективный специалист (сначала он пришел к нам на обучающие курсы, затем попал на стажировку — и вот теперь он в штате), который уже решает множество интересных задач, от проверки карт до написания простых автоматизированных скриптов. И скоро мы ждём ещё одного.
У нас большой парк тестовых девайсов, от стареньких побитых жизнью телефонов до суперсовременных устройств с новейшими ОС и функционалом. Порой бывает интересно выловить баг только на одном планшете, потому что у него особый жёсткий диск, и потом пытаться воссоздать соответствующие условия в студии разработки.
Как известно, в итерационных моделях тестирование начинается с завершением формирования технического задания и высокоуровнего дизайна. Так работает и у нас. Мы вычитываем ТЗ до того, как его начнут реализовывать, отсматриваем макеты новых интерфейсов, проверяем «серые коробки» карт, смотрим на расчеты математики в документах геймдизайнеров.
На моменте реализации мы не ждем, пока все правки зальют в master, а активно тестируем отдельные части функционала в отдельных ветках. Им может не хватать красивой графики, вместо персонажа может бегать розовый конус, а на карте вместо деревьев и кустов будут стоять серые бочки. Но проверить функционал мы уже можем.
Нередки случаи парного тестирования с разработчиком на его компьютере — сильно экономит время на сборки. Если программист обычно смотрит только тот функционал, который он сделал или поправил, и только позитивные кейсы, то тестировщик может сразу найти баги в негативных кейсах плюс по опыту знать, что именно этот программист в этом модуле мог сломать. Ещё помогает анализ влияния: например, всегда, когда правят код гильдий, что-то случается с функционалом друзей. Почему бы не проверить этот момент сразу?
Когда же все отдельные куски кода, графики, эффектов, звуков и локализации слиты в мастер, наступает время интеграционного и системного тестирования. Смотрим, как новые фичи работают друг с другом, и проводим масс-тесты со всей командой. Нередко тут вылезают баги вроде «мне неудобно» или «не ощущаю интереса», которые также фиксируются и обрабатываются. Мы смотрим не только на функциональные характеристики, но и на то, как игра ведет себя при большой нагрузке, «плохом» интернете и в различных неидеальных средах, вроде поездки в автобусе через город или подвале бизнес-центра.
И вот, все явные баги исправлены, все новые штуки готовы увидеть свет. Можно заливать на прод? Конечно, нет. Нужно мнение представителей всех отделов и некоторых реальных игроков. Одновременно начинается регрессия (время больших автотестов) и приемочное тестирование. Если с первым всё понятно (проверяем весь функционал игры, дописываем устаревшие кейсы, добавляем новые, проверяем и их), то про приёмку мало кто говорит. А вещь полезная. Мы рассылаем билд в общий канал проекта и призываем всех в течение пары дней поиграть и оценить игру “со своей колокольни". Тут может выясниться, что геймдизайнеры вовсе не так представляли фичу ямы с кольями, хотя всё сделано по описанию и макетам, а маркетингу нужен ещё один скин персонажа-воина для акции в соцсети. Когда все пожелания учтены, мы идём к продюсеру — главному человеку на проекте. Он дает добро, и тогда начинается процесс заливки версии на прод. На данный момент мы зарелизились только в Google Play. Всё действо занимает от получаса до часа.
Когда всё готово, мы не сразу снимаем плашку профработ. Сперва надо самим убедиться, что рейтинги рисуются, платежи проходят, игры запускаются, а новые фичи попали к игрокам.
Далее процесс начинается заново.
Часто, чтобы проверить игру, её не требуется запускать. Есть существующая механика, в которой изменили какие-то параметры. Отлично, скачиваем свежий репозиторий, смотрим соответствующий xml-файл и закрываем таск. Порой баги повторяться не хотят. Например, кто-то из партнёров играл в наш проект в метро, в это время у него зазвонил телефон, а интернет с 3g переключился на wifi без доступа к глобальной сети. При этом на устройстве кончилось место и перегрелась батарея. Но невоспроизводимых багов у нас нет, есть те, до которых ещё руки не дошли.
Конечно, бывает, что баги вылезают на прод. И если пользователи нашли такой, то мы, скорее всего, его тоже нашли. Просто у него низкий приоритет или воспроизводимость, поэтому фикс отложили на два месяца.
Редко, но случается доказывать программисту или ПМу, что баг — это баг и его надо чинить прямо сейчас. Например, на картах можно заходить в сейф-зону противника. Да, ты не можешь там атаковать, но это отличный способ восстановить здоровье и устроить засаду на врага. Доказал — чинят. Нет — ищи более веские аргументы. Доводы в стиле «прикольно» или «мне не нравится» не принимаются, нужны конкретные примеры с конкретными последствиями.
Иногда нам приходилось тестировать дисконнекты, выбегая на балкон в офисе, пока не было настройки «плохого» интернета на роутере.
Чтобы имитировать наполненную сеть и проверить работу приложения в таких условиях, тестировщик специально ходит по переполненному торговому центру с телефоном.
Много багов ловится, когда делаешь дисконнект и быстро что-то переключаешь. Тут реально важна скорость тапов по экрану. Например, так нашли совершенно не очевидную ошибку: когда быстро переключаешь классы и скины персонажей, в итоге у тебя лучник держит щит или воин магический жезл.
Спасибо за внимание! Надеюсь, вам было интересно узнать больше о процессе тестирования игр.
Далее — прямая речь.
У Pixel Wars долгая и непростая история. Руководствуясь бизнес-целями, мы начали сборку первых прототипов игры в 2016 году. В дальнейшем концепция была полностью переработана с учетом изменившихся реалий рынка, и в софтланч “Пиксели” вышли в конце 2018-го. В ближайшем будущем планируется коммерческий релиз проекта.
Кто в команде?
Лид отдела распределяет задачи, присутствует на всех совещаниях, создаёт тестовые планы, ставит задачам приоритеты, а также выступает в роли тест-аналитика.
Далее есть три опытных сотрудника, не один год стоящих на страже качества игры. Один из них с недавних пор плотно подсел на автотесты — создаёт скрипты по кейсам на самописной тулзе.
Недавно к нашей команде присоединился молодой и перспективный специалист (сначала он пришел к нам на обучающие курсы, затем попал на стажировку — и вот теперь он в штате), который уже решает множество интересных задач, от проверки карт до написания простых автоматизированных скриптов. И скоро мы ждём ещё одного.
У нас большой парк тестовых девайсов, от стареньких побитых жизнью телефонов до суперсовременных устройств с новейшими ОС и функционалом. Порой бывает интересно выловить баг только на одном планшете, потому что у него особый жёсткий диск, и потом пытаться воссоздать соответствующие условия в студии разработки.
Какие задачи решают QA-специалисты?
Как известно, в итерационных моделях тестирование начинается с завершением формирования технического задания и высокоуровнего дизайна. Так работает и у нас. Мы вычитываем ТЗ до того, как его начнут реализовывать, отсматриваем макеты новых интерфейсов, проверяем «серые коробки» карт, смотрим на расчеты математики в документах геймдизайнеров.
На моменте реализации мы не ждем, пока все правки зальют в master, а активно тестируем отдельные части функционала в отдельных ветках. Им может не хватать красивой графики, вместо персонажа может бегать розовый конус, а на карте вместо деревьев и кустов будут стоять серые бочки. Но проверить функционал мы уже можем.
Нередки случаи парного тестирования с разработчиком на его компьютере — сильно экономит время на сборки. Если программист обычно смотрит только тот функционал, который он сделал или поправил, и только позитивные кейсы, то тестировщик может сразу найти баги в негативных кейсах плюс по опыту знать, что именно этот программист в этом модуле мог сломать. Ещё помогает анализ влияния: например, всегда, когда правят код гильдий, что-то случается с функционалом друзей. Почему бы не проверить этот момент сразу?
Когда же все отдельные куски кода, графики, эффектов, звуков и локализации слиты в мастер, наступает время интеграционного и системного тестирования. Смотрим, как новые фичи работают друг с другом, и проводим масс-тесты со всей командой. Нередко тут вылезают баги вроде «мне неудобно» или «не ощущаю интереса», которые также фиксируются и обрабатываются. Мы смотрим не только на функциональные характеристики, но и на то, как игра ведет себя при большой нагрузке, «плохом» интернете и в различных неидеальных средах, вроде поездки в автобусе через город или подвале бизнес-центра.
Как происходит приемка версии?
И вот, все явные баги исправлены, все новые штуки готовы увидеть свет. Можно заливать на прод? Конечно, нет. Нужно мнение представителей всех отделов и некоторых реальных игроков. Одновременно начинается регрессия (время больших автотестов) и приемочное тестирование. Если с первым всё понятно (проверяем весь функционал игры, дописываем устаревшие кейсы, добавляем новые, проверяем и их), то про приёмку мало кто говорит. А вещь полезная. Мы рассылаем билд в общий канал проекта и призываем всех в течение пары дней поиграть и оценить игру “со своей колокольни". Тут может выясниться, что геймдизайнеры вовсе не так представляли фичу ямы с кольями, хотя всё сделано по описанию и макетам, а маркетингу нужен ещё один скин персонажа-воина для акции в соцсети. Когда все пожелания учтены, мы идём к продюсеру — главному человеку на проекте. Он дает добро, и тогда начинается процесс заливки версии на прод. На данный момент мы зарелизились только в Google Play. Всё действо занимает от получаса до часа.
Когда всё готово, мы не сразу снимаем плашку профработ. Сперва надо самим убедиться, что рейтинги рисуются, платежи проходят, игры запускаются, а новые фичи попали к игрокам.
Далее процесс начинается заново.
Еще несколько фактов
Часто, чтобы проверить игру, её не требуется запускать. Есть существующая механика, в которой изменили какие-то параметры. Отлично, скачиваем свежий репозиторий, смотрим соответствующий xml-файл и закрываем таск. Порой баги повторяться не хотят. Например, кто-то из партнёров играл в наш проект в метро, в это время у него зазвонил телефон, а интернет с 3g переключился на wifi без доступа к глобальной сети. При этом на устройстве кончилось место и перегрелась батарея. Но невоспроизводимых багов у нас нет, есть те, до которых ещё руки не дошли.
Конечно, бывает, что баги вылезают на прод. И если пользователи нашли такой, то мы, скорее всего, его тоже нашли. Просто у него низкий приоритет или воспроизводимость, поэтому фикс отложили на два месяца.
Редко, но случается доказывать программисту или ПМу, что баг — это баг и его надо чинить прямо сейчас. Например, на картах можно заходить в сейф-зону противника. Да, ты не можешь там атаковать, но это отличный способ восстановить здоровье и устроить засаду на врага. Доказал — чинят. Нет — ищи более веские аргументы. Доводы в стиле «прикольно» или «мне не нравится» не принимаются, нужны конкретные примеры с конкретными последствиями.
Иногда нам приходилось тестировать дисконнекты, выбегая на балкон в офисе, пока не было настройки «плохого» интернета на роутере.
Чтобы имитировать наполненную сеть и проверить работу приложения в таких условиях, тестировщик специально ходит по переполненному торговому центру с телефоном.
Много багов ловится, когда делаешь дисконнект и быстро что-то переключаешь. Тут реально важна скорость тапов по экрану. Например, так нашли совершенно не очевидную ошибку: когда быстро переключаешь классы и скины персонажей, в итоге у тебя лучник держит щит или воин магический жезл.
Спасибо за внимание! Надеюсь, вам было интересно узнать больше о процессе тестирования игр.
