Як General QA створював Noviora з AI: RPG для реальних навичок і погляд на розробку через тестування

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, спільното DOU! Я Максим, General QA і розробник Noviora — мобільного RPG-додатку для розвитку реальних навичок. Створюю його за допомогою AI. Хочу поділитися тим, як досвід тестування впливає на розробку власного продукту, показати, що вже можна спробувати, і запросити вас до обговорення.

Розробляв Noviora переважно ночами: вдень була основна робота, тож на власний застосунок час знаходив уже після неї. У такому режимі розробка зайняла майже вісім місяців. AI допомагав рухатися вперед, але додаткових годин у добі поки не навчився генерувати :)

Ідея: реальні дії як частина пригоди

В основі Noviora — бажання зробити навчання, рух, творчість і повсякденні корисні справи цікавішими через квести та розвиток героя. Користувач обирає завдання, виконує дію в реальному житті, отримує XP і бачить свій прогрес. Ігрова винагорода має підкреслювати зроблене.

Моя мета була створити застосунок, у який хочеться заходити з цікавості, а не з почуття провини. Після робочого дня мені самому навряд чи потрібен ще один цифровий керівник із питанням «Чому план не виконано?». Хотілося додати до розвитку трохи гри, гумору й несподіваних відкриттів. AI та сучасні можливості телефона дають для цього багато інструментів: персональні квести, роботу із зображеннями, доповнену реальність. Для мене важливо, щоб ці технології робили досвід веселішим і цікавішим, а не просто поповнювали список функцій.

Наприклад, можна взяти практичний квест, пройти навчальну тему з перевіркою знань або спробувати новий рецепт. У застосунку є тематичні сезони, Academy, Atlas, гільдії та власні квести, зокрема, створені за допомогою AI. Adventure Map додає дослідження місць до ігрової подорожі.

Ще мені хотілося дати друзям можливість ділитися власними квестами — трохи як передавати таски в Jira. Бо чому тільки айтівці мають страждати від призначених задач? Нехай і друзі поза IT відчують цю корпоративну магію :) Звісно, жартую. Ідея — запропонувати одне одному щось цікаве: приготувати страву, спробувати нове заняття чи вирушити на прогулянку. Такий собі дружній «а тобі слабо?» у форматі квесту.

Я також реалізував фотоверифікацію для окремих квестів: користувач може підтвердити результат фотографією, яку перевіряє AI відповідно до умов завдання. Це частина конкретних сценаріїв, а не обов’язкова фотосесія після кожної корисної дії. Умовно кажучи, хочеться дати людині привід щось зробити, а не найняти їй ще одного аудитора сніданку :)

Ще одна реалізована механіка — AR із 3D-реліквіями. Користувач досліджує маршрут і через камеру бачить віртуальний об’єкт у реальному оточенні. За відчуттям, це трохи «піди знайди покемона», тільки замість Пікачу — реліквія, а побічний ефект пригоди — ти таки вийшов погуляти. Мені подобається, коли телефон стає приводом помітити щось навколо себе й перетворює звичайну прогулянку на маленьке відкриття.

Приклад квесту: опис, конкретні кроки та одна основна дія. Український інтерфейс Noviora.

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

Багато ідей я обговорював із дружиною. Вона часто вмикала режим справжнього CEO й блокувала чергову мою геніальну задумку :) А ще давала корисні зауваження, які я потім реалізовував у застосунку. Тож у Noviora було й домашнє продуктове рев’ю — пройти його іноді виявлялося складніше, ніж автоматизовані тести.

Де в цьому AI, а де відповідальність розробника

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

Для QA це знайома територія: уточнити очікувану поведінку, знайти неоднозначність, продумати негативні сценарії та перевірити результат. У власному продукті ці навички потрібні ще до появи коду. Саме тому мені цікавий цей досвід на перетині QA, розробки й AI.

Чому React Native та Expo

Для такого проєкту у React Native є практичний сенс: спільна TypeScript-кодова база для значної частини iOS- та Android-застосунку, компонентний інтерфейс і доступ до нативних можливостей телефона. Квести, прогрес, профіль і каталог можна розвивати в одному стеку. Платформні відмінності при цьому залишаються — особливо коли доходиш до реклами, покупок, дозволів і 3D. «Одна кодова база» звучить заспокійливо. Android та iOS час від часу нагадують, що на двох у них різні характери.

Expo дає зручний робочий цикл: запуск, development builds, модулі для можливостей пристрою та інструменти складання через EAS. Для Noviora це спосіб організувати мобільну розробку в межах одного набору інструментів. Водночас у проєкті є нативні конфігурації й код, тож розуміти, що потрапляє у збірку, все одно доводиться.

Тут легко переплутати Expo та Expo Go. Expo Go зручний для початкових перевірок, але має заздалегідь визначений набір нативних бібліотек. Коли застосунку потрібен власний рекламний SDK чи нативний модуль, потрібна власна development build. Змінив JavaScript — часто достатньо перезавантаження. Додав нативну залежність — потрібна нова збірка. Десяте натискання Reload її, на жаль, не замінює. Цей поділ описаний у документації Expo.

