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

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

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

Також, вважається тестувати ігри є важче через наявність ігрової механіки, через це колоссальну варіативність, тому складну локалізацію багів.

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

Буває такі баги складно документувати. Можливостей, де щось могло піти не так — море. Велике число проблем просто фіксуються як improvement (покращення).

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

Типові ролі серед тестувальників ігор:

Game QA, тестувальник — головні обов’язки Game QA виявлення та документування дефектів ігор. Bug-report -и повинні бути конкретними, містити точні описи того, як можна відтворити помилку, скріни, записи скрінрекордерам..

Game QA відповідають за перевірку того, щоб гра працювала й не крешилась, була простою у використанні, дії героїв мали сенс, у грі був веселий геймплей.

Game producer, Release Manager — відповідає за встановлення термінів тестування відповідно до маркетингу та етапів процесу розробки. Керують, затверджують строки релізів та вимоги до якості.

Lead tester, QA test lead — тестувальник, який тісно співпрацює з гейм-дизайнерами, художниками та програмістами, особливо до кінця проекту. QA test lead несе відповідальність, щоб не було дублікатів багів, баги позначені у баг-репортах, як помилки виправлялись. На етапах альфа- та бета-тестування QA test lead координує співпрацю зовнішніх тестувальників. Працює з керівництвом.

SDET (Software Development Engineer in Test) or Technical Testers — або по-суті тестувальни автоматизатори. Відповідають за створення автоматизацію деяких тест-кейсів, а також за управління складними тестовими завданнями, такими як загальна продуктивність і безпека гри. Зазвичай ці люди мають сильні навички програмування. Наявність цієї ролі залежать від студій. Багато ігор розроблено без будь-яких технічних фахівців цього напряму.

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

Отже, процес тестування гри:

Identification (Ідентифікація): логічно, перш за все, нам необхідно проаналізувати правила гри і визначити чи початково у поведінку програми не закладено помилки. Тестувальник відразу може побачити проблеми і помилки при постановці завдань. Може побачити неописані сценарії або помилки логіки.

Analysis (Перевірка): на етапі коли вже написаний код, потрібно переконатися, що всі функціональні можливості гри справджуються, гра працює відповідно до очікувань гравців.

Reporting (Звітність): повідомлення розробникам про баги виявлені у грі з повним описом і у встановленому форматі.

Verification (Аналіз): перевірка чи баги виправлені розробниками не мали іншого впливу на програму.

Так, само не має стандартних методів тестування ігор. У кожного видавця свої напрацювання і методологія тестування. Застосовувана методологія постійно удосконалюються і може відрізнятися для різних типів ігор (наприклад, методологія тестування MMORPG буде відрізнятися від тестування казуальної гри).

Про різновиди ігор ми розповідали у дописі:

Читайте конспект, корисне інфо: Тестування ігор — поговоримо що таке гра, складові частини гри

Види тестування ігор

Functional Testing — найчастіше асоціюється з фразою “тестування гри”, оскільки має на увазі гру в якійсь формі.

Функціональне тестування означає протестувати:

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

Перевірка візуальної складової — наприклад: Правильно стоять об’єкти на карті? Ніякі дерева не літають в повітрі? Земля, підлога присутня? Світло не б’є з землі? Стіни навколо є з текстурою стін або підлоги?

Тестування ігрового рушіяУ першу чергу це перевірка того, як саме відображається той чи інший об’єкт. Особливо чітко таке тестування можна уявити, якщо уявити гру від першої особи. Те, що ми бачимо на екрані, має бути тим, що наш персонаж бачить своїми очима, тобто камерою. І, тримаючи це в розумі, ми перевіряємо, як виглядає те, що ми бачимо.

Тестування Фізики — це перевірка, як саме гравець реагує на предмети і події у грі фізично. Як герой швидко ходить. Як він буде стрибати і як високо. Як реагує на зіткнення зі стіною або з монстром.

Для функціонального тестування даної частини гри нам знадобиться дізнатися поняття Коллайдера.

