Як це — бути першим QA Engineer на проєкті. Вибудовуємо процес тестування з нуля

Всім привіт. Мене звати Ірина Ольховик. Я QA Engineer у геймдев-стартапі Suits, що входить в екосистему Genesis. Ми розробляємо гру-одяганку, в якій користувачі беруть участь у челенджах, одягають модель за дрес-кодом, а потім голосують за найкращий образ. Гра не лише розважальна, вона допомагає розвинути гарний смак.

Маю досвід тестування мобільних застосунків (не ігор), web, проте останні проєкти, де я працюю, — це суто геймдев.

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

Передумови

На двох останніх проєктах я приходила першим QA Engineer і якщо до того могла уточнити щось у колег чи поліпшувати готові процеси в тестуванні, то тут їх довелося налаштовувати з нуля. Часто я сама придумувала підходи до оптимізації, а потім виявлялося, що це вже давно best practices :)

Типовий день QA Engineer

Уявіть ситуацію: ви потрапляєте в команду, де до вас ще не було тестувальників. І бачите купу завдань у колонці Ready for testing (яка чекала, щоб саме ви її очистили). Ваші колеги паралельно розробляють новий функціонал, і Ready for testing починає розширюватися. Скоро реліз нової версії! І ви не знаєте, з чого почати, кого запитувати, як все пріоритезувати.

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

Тут варто додати, що на нашому проєкті релізи відбуваються регулярно раз на 2–3 тижні, працюємо за Agile. Це мобільна гра, написана в Unity 3D для Android та iOS платформ. Сьогодні на проєкті два QA Engineer.

Ознайомлюємося з доменною галуззю

Коли ви тільки приєднуєтеся до проєкту, насамперед варто дізнатися про:

  • цільову аудиторію;
  • головний функціонал;
  • технічну інформацію тощо.

Де дізнатися

1. Команда — обов’язково поспілкуйтеся з колегами, вони зазвичай знають найактуальнішу інформацію.

Склад команди:

  • Product Owner — може розповісти про цільову аудиторію, що від вас очікують у роботі.
  • Продуктова частина (гейм-дизайнер, аналітики, маркетологи) — у них з’ясуєте про економіку гри, з якими аналітичними плагінами працюють, які івенти є критичними, загальні відомості про користувача. Маркетологи дадуть інформацію, на які країни вони роблять ставки, за якими показниками висновують про успішну кампанію (наприклад, інстали, покупки, івент завершення певної дії в застосунку).
  • Development — розробники закцентують на технічній імплементації, скільки середовищ є на проєкті, на потенційних слабких місцях програми, які із задач у колонці Ready for testing стали менш актуальні. А також підкажуть, як робити білд проєкту, якими інструментами найкраще користуватися.

2. Документація проєкту. Передусім уточніть, де вона міститься. У нас, наприклад, — у Confluence. Перегляньте інформацію (це і технічна документація від розробників, і економіка гри від гейм-дизайнера, і опис івентів від аналітичного відділу).

Якщо документації немає або вона неповна, зверніть увагу на опис завдань у Task Manager системі (у нас це Jira), перегляньте тематичний чат з обговорення функціоналу.

3. Apple & Google Guidelines — ці два ресурси завжди мають бути у ваших закладках, бо, коли змінюються правила, потрібно імплементувати їх у застосунок. Команда має на це переважно кілька місяців.

Навіщо ця інформація

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

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

Варто проаналізувати, які пристрої використовує юзер — так буде простіше обрати тестові девайси, а також осі, на які треба звернути увагу. Якщо внутрішньої інформації мало, перегляньте статистичний сайт, де видно популярні моделі. Не забудьте про розмір екранів. Якщо застосунок на Android та iOS, до загального списку внесіть пристрої з найновішою та найстарішою осями. Неодноразово ми встановлювали Apple Beta осі, завдяки чому знали, наскільки стабільною програма буде під час оновлення.

