QA Lead у айті компанії відповідає за культуру якості, баланс між швидкістю роботи та її стабільністю, розвиток співробітників та запобігання їх вигоранню. Яна Марісова керує командою з 10 інженерів у Сан-Хосе на проєкті носимих AI-пристроїв. Вона поділилася з нами системою, яку вибудувала: від планування релізів до онбордингу, від встановлення метрик якості до продуктивних розмов за кавою.
Ownership замість виконання тестів
Команда Яни зараз складається з 10 працівників різного рівня та спеціалізації: QA інженери, які фокусуються на інтеграційному та системному тестуванні, а також QA-інженери з досвідом роботи з hardware і розумними модулями.
Обов'язки розподілені за принципом ownership. Кожен QA відповідає не просто за виконання тестів, а за конкретні фічі або зони продукту end-to-end — від аналізу змін у білді до релізної оцінки ризиків і готовності до запуску.
"Окремо ми зараз активно працюємо над покращенням та передачею знань усередині команди. Поки вона ще не дуже велика, ми свідомо робимо знання більш універсальними: обмінюємося контекстом, документацією та практиками. Це дозволяє зменшити залежність від окремих людей і значно спростить масштабування команди в майбутньому", — пояснює Марісова.
Планування релізів: п'ять кроків
Команда завжди починає з аналізу змін у білді: що саме було оновлено, які модулі зачіпає реліз, де є найбільший ризик для користувача.
"Процес виглядає так: аналіз scope релізу, визначення high-risk зон, планування risk-based testing, розподіл ресурсів команди, визначення мінімально обов'язкового набору тестів для релізу. Це допомагає зберігати баланс між швидкістю та якістю навіть у стислих дедлайнах", — каже інженерка.
Метрики: стабільність важливіша за кількість багів
Команда дивиться на комбінацію показників: кількість і критичність дефектів на реліз, defect leakage, повторне відкриття багів, стабільність білдів, результати регресій, час реакції команди на критичні інциденти.
"Для мене успіх — це стабільні релізи без сюрпризів, а не просто велика кількість знайдених багів", — розповідає Марісова.
Daily stand-ups без зайвих слів
Щоденні стендапи, короткі дзвінки, де обговорюють результати роботи, проходять коротко та по суті: що зроблено, що блокує виконання задач, де потрібна допомога.
На ретроспективах, роботі над помилками за минулий спринт, фокусуються не на пошуку винних у проблемах, а на трьох речах: що можна покращити, які процеси й методи не спрацювали, які рішення були ефективними.
QA reviews — це простір для обговорення підходів до тестування, складних кейсів та обміну досвідом між інженерами.
"Найкраще працює відкрита атмосфера, де люди не бояться помилятися", — каже Яна.
Запобігання вигоранню: розмови за кавою
Марісова завжди дотримується реалістичного планування, виставлення чітких пріоритетів, ротації складних задач. Формується можливість і простір відкрито сказати, що навантаження завелике, підтримується work-life balance.
"Я вважаю, що вигорання людини є сигналом про збої у внутрішніх процесах компанії", — підкреслює вона.
Якщо QA Lead бачить, що хтось систематично почав видавати результат нижчий, ніж той рівень, на який він реально здатен, не дорікає та не починає розмову з зауважень.
"Я запрошую колегу на каву і просто питаю, як справи, що відбувається в житті, чи є щось, що зараз забирає ресурс або турбує. Дуже часто такі розмови дозволяють вчасно виявити перевантаження, втому, сімейні обставини або процесні негаразди, і знайти рішення до того, як це переросте у справжнє вигорання", — розповідає Яна.
Для неї це частина відповідальності лідера — не лише керувати задачами та розподіляти їх, а й дбати про людей, які ці задачі виконують.
Інженерне мислення: п'ять практик
Марісова свідомо розвиває в QA-фахівцях інженерне мислення. Для неї важливо, щоб QA спочатку розуміли, як працює система і чому виникають проблеми, а лише потім фіксували їхні прояви.
На практиці це виглядає так:
- Фокус на root cause analysis. Команда замість того, щоб зупинятися на питанні "що зламалося?", завжди досліджує чому це сталося і в якому місці системи.
- Залучення QA до технічних обговорень. QA беруть участь у дизайн-дискусіях, обговореннях архітектури та плануванні фіч разом із розробниками. Це допомагає сформувати цілісне розуміння продукту.
- Менторство та парна робота. Команда практикує менторинг і knowledge sharing: досвідчені інженери працюють у парі з менш досвідченими, ділячись досвідом.
- Навчання через реальні кейси. Яна часто використовує реальні дефекти або інциденти як навчальні приклади.
- Заохочення питань і ініціативи. Створено середовище, де нормально не знати, але важливо питати і досліджувати.
Звісно, у high-season або під час пікових релізів не завжди є можливість системно інвестувати час у навчання та менторство. У такі періоди фокус зміщується на стабільність продукту й виконання критичних задач.
"Саме тому більшість активностей з розвитку інженерного мислення ми свідомо плануємо на cool-down періоди після великих релізів. Так команда відновлюється, осмислює отриманий досвід і переводить його в довгострокові покращення процесів та навичок", — пояснює QA Lead.
Конфлікти: розуміння проблеми, а не пошук винних
Команда завжди намагається залишатися конструктивною, не керуватися емоціями та працювати через ефективну комунікацію.
"Для мене принципово важливо уникати blame game. Конфлікти вирішуються спільним розумінням проблеми і чітким планом дій. Я завжди наголошую, що ми знаходимося в одному човні: у всіх одна мета — стабільний продукт і хороший користувацький досвід", — каже Яна.
Тому команда у першу чергу завжди швидко знаходить варіант рішення, який буде найшвидшим і найефективнішим, що допомагає зберігати здорові робочі відносини і рухатися вперед без зайвих втрат часу та енергії.
Публічне демо без дефектів
Найбільшим успіхом команди за останній рік стало проведення публічного демо продукту для преси в грудні, яке пройшло абсолютно бездоганно. Під час демонстрації не було виявлено жодного критичного дефекту — жоден баг не пройшов повз QA-відділ.
Щоб досягти цього результату, команда підійшла до підготовки максимально системно. Марісова ініціювала створення чіткої системи метрик готовності білдів, яка дозволяла об'єктивно оцінювати, наскільки кожен білд відповідає вимогам для публічного показу. Команда розробила шкалу готовності, яка враховувала стабільність, продуктивність, ключові користувацькі сценарії та ризики.
"Це дало нам можливість приймати зважені рішення щодо готовності продукту до демо, сфокусувати зусилля на найкритичніших зонах і уникнути сюрпризів у день презентації. Саме завдяки цьому світ уперше побачив наш продукт таким, яким він мав бути", — розповідає інженерка.
Процеси, які покращили роботу
Коли Яна прийшла в команду, вона побудувала процес тест-планування. Для неї було важливо, щоб кожен QA чітко розумів свій скоуп роботи на день, щоб складні й стресові задачі не концентрувались постійно на одних і тих самих людях, і щоб кожен мав відчуття контролю над своїм обсягом роботи та зоною відповідальності.
"Це одразу зменшило кількість конф'юзу, дублювання й помилок через неправильні білди або налаштування", — каже вона.
Окрім того Марісова впровадила для новачків нову унікальну систему онбордингу, який полегшує їм знайомство з процесами та допомагає увійти в ритм.
Онбординг: інвестиція в довгострокову якість
Попри трудомісткість, Яна любить цей етап роботи.
"Якщо зробити його правильно і не поспішати, він дуже швидко окупається", — каже вона.
Його порядок такий: системні доступи, базові тренінги (безпека, anti-harassment, privacy), робота з девайсами та конфіденційною інформацією, навчання внутрішнім інструментам.
"Щоб зацікавити продуктом, я показую його, демо, розповідаю, що тестуємо, для кого і навіщо, також знайомлю з колегами, які працюють у команді", — розповідає Марісова.
Після детальних тренінгів по зонах продукту нові співробітники починають тестування у форматі shadowing: спостерігають за досвідченими QA, задають питання та після того, як зрозуміють контекст переходять до самостійної роботи.
"Онбординг — це завжди про якість старту. Якщо людина з самого початку розуміє продукт, правила і очікування від неї, вона значно швидше стає впевненим членом команди", — підсумовує інженерка.
Підсумок
Керування QA-командою — це баланс між швидкістю та якістю, розвитком людей та виконанням задач, процесами та гнучкістю. Досвід Яни Марісової показує, що успішна команда будується на взаєморозумінні, чітких метриках, культурі довіри та постійному розвитку.