Мобільний клієнт побудований на React Native, Expo і TypeScript. Для стану використовується Zustand, для навігації — React Navigation. Серверна частина спирається на Supabase та Edge Functions. Анімації й візуальний зворотний зв’язок реалізовані з використанням Reanimated, Lottie та SVG.

Локалізація працює через i18next. Зараз підтримуються українська, англійська, словацька, корейська та німецька. Для такого продукту переклад стосується також завдань, навчального контенту, повідомлень і станів помилок.

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

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

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

Далі — каркас застосунку: TypeScript, навігація, шар стану, локалізація, базові компоненти й development build на цільовому пристрої. На цьому етапі важливо перевірити, що проєкт справді збирається і запускається. Особливо якщо вже відомо, що будуть камера, реклама чи інші нативні інтеграції.

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

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

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

Apple і Google теж мають свої критерії приймання

Тим, хто планує власний мобільний продукт, я б радив читати вимоги магазинів ще під час проєктування. Авторизація, робота з даними, дозволи, реклама, покупки та підписки впливають на реалізацію. Перед поданням варто звірити актуальні App Review Guidelines і правила Google Play, а також перевірити, чи відповідають описи, скриншоти та декларації про дані реальній поведінці застосунку. Успішно зібраний білд — це ще не квиток у магазин.

І не дай боже вирішити, що яблучко на кнопці входу буде гарніше, якщо його трохи перемалювати, пофарбувати в золото й додати магічне сяйво :) У моїй RPG це могло б стати легендарною реліквією, але для Sign in with Apple є конкретні правила оформлення. Apple вимагає використовувати офіційну графіку логотипа, а кастомні кнопки перевіряє App Review. Тому системна кнопка або оформлення за офіційними вимогами — значно спокійніший шлях. У Google для кнопки входу теж є власний брендгайд. Жарт жартом, а такі деталі я б включав у критерії готовності разом із перевіркою самого входу.

Офіційні вимоги: App Review Guidelines, правила Google Play, правила Sign in with Apple, брендгайд Google.

Реклама: кнопка одна, станів багато

Інтеграція rewarded ads добре показала, чому «підключити SDK» і «зробити функцію» — різні за обсягом задачі. У Noviora використовується LevelPlay. Треба узгодити нативні залежності, конфігурацію рекламних мереж, ініціалізацію, стан згоди користувача, завантаження оголошення та обробку результату перегляду.

На Android у мене були окремі виправлення для включення Unity Ads SDK у збірку та запуску діагностичного режиму LevelPlay до старту React. Для iOS є перевірка наявності й формату AdMob App ID у нативній конфігурації. Тобто частину проблем довелося вирішувати нижче рівня React-компонентів. Кнопка вже могла бути красивою, а показувати їй було нічого.

Наступний рівень — поведінка після перегляду. Оголошення може не завантажитися, користувач може перервати сценарій, а оновлення балансу може прийти тоді, коли інтерфейс ще обробляє закриття реклами. У мене є виправлення відновлення перерваних rewarded-сесій і перевірка підтвердження нагороди. Завершення показу, зарахування результату та повідомлення користувачу потрібно перевіряти як пов’язаний сценарій.

Один конкретний баг був в Atlas: оновлення енергії змінювало залежності React-ефекту, який підписувався на рекламні події. Cleanup позначав поточну обробку як скасовану, і очікуваний попап нагороди міг не з’явитися. Виправлення відділило життєвий цикл підписки від змін поточного балансу; актуальні умови доступності читалися окремо. Я додав регресійні тести. Саме той випадок, коли для користувача «не з’явилося віконце», а для розробника — асинхронний сценарій із кількома учасниками.

Atlas: навчальні експедиції та прогрес відкриття карток. Саме тут виник описаний вище баг із показом рекламної нагороди.

Продуктивність: іноді треба перестати чекати

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

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

Окремий клас задач — 3D-реліквії. В історії проєкту є зміна завантаження спільної великої сцени на окремі моделі з кешуванням уже прочитаних сцен. Це зменшує обсяг повторної роботи під час відкриття конкретної реліквії. Кеш теж має ціну в пам’яті, тому сам факт його появи ще не означає, що всі питання продуктивності закриті.

Adventure Map: маршрут Братиславою, точки відкриттів і перехід до квесту. Карта — частина сценарію дослідження та колекціонування реліквій.

Для анімацій я зафіксував перевірку в Expo Dev Client. Плавність і відгук потрібно дивитися на пристроях, а продуктивність для користувацького релізу — вимірювати в release-збірці: режим розробки додає власні витрати. Це також підкреслює документація React Native. У цій розповіді я не наводжу приросту FPS чи відсотків прискорення: для цього потрібні порівнювані заміри до й після. Зате можна точно пояснити, яке зайве очікування або яку повторну роботу я прибрав.