Відповідно я зрозуміла, що мені треба налаштувати:

  • доступ до репозиторію, щоб стягувати гілки для збірки проєкту, змінювати налаштування в коді, для перевірки тестової версії: SourceTree (Git GUI), Bitbucket (Git), Rider (IDE);
  • встановити інструменти для збірки проєкту, зчитування логів, профайлингу — Unity, Android Studio, XCode;
  • доступ до бази даних — MySQL Workbench;
  • доступ до логування помилок на AWS — CloudWatch;
  • тестування REST API через Postman та перехоплювання даних між клієнтом і сервером — Charles (хоча можна використовувати Proxyman чи Fiddler);
  • доступ до аналітичних систем для коректного налаштування аналітики в застосунку (перевірка івентів, інсталів, діп-лінків, ремоут-конфігів) — AppsFlyer, Amplitude, Firebase, Facebook Events Manager.

Передаємо задачі на тестування

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

Тому наступним кроком стало побудувати процес передачі задач на тестування. Отримати інформацію, хто виставляє пріоритети, які помилки варто виправляти насамперед і коли робити bug-fix реліз (якщо виявляємо критичну позначку crash-free users на продакшені).

Ось кілька наших практик:

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

2. Тестувальник знає про зміни в коді. На кожен функціонал розробник вказує в pull request тестувальника, який його перевірятиме. Гілка зливається в main, коли QA підтверджує pull request (це означає, що критичних помилок тут не знайдено). Це запобігає запуску неперевіреного функціонала в реліз, і QA завжди в курсі всіх змін, що відбуваються.

3. Affected areas у коментарях завдання. Перед тим як віддати на тестування фічу, розробник вказує на affected areas. Відповідно контрольний список створюють з їх урахуванням. Крім того, це допомагає пріоритезувати регресійні тести перед релізом.

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

Одного разу я завела помилку на спливне вікно покупки, яке описала як «bulk purchase pop up», і виникло непорозуміння з розробником, який доводив, що тут усе працює. У проєкті спливне вікно мало назву «checkout pop up». Тобто ми говорили про два різні функціонали.

Розв’язати таку проблему можна через створення Glossary — списку термінів з поясненнями. Важливо його постійно оновлювати.

Тестова документація

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

Test Strategy

Передусім всю інформацію можна перенести в документ під назвою Test Strategy. За правилами він має складатися з таких пунктів:

  • Scope;
  • Test Approach;
  • Test Environment;
  • Testing Tools;
  • Release Control;
  • Risk Analysis;
  • Review and Approvals.

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

Як вели та зберігали checklists, test cases

Ми довго шукали, куди перенести напрацьовані checklists з Excel, проаналізували варіанти й дійшли висновку, що найкраще використати Zephyr.

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

Крім того, можна без проблем прикріпити тести до кожної задачі та переглядати їх у розділі Traceability Matrix, щоб розуміти, що було покрито тестами, а що ні.

Як налаштували

Поділили тести на такі цикли:

  • Regression — список тестів, який ми перевіряємо перед кожним релізом.
  • Smoke — перевіряння основного функціонала застосунку на продакшені після релізу нової версії клієнтської чи серверної частини. Ще цей цикл можемо використовувати, коли зміни, які йдуть у реліз, незначні.
  • AdHock — тестуємо задачі, які входитимуть у релізну збірку.
  • Exploratory (цей блок ще в процесі розробки) — кейси, які не мають чіткого скрипту тестування.

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

Обов’язково додаємо Label, це полегшить фільтрування тестів. А ще аналізуємо перевірене у вкладці Test Summary.

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

Цикл Regression. Варто ґрунтовно продумати блоки застосунку, щоб потім без глобальних переписувань додавати нові тести.

