Крихкі зони: як виявляти їх вчасно. Досвід FAVBET Tech

Крихкі зони у FAVBET Tech раніше могли просочуватись у продакшн. Причини були різними, але одна з найголовніших – непорозуміння команд QA і девів. Тепер, коли комунікація налагоджена, крихкість відловлюють на ранніх етапах.

Як саме вони це роблять і що допомогло впровадити найкращі практики, розповідає для партнерського тексту QA Lead у FAVBET Tech Вячеслав Остапенко. 

Як дізнатися, що частина системи є крихкою

Ми розуміємо, що частина нашої системи є крихкою, коли є певні фактори на рівні коду або тестів. Серед них:

• Падіння Common Test у GitLab CI. Це юніт-тести, які проходить фіча до передачі на тестування. Якщо вони фейляться, варто змінити підхід або переписати частину коду.
• Стислі дедлайни. Якщо реалізацію фічі пришвидшують на вимогу бізнесу і при цьому минають критичні нюанси, зростає ймовірність появи крихких місць.
• Складна або заплутана логіка. Чим більше у функціональності залежностей (сервісів, інтеграцій, команд), тим вищий ризик помилок.

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

Інший приклад – рефакторинг бекенд-методу, пов’язаного з фільтрами за датою. Після змін впали автотести, пов’язані з іншим методом. Автоматизатор написав про це в чаті й розробник оперативно виправив помилку до того, як вона пішла на stage або продакшен.

Також ми застосовуємо проактивні техніки, але вони є відповідальністю інших команд. Наприклад, fault injection – це зона відповідальності DevSecOps, а ризики типу house testing відстежують команди інфраструктури через моніторинг.

Які використовують метрики

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

Серед ручних метрик використовуємо:

• Jira-дашборди;
• звіти з тестування;
• список заведених багів (зокрема критичних і високого пріоритету).

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

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

Роль комунікації: чому без неї не виявити слабкі місця

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

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

Відтоді ми ввели практику позначати affected area – зони, які потенційно зачіпає зміна. І навіть якщо розробник не зазначив таку зону вручну, тестувальники тепер уточнюють це окремо – раптом просто забули додати.

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

Do’s і Dont’s при роботі із крихкими зонами

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

Раз на квартал команда планує завдання на три місяці вперед. До цього ми аналізуємо баги й інші проблеми, що виникали в попередній період, з боку тестувальників, сапорту, користувачів. Навіть якщо формально дефект не був заведений, ми обговорюємо ситуації, які вплинули на стабільність або досвід. Якщо бачимо ознаки крихкої зони, закладаємо час на її пропрацювання. Зараз у нашій практиці близько 20% задач у спринтах – це робота з технічним боргом, рефакторинг чи оновлення автотестів.

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

Усередині команди працюють і менш помітні, але постійні практики:

• Ревʼю тест-кейсів. Ми переглядаємо роботи одне одного, уточнюємо логіку, доповнюємо сценарії.
• Спільна документація. Кожен важливий кейс чи висновок фіксуємо у внутрішньому QA-просторі.
• Щотижневі обговорення. Інциденти, нюанси релізів і ризики обговорюємо на регулярних мітингах.
• Ретроспективи. Після інцидентів повертаємося до причин, оновлюємо покриття, змінюємо підходи.

Ретроспективи – це один з найулюбленіших моїх підходів. Ось нещодавній приклад, як вони працюють:

А от серед переоцінених і марних підходів – це писати чеклісти на все. Бо якщо чекліст розписаний дуже детально, його частина часто ігнорується. Натомість короткий, але релевантний список ризиків саме для певної фічі працює значно краще.

Залежність «більше тестів – менше крихкості» також не працює. Покриття саме по собі не гарантує стабільності. Якщо сценарії підібрані формально, крихкість лишається. Крім того, бувають кейси, коли автотести покривають лише happy flow. Натомість варто працювати і з негативними та edge-сценаріями. 

Що робити після виявлення крихкої зони

Коли ми виявляємо крихке місце (на проді, у тестуванні чи в логах), команда діє послідовно: аналіз → рішення → перевірка → моніторинг.

1. Аналіз причин

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

2. Формування рішення

Наступний крок – знайти спосіб усунення. Це може бути:

• зміна логіки;
• додаткова перевірка;
• рефакторинг;
• уточнення вимог, якщо вони виявилися некоректними або нечіткими.

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

3. Оновлення покриття

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

4. Перевірка та верифікація

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

5. Подальший моніторинг

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

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

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

Поради командам, які хочуть вчасно виявляти слабкі місця

1. Налагоджуйте комунікацію всередині команди та між командами. Тестувальники й розробники мають працювати разом: ставити уточнення, ділитися сумнівами, не боятися обговорювати нестандартні кейси. Здорова комунікація допомагає виявляти слабкі місця ще до появи перших багів.
2. Дивіться не лише на дефекти, а й на місця, де вони виникають. Важливо не просто рахувати баги, а аналізувати закономірності: у яких модулях вони трапляються, із чим пов’язані. Ми, наприклад, щомісяця переглядаємо інциденти і проводимо мінірозбори – це дає змогу вчасно виявляти повторювані проблеми.
3. Документуйте висновки після фіксів. Якщо проблема вже виникала, вона може повторитись. Тому після кожного критичного багу варто не лише виправити код, а й зафіксувати причину, сценарій і рішення. Це допомагає не повертатись до тієї самої помилки в майбутньому.