У нашій команді зараз 9 чоловік, лід – один. Велика частина команди разом з лідом знаходиться в Рівному, але тестувальники є і в київському, і в дніпровському офісах. Команда зростає, тому що планується запуск нових проектів і постійно зростає навантаження. Зараз випускаємо багато фіч, набагато більше, ніж раніше.

 

Спочатку ми тестуємо документацію.

Почнемо з того, що по нашому процесу тестувальник включається в процес складання документації. Це допомагає закласти в дизайн фічі те, що могло б вилізти вже на етапі тестування. Читаємо специфікації, складені геймдизайнерами, розбираємося, як функціонал повинен працювати, як це перевіряти, закладаємо час на перевірку. Це дуже важливий крок. Уже на етапі тестування технічного завдання можна виявити критичні баги. Відразу, навіть якщо фічу не бачив в очі, можна сказати, що не зайде, що потрібно поправити, а що викинути, і де додати плюшки користувачеві ?

Тестувальники багато знають про те, як фічі взаємодіють між собою, на що може вплинути зміна в грі. Саме в цьому наша функція. Справа не в тому, що геймдизайнери чогось не знають, вони намагаються прораховувати всі дрібниці. Але QA перевіряють, як це все в грі гармонує між собою, і виходячи з досвіду задають додаткові питання.

Не буває так, що ось є фіча, є специфікація до неї, все гладко і ідеально. Завжди виникають додаткові питання. Ми радимося з геймдизайнерами, з програмістами, разом придумуємо, як краще зробити.

 

Головне – щоб був діалог. Щоб всі могли висловити свою точку зору, а потім шукати консенсус.

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

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

Дивимося акцію, перевіряємо баланс, налаштування інтеграторів. Це займає десь місяць. Тестуємо в білдах: спеціальних версіях додатка з новим контентом для релізу. Релізні білди викладаються на релізний сервер, звідки ми їх качаємо. Лід планує спринти на кожен тиждень і навантаження на кожен день.

 

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

Тест-кейс – це опис кроків, які потрібно зробити для перевірки функціоналу, і результат, який потрібно в кінці отримати. Для кожного тест-кейса закладаємо час на виконання + час на ризики, на випадок, якщо щось піде не так. З досвідом цей час визначається досить точно ?

Час на ризики потрібно закладати на випадок поломок: наприклад, ми перевіряємо і бачимо, що немає монстрів на карті. Це блокер, найсерйозніша помилка, яку обов’язково потрібно пофіксити. Ми заводимо баг і перевіряємо далі. Але розраховуємо, що потім потрібно буде перевірити фікс – і на це піде додатковий час.

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

 

Наш набір тест-кейсів формувався протягом останніх трьох років.

Якщо функціонал змінюється, ми актуалізуємо тест-кейси. Старі зберігаємо в архів – на випадок якщо потрібно буде підглянути, як тестували раніше.

Стандартні перевірки намагаємося час від часу тасувати між учасниками команди. Від них нікуди не дінешся, перевіряти обов’язково потрібно, навіть якщо робили це в попередніх апдейтах. А тасуємо тому, що перевіряти одне і те ж нудно, та й професійного розвитку так не буде.

Коли виходить новий контент, додаються кейси та перевірки. Цього разу зробили нове вікно діалогу, вікно підвищення рангу – грубо кажучи, освіжили UI. У наступному апдейті (1.38) теж будуть оновлення, щоб гра йшла в ногу з часом. Намагаємося розподіляти роботу так, щоб кожному дісталося щось новеньке.

 

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

В середньому, щоб відтворити баг, потрібно зробити 5-7 кроків. Це ідеальний баг. Якщо кроків менше, взагалі супер. А ось два роки тому у нас був баг, який відтворювався більше ніж за 30 кроків! І баг був серйозний, здається, краш додатку. Залишилося навіть відео з відтворенням цього бага – хвилин на 7! Ми пару місяців цим займалися і знайшли, як скоротити кількість кроків до 10-12.

 

Ідеального тест-кейсу не існує.

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

 

Тестувальникам обов’язково потрібно грати в свою гру.

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

Ще ми постійно граємо в ігри конкурентів, не тільки hidden object, а й інших жанрів. Стежимо за новинками, які з’являються, за апдейтами.

Іноді знаходимо баги, звичайно ? Але некритичні.

 

Але взагалі для спеціаліста, особливо нового, головне – бажання. Щоб очі горіли!

Карантин не дуже ускладнив нам життя: дистанційна робота у нас давно налагоджена. Ми і раніше співпрацювали з хлопцями з інших офісів. Хіба що раніше часто їздили у відрядження, щоб спілкуватися наживо.

Коли працюєш в офісі, деякі питання можна вирішити одним поглядом ? І, звичайно, є завдання, які набагато зручніше розбирати особисто. Наприклад, була проблема у тих, хто грав на кількох девайсах. Якщо забув оновитися на одному, після входу в стару версію може щось зламатися. Щоб це виправити, додали вікно завантаження оновлень: поки не оновиться, в гру не пускає. Тестувати цю фічу було складно. Так що приходили разом з разробнцею в суботу, сідали поруч з ноутами і разом розбиралися.

А тепер більше часу йде на листування. Але працюємо як і раніше злагоджено.

 

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

В кінці перед апдейтом всі у нас в кабінеті ?  Потрібно все протестувати. Іноді доводиться чергу записувати в блокноті: мовляв, ти четвертим будеш! У нас нечасто почуєш фразу “це не баг, а фіча”, та й то – тільки в жарт. Наші програмісти таким не займаються. У нас всі відповідальні, поважають один одного, і робота будується на довірі.

 

У перші дні після релізу ми ретельно моніторимо співтовариство в фейсбуці.

Там багато цікавого пишуть: і хороше, коли задоволені оновленням, і не дуже хороше теж ? І баги, буває, знаходять. Наприклад, людина пише, що у нього не стартувала закачка контенту. Ми можемо написати: дізнатися докладніше про проблему, порадити, як її виправити (перевстановити гру, наприклад). Часто звертаємося до хлопців з відділу саппорта, щоб вони дізналися у користувачів побільше про якийсь баг.

Ще після релізу дізнаємося у аналітиків, як гравцям зайшла акція, які відгуки, який краш рейт.

 

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

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

 

Найцікавіше в роботі тестувальника – це реліз без багів.

Правда, це як єдиноріг: в природі не буває. Тому ми задоволені, коли просто обходиться без критичних багів і крашів на продакшені.