Коллайдер це об’єкт, який при зіткненні з іншим колайдером повинен «сказати» грі відреагувати певним чином. Якщо коллайдер персонажа вперся в коллайдер стіни, це значить він повинен зупинитися. Якщо стикнувся з колайдером шипів отримав пошкодження. Обов’язково потрібно перевіряти, чи не може гравець застрягти в колайдері або провалитися під той коллайдер, під який він провалюватися не повинен. Ви і самі напевно грали в ігри, де в певні моменти персонаж гравця міг пролізти між текстурами або впасти в них, де він цього робити не повинен був. Саме це і треба перевіряти під час тестування!

Тестування Балансу складатиметься у свою чергу із складових:

1. Порівняння балансу з фактичними значеннями в грі: те, що написано у таблицях балансу, зовсім не означає, що те ж саме буде прописано в самій грі. В першу чергу потрібно отримати у гейм дизайнера таблиці, з якими необхідно звірятися і дивитися всередині гри, що фактично показує гра. Можливо, хтось щось неправильно ввів. Хтось міг помилитися, і в результаті у зброї буде ціна в 10 разів більша, ніж повинна бути. Якщо всі значення співпали з нашими таблицями — добре! Якщо немає — нам обов’язково треба скласти баг-репорт про це!

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

2. Перевірка формул — існують формули, які повинні розраховувати ту чи іншу частину ігрового процесу залежності від значень. Але у формулах можуть бути помилки. Скрізь можуть бути помилки. Формули теж пише геймдизайнер, і саме у нього ми, як тестувальники, можемо отримати інформацію: як вони виглядають, звідки вони беруть значення, яке значення має бути на виході. Коли ми дізналися інформацію, перше, що потрібно зробити — це підставити під неї прості значення. Наприклад, формула нанесення шкоди ворогові може виглядати ось так:

((Баз. Шкоди + «Сила» + шкоди від зброї) * коефіцієнт) — відсоток несприйнятливості ворога. Після того, як ми підставимо прості значення: ((2 + 1 + 2) * 2) – 15%, нам стає простіше уявити собі кінцевий результат.

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

3. Тестування процесу — гра не статична, значить не можна цілком протестувати баланс, досліджуючи його тільки в якомусь вакуумі наших цифр. Гра — це процес, і тільки в самому процесі ми можемо з’ясувати, чи працює баланс гри? Що, буде якщо задум даного розрахунку неправильний? Що повинно статися? Чи варто зробити гру простішою чи складнішою у цій частині? Чи правильно відрегульована кількість винагороди за перемогу і покарання за поразку? Потрібно давати гравцеві час на перепочинок між рівнями? Давайте поговоримо про це.

Як і всі гравці, тестувальник витрачає певні зусилля, щоб пройти від «пункту А» до «пункту Б» у грі. Але, на відміну від гравця, тестувальник по-справжньому тестує цей час і зусилля, порівнюючи їх з певними значеннями. Це така ж перевірка очікуваного і фактичного результатів! Але якщо фактичний результат можна перевірити, проходячи з «пункту А» в «пункт Б» щоразу, порівнюючи результати. То де брати очікуваний результат? Вірно запитати у Геймдизайнера! Щоб у гру добре гралося, геймдизайнер розраховує, скільки зусиль і часу буде потрібно гравцеві для досягнення мети. Наприклад: скільки монстрів йому треба вбити, щоб отримати наступний рівень? Скільки предметів продати, щоб отримати можливість купити нову зброю або обладунок? Скільки разів влучити в ціль, щоб підвищити рівень навику стрільби? Це перше джерело інформації про очікуваний результат.

Тестування дизайну рівнів — типовий баг stuck spot (коли застрягли і ні туди і ні сюди), sticky spot (персонаж застряг у об’єкті, смикається). Невидимі стіни (на кшталт пройти можна, а ніби й не можна), текстурні діри (провали невідомо куди), відсутність геометрії рівнів (стіна начебто є, але через неї можна легко проскочити).

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

Повинне буде передбачене правильне балансування, помічали? Стандартно перші рівні гри завше йдуть легше, а останні рівні більш складні. Причому їх можливо пройти. Коли якись рівень не реально пройти, бо непередбачено — баг.

Тестування балансового кільця — означає що не повинно зустрічатися такого, що герої нищого рівня, можуть вбити героїв вищого рівня. Характерно для MMORPG, але і в інших іграх зустрічається.

