QA під тиском: як керувати ризиками, а не «перевіряти все», і зберігати якість

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

Привіт! Мене звати Лада Харченко, я Engineering Lead в Guru Apps — одному з бізнесів групи продуктових IT-компаній Universe Group, що створює застосунки в двох основних напрямках: утиліти та AI. Ми оптимізуємо час людей на рутинних задачах, щоб вони могли його інвестувати у важливі для себе речі. У своїй ролі я відповідаю за Backend, Frontend, iOS та QA напрямки, а мій профільний домен — QA.

Якщо ви читали мою попередню статтю про тестування In-App Purchases на iOS, то ви вже знаєте, що я люблю копати глибоко і говорити про те, з чим стикаюсь у роботі, а не про те, що гарно виглядає в теорії. Тому в цьому матеріалі я поділюся тим, що болить майже в кожній команді, але про що рідко говорять відверто: як тестувати, коли дедлайн на вчора, product-менеджер уже пише в Slack, а ти ще не дивився білд.

Реальність pressure-релізів: що робити, якщо дедлайни горять?

Швидкі релізи — не виняток і не авральна ситуація. Це реальність більшості продуктових компаній, особливо тих, що живуть у світі перформанс-маркетингу і конкурентних ринків. У таких команд тестування під тиском зводиться до поверхневих перевірок, або до хаотичних спроб «перевірити все». Класичний STLC тут не рятує — коли від ідеї до релізу є дні або години, best practices з книжок просто не вписуються в реальність.

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

Кейс № 1: коли чеклісти не рятують

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

Технічна команда сідає за розробку, все йде за планом — є відчуття, що встигаємо. Розробники віддають білд на тестування в п’ятницю після обіду. Тестувальник готувався весь цей час: написав чеклісти, продумав corner cases. Далі починається робота з правками, у результаті якої до вечора реліз-кандидат готовий. Але тестувальник вже не має сил на повноцінну регресію з усіма 500 перевірками, тому робить швидкий прогін по проєкту: все працює, отже можна релізити.

Всі радісні, а в Slack приходить повідомлення про успішний реліз.

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

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

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

Тестування як система рішень

Як жити QA в епоху швидких змін пріоритетів і термінових релізів? Найважливіше — змінити mindset з «що перевіряти» на «який ризик ми приймаємо». Це означає, що з моменту отримання термінової задачі команда думає не про повноту покриття, а про те, що може піти не так й які наслідки це матиме для бізнесу.

Ось три конкретні питання, які варто ставити на старті кожного pressure-релізу:

Що для бізнесу окей, а що критично? Якщо картинка на екрані буде на 3 пікселі лівіше — переживемо. Якщо по кліку на кнопку нічого не відбувається — це вже критично. Розуміння цієї межі дозволяє будувати зовсім іншу систему пріоритизації: і для тестування нового функціоналу, і для регресії існуючого.

Що можна спростити без втрати гіпотези? Дуже часто в термінових релізах product-менеджери з дизайнерами створюють складну логіку, яка не є обов’язковою для перевірки гіпотези. Технічна команда може і має валідувати задачу перед реалізацією: що можна прибрати або спростити так, щоб product-менеджер отримав гіпотезу в проді, QA менше тестував, а дев менше розробляв. Всі задоволені, а реліз відбувся вчасно.

Що змінилось у коді насправді? Ризик-менеджмент — це про «довіряємо, але перевіряємо». Навіть якщо QA давно працює з розробником і комунікація вибудувана — варто хоча б раз під час релізу переглянути історію змін, подивитись які файли в git були змінені і побудувати власний root cause для оцінки скоупу регресії. Особливо в еру Cursor’а, коли розробник сам може не помітити якісь побічні зміни. І окреме питання: чи дійсно цей рефакторинг потрібен саме зараз, чи можна посунути його на наступний тиждень?

Кейс № 2: система go / no-go в дії

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

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

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

Комунікація мовою ризиків

Навіть під тиском можна релізитись швидко і безпечно — якщо тестування побудоване як система рішень, а не список перевірок.

Для тих хто вперше потрапляє в середовище швидкозмінних пріоритетів і термінових релізів на вчора — це справжній страшний сон. Але така реальність сучасного світу в епоху AI, трендів і конкурентності на ринку. Якщо навчитись адаптовуватись і хакнути цю систему — можна почати отримувати від цього задоволення. Особисто я на зараз не уявляю себе в «тихій гавані» :)

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

Домовлятись про рівень якості до моменту pressure. Якщо команда працює в режимі 2-3 релізів на тиждень — повна регресія на 500 перевірок кожного разу просто не реалістична. Але команда має чітко розуміти наслідки цього рішення і мати правильне розуміння неідеальності: рух у такому темпі може означати, що десь перестане працювати кнопка на якомусь флоу.

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

Якість — це не тільки тест перед релізом. В сучасному світі недостатньо просто тестувати мануально. Треба знати де провести навантажувальне тестування, де копнути глибше, вміти імітувати стани та іноді залазити в код. Вичерпне тестування неможливе, але якісно побудована система моніторингу прода, а це майже завжди поруч з автотестуванням — дозволяє бачити проблеми ще на 0,5% користувачів і готувати хотфікси до того як вони стануть інцидентом. І особливо це важливо при роботі з third-party сервісами — кейси нестабільності з їхнього боку моніторити обов’язково.

Підсумок

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

Кілька key takeaways з цієї статті:

Швидке тестування ≠ хаос. Рішення, які ви приймаєте під час тестування — ось що визначає результат, а не кількість витраченого часу.
Місяць на тестування не гарантує відсутність багів, якщо ви не знаєте які ризики перевіряти і не розумієте продукт та стек.
Домовляйтесь про рівень якості до моменту pressure — не в момент коли все горить.
Комунікуйте ризиками, а не страхами. Ризик можна побачити і вирішити. Страх — тільки паралізує.
Якість продукту тримається на фокусі, пріоритетах і домовленостях — а не тестується.