Що автоматизація може зробити для мобільних ігор і де ручне тестування все ще працює краще

Привіт, я — Інна Мокрова, QA інженер компанії SciPlay. Свою кар’єру в IT я розпочала майже 10 років тому як manual QA і дуже щаслива, що обрала таку «ненудну» сферу як геймдев. Вже півтора роки я беру участь у надзвичайно цікавому процесі — запровадженні автоматизації тестування ігор. У цьому дописі я хочу поділитися кількома практичними порадами від команди QA мобільної гри Solitaire Pets Adventure. Я розповім, які частини процесу тестування можна автоматизувати з самого початку, щоб якнайшвидше отримати переваги для процесу розробки гри. Також продемонструю, що в деяких випадках ручне тестування все ще є кращим вибором.

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

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

Що може зробити автоматизація для вашої мобільної гри

Автоматизація тестування потребує ресурсів — досвідчені фахівці, час, техніка, середовище. З самого початку вона вимагає набагато більше, ніж дає. Для тестування мобільних ігор вам насправді потрібно написати власний фреймворк, який складається з багатьох інших фреймворків, бібліотек і скриптів — деякі з них є стандартними продуктами (Selenium, NUnit, NLog тощо), інші інструменти повинні бути підготовлені командою розробників. Наприклад, розробники Solitaire Pets Adventure створили скрипт для «перекладу» структури ігрових об’єктів Unity у формат xml, щоб зробити їх доступними для Selenium. Також було підготовано API для роботи з CMS.

Автоматизація регресійних тестів: end-to-end підхід

Припустімо, ви вклали ресурси та вже підготували свій фреймворк, тестове середовище та навіть запустили свій перший авто-тест. Що ж далі? А далі вам потрібно вивести автоматизацію на рівень, коли вона приносить дивіденди вашій грі, які можна виміряти та продемонструвати.

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

Регресійні тест-кейси Solitaire Pets Adventure побудовані за end-to-end підходом, що означає тестування основних сценаріїв (game flows) з позиції кінцевого користувача. Ми відтворюємо ті самі кроки, що і користувач, та перевіряємо поведінку гри і цілісність вихідних даних. Цей підхід дуже зручний для автоматизації — натисніть кнопку, перевірте спливаюче вікно, валідуйте дані у ньому та порівняйте з даними у базі.

Автоматизуйте те, що потрібно перевіряти, але бракує часу

У більшості казуальних мобільних ігор є спільні риси та функціонал, наприклад — квести/місії; анонси з call to action (CTA) кнопками; out of coins/out of lives flow тощо. Давайте розглянемо місії: користувач отримує прогрес у місії, виконуючи дію з певними параметрами в грі — граючи в конкретному ігровому режимі, збираючи предмети, виграючи гру тощо. У Solitaire Pets Adventure ми маємо принаймні 10 типів місій, 5 параметрів у кожній, ще й потрібно пройти позитивний і негативний сценарії для кожної з них. Звичайно, manual QA не мають достатньо часу, щоб проходити всі ці тест-кейси під час кожної регресії. Але, чесно кажучи, вони мають це робити.

Ця ігрова функція є ідеальним кандидатом для автоматизації також тому, що більшість тестів дуже схожі, і, написавши один авто-тест, QA може написати всі інші досить швидко.

Іншим хорошим прикладом функціональності, яка тестується на регресії поверхнево через брак часу, є різні типи анонсів. Кнопка на анонсі може відкривати різні частини гри, для показу анонсів використовуються різноманітні тригери та умови. У Solitaire Pets Adventure ми автоматизували щонайменше 20 тест-кейсів і на даний момент готуємо ще стільки ж.

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

Виявляйте баги на ранніх стадіях

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

У Solitaire Pets Adventure кожна нова збірка сервера автоматично розгортається на тестовому середовищі, а авто-тести виконуються щовечора на останній збірці клієнта. Після виконання всіх тестів команда QA отримує електронний лист зі звітом про те, скільки тестів пройшло успішно, а скільки — невдало. Тест-кейси, які «не пройшли», необхідно дослідити.

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

Де ручне тестування все ще є кращим вибором

Розробка мобільних ігор — це дуже динамічна сфера, де постійно відбуваються зміни. Кожні кілька років гра змінює дизайн, постійно з’являються нові функції, які замінюють старі — нові game flows, нова логіка, нові спливаючі вікна тощо. І чим більше у вас авто-тестів, тим більше ресурсів вам потрібно для їх підтримки. Іншими словами, з одного боку, автоматизація допомагає заощадити час, а з іншого — ви повинні інвестувати багато часу, щоб підтримувати авто-тести в актуальному стані.

Ось кілька цікавих висновків, до яких ми з колегами дійшли, працюючи над автоматизацією гри Solitaire Pets Adventure.