Тестування звуку — озвучення повинне корелювати з тим, що відбуваєтьсяу грі. Чи не має дратівливої музики? Чи не починає герой кричати там, де не потрібно? Чи не мовчить герой у відповідь там, де мав щось говорити?

Найпоширеніші баги зі звуком:

  • Distortion — помилка у відтворенні звуку, спотворення звуку.
  • Audio Drop — помилка у відтворенні звуку. Слова в діалогах пропадають, як при поганому зв’язку під час розмови по телефону. Також перепади звуку, обриви звуку.

OS and Browser compatibility (Сумісність ОС і браузера): Дуже важливо перевірити сумісність ОС і браузера. Потрібно переконатися, що вся функціональність ігрового додатку коректно працює на всіх передбачених браузерах, операційних системах і ігрових консолях, приставках.

Мобільне Тестуванняякщо гра мобільна, то до неї так само застосовні техніки мобільного тестування.

Localization testing (Тестування локалізації): перевірка правильності відображення тексту на підтримуваних мовах. Наприклад, як перекладені і пристосовані японські, корейські ігри до світового ринку і навпаки. Для забезпечення точності та якості та гарної локалізації цей вид тестування можуть проводити Game QA з регіону, де продається гра.

Локкіт (Локалізаційний файл, англ. Lockit) — документ у якому представлені всі текстові програми на всіх підтримуваних мовах.

Performance Testing (Тестування продуктивност)і: це перевірка чи здатна гра або ігровий додаток витримувати встановлене навантаження?

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

Load testing — тестування вантаження тестує межі системи, наприклад, кількість гравців на сервері MMO гри, кількість спрайтів, що діють на екрані, або кількість потоків, що працюють у певній програмі. Тестування навантаження забезпечує програмне забезпечення, яке імітує велику активність. Тестування навантаження також вимірює здатність програми працювати правильно під навантаженням.

Multi-player Testing (Тестування мультиплеєрів): перевірка чи гра здатна обробляти ігрову функціональність для всіх гравців однаково? Паралельно проводять тестування для одного гравця та для кількох гравців. На цьому етапі тестування Game QA повинні забезпечити роботу всіх методів підключення (модем, локальна мережа, інтернет).

Regression testing (Повторне тестування): тестування регресії проводиться після того, як програмісти виправили помилку. QA перевіряє, чи є помилка все ще там (регресія), і чи не проводить подібні тести, щоб побачити, чи виправлено помилку щось інше.

Compliance testing (Тестування на відповідність): це слідування чітким технічним вимогам ліцензування ігор. Наприклад, Sony публікує контрольний список технічних вимог (TRC), Microsoft публікує вимоги Xbox (XR), а Nintendo публікує набір “рекомендацій” (Lotcheck). Деякі з цих вимог є високотехнічними і виходять за межі тестування гри. Інші ж, зокрема формат стандартних повідомлень про помилки, обробка даних карти пам’яті та обробка матеріалів, захищених законодавством, захищених авторським правом (trademarked and copyrighted) належить до scope game testing. Навіть одне порушення в поданні на затвердження ліцензії може відхилити гру, і спричинить додаткові витрати на подальше тестування та повторне подання до магазинів (store) ігор. Крім того, затримка може призвести до пропуску запуску гри release, що може коштувати видавцеві гри ще більших грошових сум.

Compliance може також стосуватися регуляторних органів, таких як ESRB та PEGI, якщо гра націлена на певний рейтинг контенту гри. Тестувальники повинні повідомити про неприйнятний контент, який може бути невідповідним бажаному рейтингу. Подібно до ліцензування, ігри, які не отримують бажаного рейтингу, повинні бути повторно відредаговані, повторно перевірені та подані за додаткову плату.

Про такі види тестування як Альфа і Бета тестування — очікуйте ми поговоримо у наших майбутніх дописах.

Чит-код (Cheat Code) — частина коду гри, невеликий додаток, яке дає можливість виконувати тестування окремих частин ігор (рівнів, локацій, сцен), переходити до них без проходження великої частини гри, а також додавати необмежені ресурси персонажам (гроші, зброя і т.д.).

Далі поговоримо про банальне порівняння ігор з іншими іграми:

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

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

Як Game QA слід задавати собі запитання:

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

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.