Назад
“Главное, чтобы глаза горели!” – о команде тестирования AB Games

ноября 25, 2020

“Главное, чтобы глаза горели!” – о команде тестирования AB Games

В нашей команде сейчас 9 человек, лид – один. Большая часть команды вместе с лидом находится в Ровно, но тестировщики есть и в киевском, и в днепровском офисах. Команда растет, потому что планируется запуск новых проектов и постоянно растет нагрузка. Сейчас выпускаем много фич, гораздо больше, чем раньше. 

Сначала мы тестируем документацию.

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

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

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

 

Главное – чтобы был диалог. Чтобы все могли высказать свою точку зрения, а потом искать консенсус.

Наш апдейт включает в себя акции (то есть тематические цепочки квестов), дополнительные задания, новых персонажей, мини-ивенты и так далее. Есть механики, которые проверяем из апдейта в апдейт, а есть новые.

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

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

 

Мы проверяем тест-кейсами.

Тест-кейс – это описание шагов, которые нужно сделать для проверки функционала, и результат, который нужно в итоге получить. Для каждого тест-кейса закладываем время выполнения + время на риски, на случай, если что-то пойдет не так. С опытом это время определяется довольно точно 🙂

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

Потом более-менее готовый билд попадает к паблишеру. У нашего паблишера G5 есть свои тестировщики, и они уже вычищают билд до идеала вместе с нами. Они тоже смотрят акции и мини-ивенты. Мы находим гораздо больше багов, потому что начинаем проверять раньше. У них свой набор кейсов и проверок, в которых команда специализируется и проверяет со своей стороны. Одна голова хорошо а две – всегда лучше!

 

Наш набор тест-кейсов формировался в течение последних трех лет.

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

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

Когда выходит новый контент, добавляются кейсы и проверки. В этот раз сделали новое окно диалога, окно повышения ранга – грубо говоря, освежили UI. В следующем апдейте (1.38) тоже будем, чтобы игра шла в ногу со временем. Стараемся распределять работу так, чтобы каждому досталось что-нибудь новенькое. 

 

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

В среднем, чтобы воспроизвести баг, нужно сделать 5-7 шагов. Это идеальный баг. Если шагов меньше, вообще супер. А вот два года назад у нас был баг, который воспроизводился больше чем за 30 шагов! И баг был серьезный, кажется, краш приложения. Осталось даже видео с воспроизведением этого бага – минут на 7! Мы пару месяцев этим занимались и нашли, как сократить количество шагов до 10–12.

 

Идеального тест-кейса не существует.

Можно запланировать тест-кейсы до малейших деталей, опираясь на свой опыт, расспросить программиста, других тестировщиков. Но мы все равно время от времени что-то ломаем, прокликиваем, проходим нелинейно, не так, как по кейсу. Это называется исследовательское тестирование: заходишь и смотришь каждую деталь, опираясь на свой опыт. 

 

Тестировщику обязательно нужно играть в свою игру.

Без этого тест-кейс не напишешь, не будешь понимать, что проверять, с какой стороны подойти.

Еще мы постоянно играем в игры конкурентов, не только hidden object, но и других жанров. Следим за новинками, которые появляются, за апдейтами.

Иногда находим баги, конечно 😉 Но некритичные.

 

Но вообще для специалиста, особенно нового, главное — желание. Чтобы глаза горели!

Карантин не слишком усложнил нам жизнь: удаленная работа у нас давно налажена. Мы и раньше сотрудничали с ребятами из других офисов. Разве что раньше часто ездили в командировки, чтобы общаться вживую.

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

А теперь больше времени уходит на переписку. Но работаем по-прежнему слаженно.

 

У нас в компании тестировщик – лучший друг программиста.

В конце перед апдейтом все у нас в кабинете 🙂 Нужно всё протестировать. Иногда приходится очередь записывать в блокноте: мол, ты четвертым будешь! У нас нечасто услышишь фразу “это не баг, а фича”, да и то – только в шутку. Наши программисты таким не занимаются. У нас все ответственные, уважают друг друга, и работа строится на доверии.

 

В первые дни после релиза мы тщательно мониторим сообщество в фейсбуке. 

Там много интересного пишут: и хорошее, когда довольны обновлением, и не очень хорошее тоже 🙂 И баги, бывает, находят. Например, человек пишет, что у него не стартовала закачка контента. Мы можем написать: узнать подробнее о проблеме, посоветовать, как ее исправить (переустановить игру, например). Часто обращаемся к ребятам из отдела саппорта, чтобы они узнали у юзеров побольше про какой-то баг.

Еще после релиза узнаем у аналитиков, как игрокам зашла акция, какие отзывы, какой краш рейт.

 

Перед введением некоторых изменений проводятся АБ-тесты.

Например, хотим упростить квесты в первой акции. Если сделаем это сразу, а игрокам не понравится, посыпятся жалобы или упадут показатели. Поэтому сначала проверяем на небольшой группе: например, берем 50% игроков. 25% упрощаем квесты, а остальным 25% – нет. Аналитики собирают статистику, как игроки на это реагируют. Если игрокам понравилось, мы уже в следующий апдейт или через один вводим новую штуку.

 

Самое интересное в работе тестировщика — это релиз без багов. 

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