На все свій час

Коли розробку нової фічі (feature) завершено та вона стала доступною користувачам, насправді це ще не означає кінець розробки. У більшості випадків зацікавлені сторони просять внести зміни, і ці зміни можуть бути величезними. Якщо ви починаєте автоматизувати «свіжий» функціонал одразу після розробки, вам доведеться ще кілька разів переписувати авто-тести відповідно до змін у фічі. Ефективніший спосіб протягом деякого часу тестувати новий функціонал вручну. Коли нова функція стане стабільною, можна писати тестові сценарії для автоматизації та робити їх частиною continuous delivery.

Покриття коду авто-тестами не є чимось стабільним, і це нормально, коли воно зменшується після розробки кількох нових функцій. Це просто означає, що ваша гра змінюється та розвивається, і ваші інструменти також змінюються. У Solitaire Pets Adventure ми нещодавно зіткнулися з ситуацією, коли замість 260 авто-тестів у нас залишилося лише 140. Це сталося після того, як наша гра змінила напрямок і було видалено багато функціоналу, а розробка нового ще не завершилась. Команда QA також переглянула авто-тести та видалила нерелевантні тест-кейси. Розробка нових тестів зайняла певний час.

Те, на що здатне лише людське око

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

Авто-тест сам по собі не зможе «розпізнати» миготіння, артефакти в анімації, інші візуальні баги. В той же час усі ці проблеми елементарно виявляються під час мануального тестування. Лише людина може «відчути гру» та оцінити досвід користувача, а це дуже важлива частина тестування ігор. Ви не можете створити щось справді круте, якщо не граєте у свою гру, чи не так?

Уникайте складних тестів

Написання автоматизованих тестів для охоплення функціональності, яка виходить за межі вашого додатку, є дуже складним завданням. Наприклад, BI-events, відправка даних стороннім системам і т. д. Надто складно написати end-to-end тест та воно й не варте тих зусиль. Це саме ті випадки, коли мануальне тестування працює краще, ніж авто-тести.

Одним із прикладів такої «складності» є тестування push-повідомлень. Це дуже важлива функція для мобільних ігор, яка впливає на утримання користувача (retention). Для реалізації функціоналу push-повідомлень розробники інтегрують у гру сторонню бібліотеку. Потенційним джерелом помилок є конфлікт між мобільною операційною системою (ОС) і цією бібліотекою, тому важливо тестувати push-повідомлення принаймні на кількох версіях ОС для обох платформ (Android, iOS). У цьому випадку запуск авто-тестів потребуватиме кількох тестових пристроїв. Насправді, кращим вибором буде надати ці технічні ресурси в руки QA.

Резюме

Автоматизація тестування — це «медаль з двома сторонами», як і всі інші речі в цьому світі. З одного боку, це ідеальний засіб, щоб уникнути виснажливої ​​процедури регресії. А з іншого — це також код, який потрібно тестувати, відслідковувати та підтримувати в актуальному стані.

Але ви ніколи не розчаруєтеся, якщо матимете правильні очікування щодо можливостей автоматизованого тестування, і відразу зрозумієте, що шлях до успіху полягає в розумному поєднанні автоматизації та старого доброго manual QA. Абсолютно нормально відразу відмовитися від автоматизації певних тестів і залишити їх для ручного тестування. Навіть якщо вам вдасться автоматизувати 20-30% набору регресійних тестів, це вже дасть вам непоганий результат.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному1
LinkedIn


Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Стаття загалом офігенна, дякую!

Побажання/рекомендації. Доу останнім часом грішить на назви і гучні заголовки. Це все працює в плані залучення читача, так. Але часто — не відповідає дійсності на сто відсотків.
Я би не порівнював напрямки тестування з точки зору якоїсь «кращості». Все ж перед нами напрямки, які мають трохи різні цілі та задачі. Бо це схоже на порівняння тролейбусу та велосипеду, або ноти «ля» та ноти «ре». Та і до того ж — краще завжди працює те, що працює.
Плюс до всього цього ми маємо пам’ятати, що не всі типи тестування можливо взагалі покрити автотестами. Тому це трохи непорівнювані речі)

Дійсно, в чомусь ви праві. Але, спілкуючись з колегами, я досить часто чую щось типу «А що, у вас ще досі не все автоматизовано? А у нас от-от звільнять останнього мануала». Є, навіть, компанії, які спочатку запрошують людей на курси QA, а потім кажуть, що мануальне тестування вже не актуальне, ідіть на курс автоматизації.

Колеги ще незрілі інженери значить. Або керівництво компанії не розуміє суті питання, не є спеціалістами в сфері, чи технічно непідковані.
Це загальна проблема галузі

Підписатись на коментарі