Цикл AdHoc. Тут створюємо щоденні тести за завданнями. Наприклад, є пункт «Додати рекламу»:

  • створюємо тест і прописуємо кроки, щоб покрити функціонал;
  • лінкуємо тест до задачі в Jira;
  • додаємо тест у цикл AdHoc відповідного релізу й тоді проганяємо його;
  • якщо є помилки, прикріплюємо їх до цього прогону і в тесті ставимо Failed;
  • ще одна перевірка функціонала — додаємо такий самий тест в AdHoc, повторюємо кроки й укінці ставимо резолюцію.

Так ми бачимо, скільки разів перевіряли один і той самий білд:

Exploratory. Надихнувшись книгами Джеймса Вітакера «Exploratory testing» та Джеймса Баха «Session-Based Test Management», ми створили цикл Exploratory, щоб покрити функціонал там, де він не покритий регресійними тестами.

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

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

Варто визначити готові тури, що будуть найкраще підходити продукту, або ж створити власні. Знайти помилки нам допомогли тури The Rained-Out Tour. У нас зривався процес купівлі (відбулася верифікація Apple, але запис у БД ще не створився), кошти знімалися, але не нараховувалася внутрішня валюта. The Supermodel Tour допоміг виявити UI-помилки.

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

Як зменшити час на тестування і не втратити якість

Проєкт невпинно зростає, тож на тестування йде більше часу. Тому ми взялися за API тестування: нині активно створюємо кейси, використовуючи Postman, прописуємо Test та Pre-reg — під час прогону візуально зрозуміло, де тест пройшов, а де впав і на якому кроці.

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

Варто наголосити, що через динамічність контенту в застосунку (додаються нові нагороди, відкриваються нові рівні, челенджі) є гостра потреба швидко перевіряти, чи в користувачів не з’являються блокери.

Нам вдалося написати кілька основних тестів SQL-запитів, які запускаємо тоді, коли новий контент готовий до релізу. До написання цих запитів перевірка оновлень займала 3–4 години, після — кілька секунд виконання запиту в БД. Скрипт запускається чотири рази на добу, і повідомлення надходять у Slack (автоматично було налаштовано через Apache Airflow).

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

Як контролювати статистику на продакшені? Допустимий рейтинг Crash-free користувачів — 95%. Якщо він нижчий, це потребує уваги й оновлення збірки. Ми відстежуємо ці показники через Firebase Crashlytics, а також Unity cloud reporting. В режимі реального часу можна спостерігати за проблемами, з якими стикаються користувачі, переглядати статистику девайсів, кроки, які зробила людина до цього.

Висновок

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

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

Сподіваюся, що ця стаття стала корисною для вас, і готова відповісти на ваші запитання.

👍НравитсяПонравилось29
В избранноеВ избранном14
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

Стаття цікава. Дякую.

Интересная и познавательная статья)
Буду рад от Вас еще почитать статьи.

Допустимий рейтинг Crash-free користувачів — 95%. Якщо він нижчий, це потребує уваги

Це за добу чи за годину?

Допустимий рейтинг Cash-free користувачів — 95%. Якщо він нижчий, це потребує уваги :)

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

Допустимий рейтинг Crash-free користувачів — 95%. Якщо він нижчий, це потребує уваги

Це за добу чи за годину?

Допустимий рейтинг Cash-free користувачів — 95%. Якщо він нижчий, це потребує уваги :)

Отличная статья!

А что у вас с автоматизацией тетсирования?

На даний момент девелопери налаштували запуск юніт тестів перед збіркою проекту.
Також, в нас є скрипти для Postmanа які тестують API і налаштований скедюлер для запуску перевірки контенту за вимогами гри.

Також, в нас є скрипти для Postmanа які тестують API

А власне ці тести API не плануєте автоматизувати окремим фреймворком, поза Postman-ом?

емнип с автотестами для Unity3D довольну тухло, стандарный Appium там без силы, а в тулы из юнити очень мало людей на рынке умеет

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

Гарна стаття! І тема цікава.
Особливо хочу висловити подяку вам за те, що не полінились написати українською мовою, а не язиком країни-агресора чи окупанта.
Пишіть ще.

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