Тестувальник допомагає помітити та виправити помилки в продукті до того, як їх побачить мільйон користувачів. Стереотип про те, що робота QA — це просто сходинка на шляху до «справжньої» розробки, залишився в минулому. Аби стати професіоналом своєї справи, фахівець має розумітися не лише на своєму домені, а й на бізнес-складовій.
У цьому матеріалі ми розглядаємо сім труднощів, з якими зіштовхуються QA-інженери, поки відловлюють всі баги у продукті. Перелік сформулювала Каріна Карпінська, QA Lead в OBRIO. Каріна має п'ять років професійного досвіду. За два роки в команді OBRIO, вона вибудувала QA-процеси з нуля, а зараз посилює власну команду.
Коли програмісти розробили новий функціонал чи допрацювали старий, завдання переходить до QA-інженерів. Трапляється так, що частину завдань, пов’язаних із тестуванням, розробники пропускають.
Наприклад, у нас на кожну фічу підіймається окрема рев’ю-гілка. Ми їх називаємо рев’ю-апками. Кожній такій апці відповідає окремий лінк. Щоби протестувати зміни на беці, розробник має окремо підняти рев’ю-апку на фронті. Відповідно, якщо проєктів декілька, й усюди були зміни, підіймати гілки на фронті потрібно окремо під кожен проєкт.
Буває так, що розробники забувають підіймати необхідне середовище. Тоді життя тестувальника стає складнішим, адже він має витрачати час на пошук потрібних лінків.
Однак, я думаю, що це просто людський фактор, а завдання пропускаються через банальний поспіх. Подібні проблеми можна вирішити чеклістом, аби розробник міг перевірити, чи готова задача до тестування, перед тим, як її віддавати. Тоді час на тестування і комунікацію зменшується, а життя й настрій QA-інженера покращується.
Зазвичай ТЗ прописується для всієї технічної команди загалом, а далі декомпозується на розробників, тестувальників, аналітиків та інших.
ТЗ для QA-фахівця складають різні люди — від бізнес-аналітика до продакт-менеджера. Кожен із них може зіштовхнутися з упередженням, що всі деталі зрозумілі й так, а додатково конкретизувати нічого не потрібно. В результаті в описі завдання немає тестових сценаріїв, вимог до функціональності, критеріїв прийняття чи інших технічних подробиць.
Нечіткі вимоги призводять до того, що QA-інженер знову-таки витрачає зайвий час на комунікацію з розробниками та продактами, з’ясовує деталі, переоцінює терміни, змінює пріоритети тощо. І це в кращому випадку. У гіршому — погано прописані вимоги призводять до помилок у продукті.
В OBRIO є два напрями — мобайл і веб. Раніше вони існували паралельно. Формально продукт один і той же, однак логіки, архітектура та кодова база відмінні. Кожне спрямування розвивала окрема технічна команда, яка складалася з розробників, аналітиків, QA та DevOps-інженерів. Тепер мобайл і веб поєднали — і над ними працює єдина команда під керівництвом CTO.
Потрібно було провести взаємний онбординг команд. У продуктах з прямолінійним юзер-флоу це нескладно, однак у нас все трохи інакше. Шлях користувача може відрізнятися залежно від того, звідки він до нас потрапив, у який день тижня, та інших факторів. У продукті багато розгалужень, тож навіть покупка простого оферу може мати свої особливості. До того ж, у вебі й у мобайлі робилися різні тести. Потім їх порівнювали та аналізували результати.
Через це тестувати продукт буває складно. І тут, знову-таки важлива документація. Не факт, що всі деталі щодо онбордингу в новий напрям вдасться втримати в голові. Тому дуже важливо мати якесь «джерело правди», до якого можна звертатися за необхідності.
Хороша документація не обов’язково містить кожну дрібницю, однак у ній точно потрібно описати складний та базовий функціонал. Аби QA-фахівець міг якісно виконувати свої завдання, йому потрібні всі три: і продуктова, і тестова, і API.
Складність з продуктовою документацією полягає в специфіці роботи загалом. Річ у тім, що 90% наших запусків відбуваються через A/B-тести. Тому, перш ніж потрапити до документації, функція має деякий час «пожити» на продукті. Навіть якщо вона залишилася, документування часто губиться серед інших, більш термінових завдань. Однак це важливо, бо немає гарантії, що через місяць нюанси конкретного запуску не забудуться.
Тестова документація теж необхідна QA-фахівцям, особливо, коли йдеться про регресію, smoke-тестування, чеклісти. Тоді вся необхідна інформація буде під рукою, якщо потрібно перевірити велику частину продукту.
Щодо API-документації — я не можу сказати, що вона полегшить життя усім на продукті. Здебільшого, вона потрібна QA-інженерам. Втім, цього достатньо, враховуючи, що багато продуктів, які потрібно тестувати, взаємодіють зі сторонніми програмами, сервісами або бібліотеками.
Я уже згадувала про тестові рев’ю-апки — окремі гілки, де ми ізольовано тестуємо кожну фічу. Для них розгортається окреме середовище — тестовий env (скорочено від environment). Ці середовища часто працюють нестабільно через те, що мають окремі бази даних, окреме наповнення. До того ж, на них впливає запуск UI-тестів, налаштування конфігів та інші фактори. Через це тести також не вдається спланувати чітко.
Наприклад, я розраховую, що сьогодні на тестуванні матиму дві задачі. Спочатку все добре: відкриваю таску, онборджуся в неї, продумую послідовність дій. І тут — маю перший блокер: не працює тестовий env. Щось не налаштоване, а що саме не так — не зрозуміло. Або не вистачає потрібних даних. Доводиться переключатися на інше завдання, втрачати фокус, онбордитися в нову таску. А це — час і ресурс.
Інженери, що займаються автоматизованим тестуванням, зіштовхуються з цим болем рідше. Здебільшого труднощі з плануванням виникають саме у Manual QA. Їхня робота залежить від розробників, продакт-менеджерів, бізнес-аналітиків, DevOps-інженерів та багатьох інших людей у команді.
Оцінюючи терміни для тестування, я орієнтуюся на кілька факторів: опис, дедлайн від розробника, наявність чи відсутність A/B-тестів, частина продукту, з якою потрібно працювати. Ми в команді естимейтимо в годинах, тож найчастіше розрахувати терміни вдається плюс-мінус точно. Втім, бувають нюанси.
Так, на початку спринтів я намічаю для себе процес роботи. Фіксую, що, наприклад, у вівторок-середу отримаю три конкретні завдання від розробників — й готуюся працювати саме з ними. Однак буває, що терміни роботи розробників змінюються. Хтось захворів, хтось поверхнево заестимейтив нове завдання й потребує більше часу, десь тестування не можна почати без допрацювань в іншому продукті (через те, що вебплатформа залежить від застосунку й навпаки). Заплановане відкладається — і вся підготовка починається спочатку.
Частина труднощів пов’язана з тестовими env-ами. Щоби зарелізити функціональність, яка потрапляє на тестовий env, все на стейджі має бути готове до запуску. Однак, коли є ще якісь таски, які треба дофіксити чи дотестувати, то зробити реліз не вийде — на стейджі все заблоковано. Подібних нюансів багато.
Коли ми проводимо A/B-тести чи робимо інші запуски, то створюємо аналітичний дашборд. Він дає змогу відстежити поведінку юзерів у продукті. Інструмент показує, що, наприклад, маркетингова воронка на першому кроці має привести 10 юзерів, які будуть активно «жити» у застосунку.
Після запуску ми маємо змогу оцінити кількість та поведінку користувачів, що залишилися. Їх очікувано десять чи менше? А якщо менше — то чому? На якому етапі юзери «відвалилися»? Що на це вплинуло? Як ми можемо їх повернути? Метрики дають змогу знайти відповіді на ці питання, з’ясувати, чому не вдалося досягти бажаних показників та головне — не повторювати помилки під час майбутніх запусків з більшою кількістю користувачів.
Якщо ж метрик немає, ми не зрозуміємо, що сталося: чи це QA неправильно спланували завдання, чи розробники щось не врахували, або ж справа в гаджеті користувача. Дашборду може не бути через низку причин: не запланували аналітичні івенти, не прокомунікували, що завдання уже потрапило на прод, не попередили, що незабаром реліз, й для нього потрібна аналітика.