Layout’и, стеки екранів і модалки-привиди

Окремим головним болем стали layout’и та переходи між екранами. Відступи, safe area, клавіатура, довші переклади, кнопки внизу модалки — усе це треба перевіряти в реальних сценаріях. Екран може чудово виглядати на скриншоті, але після відкриття клавіатури головна кнопка раптом вирушає у власну експедицію за межі видимої області.

А найпідступніший сюжет — коли екран начебто завис: усе видно, але натискання не працюють. У Noviora був конкретний випадок, коли невидима нативна модалка на iOS перехоплювала дотики в Кодексі. Віконце вже зникло для очей, а для системи ще залишалося учасником вечірки. Ось тобі й фентезі: привида не видно, зате кнопки він тримає міцно :)

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

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

Як QA-підхід впливає на процес розробки

У моєму процесі зміна проходить шлях: ідея → перевірка за продуктовими правилами → невеликий план → реалізація → перевірки → окремий коміт. Перед релізом окремо перевіряється відповідність серверної частини застосунку. Працездатність у dev-середовищі сама по собі ще не доводить готовність релізу.

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

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

Приклад екрана отриманого трофея. Такі стани винагороди мають зрозуміло показувати результат дії; це ілюстрація механіки, а не кадр описаного автотесту.

Які методи тестування є в процесі

Статичні перевірки: TypeScript і ESLint допомагають знаходити проблеми до запуску застосунку. Вони доповнюють перевірку поведінки, але не доводять її коректність.

Модульні та регресійні тести на Jest: я перевіряю окремі правила й захищаю виправлення від повторної появи помилки. Наприклад, у тестах логіки послідовних днів розглядаються повторна дія того самого дня, наступний день і пропуски. Для ризикових змін важливі граничні та негативні сценарії.

Автоматизовані UI-сценарії на Maestro: у репозиторії є перевірки онбордингу, навігації, авторизації, зміни мови та відновлення сценарію після перезапуску. Наявність сценаріїв не означає, що кожен із них запускається в кожному релізі: обсяг перевірок залежить від зміни.

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

Перевірки релізної готовності: відповідність бекенду, конфігурації та збірки; локалізовані матеріали релізу. Для візуальної поведінки й анімацій процес передбачає перевірку в Expo Dev Client. API-перевірка входу не замінює перевірку OAuth через інтерфейс, а успішна збірка — реальної покупки чи відтворення реклами на пристрої. Межі конкретного прогону важливо фіксувати у звіті.

Як організувати проєкт і роботу AI-агентів

У Noviora правила роботи з репозиторієм зібрані в AGENTS.md, а продуктова поведінка та інженерний процес описані окремо. Це дає агенту постійний контекст: яку задачу вирішує продукт, які обмеження треба врахувати та що перевірити перед завершенням роботи. Зокрема, зміни мають бути в межах задачі, враховувати всі підтримувані мови й завершуватися перевіркою та окремим комітом.

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

Так само важливий беклог. У проєкті я веду окремий список задач зі стабільними ID, статусами та критеріями готовності. Статус має спиратися на код і перевірки: що вже реалізовано, що зроблено частково, а чого ще немає. Для незавершеної задачі важливо залишити конкретний наступний крок і посилання на потрібні матеріали. Запис «доробити рекламу» — це радше побажання на ніч, ніж задача для агента.

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

Ілюстрація з Noviora для контенту в розробці: мудреці пишуть наступні пригоди. Приблизно такий вигляд має мій беклог у фентезі-всесвіті :)

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

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

Якщо залучати кількох агентів, я б розділяв незалежні задачі: дослідження, реалізацію та перевірку конкретного результату. Для паралельних змін потрібні узгоджені межі файлів або окремі worktree, а після об’єднання — перевірка інтеграції. Це рекомендація щодо організації роботи; сама кількість агентів не забезпечує якість результату.

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

Чому цей кейс може бути цікавим спільноті

Для General QA це можливість обговорити, як досвід перевірки систем допомагає створювати власні: формулювати вимоги, бачити ризики, будувати автоматизацію та визначати критерії готовності. З появою AI особливо цікаво, як змінюється співвідношення часу на написання коду, його осмислення та перевірку.

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

Запрошую спробувати Noviora

Noviora вже доступна для iPhone. Є безкоштовні можливості та необов’язкові покупки. Детальніше про застосунок: noviora.app . Встановити: apps.apple.com/...​/app/noviora/id6761079858 .

Буду вдячний, якщо підтримаєте проєкт: спробуєте пройти перший квест, поділитеся враженнями або розкажете про Noviora тим, кому такий формат може бути цікавий. Особливо корисно почути, де було незрозуміло, що сподобалося і чого забракло для наступного кроку.

Якщо знайдете помилку, допоможуть модель пристрою, версія iOS і короткі кроки відтворення. Також цікава ваша думка: як би ви організували перевірки такого продукту та яку роль бачите для QA у розробці з AI? Дякую за ваш час, тестування й чесні коментарі!