Інженерія якості без поділу на ролі

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

Привіт, DOU! Я Роман Поботін, Lead AQA / SDET з понад 10-річним досвідом. За ці роки я бачив один і той самий сценарій в різних командах: QA ділять на Manual і Automation, кожну роль «оптимізують» окремо — а реліз все одно горить. Чому — довго ніхто пояснити не може.

Відповідь завжди одна: «Ну, так історично склалося». Цією фразою виправдовують дивні процеси, нелогічні CI-пайплайни, відсутність стратегії і, найголовніше, штучні стіни між людьми. Найпопулярніша з них — та сама, з якої я почав: поділ на Manual та Automation QA. Систему розрізали на шматки. Кожен шматок працює добре сам по собі. Сама система — ні.

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

Проблематика: Коли оптимізація ролей вбиває систему

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

Замість потоку цінності ми отримуємо:

• Інформаційні «бункери»: Мануальники володіють контекстом, але не мають важелів швидкості. Автоматизатори мають код, але часто відірвані від реальних ризиків.
• Втрати на передачах (Handoffs): Кожна передача задачі від однієї ролі до іншої — це втрата контексту та часу. Це «сміття» у Lean-термінології.
• Регресія як «Гербі»: У Теорії обмежень є персонаж Гербі — найповільніший бойскаут, який гальмоє весь загін. У IT-командах роль Гербі часто грає регресія, яка «з’їдає» тижні й стає головним пляшковим горлечком.
• Культура «це не моя зона відповідальності»: Кожен «завантажений на 100%», але реліз стоїть. Бо відповідальність розмита між ролями, а не зосереджена на результаті.

Дисклеймер: Це не про ролі, це про мислення

Manual — це не проблема. Automation — це не проблема. Проблема виникає тоді, коли це стає різними світами.

• Manual — це про мислення, UX-аналіз та емпатію. Це розуміння того, що і навіщо ми перевіряємо.
• Automation — це про масштаб, швидкість та інженерну досконалість. Це важіль, що примножує ваші знання.

Як тільки ці інструменти стають ізольованими посадами — система деградує. Мова не про революцію, а про еволюцію: від виконання функцій до інженерії.

Прогресія ролі: Від «клікера» до інженера системи

Кар’єра QA виглядає просто: ти або виконуєш задачі, або відповідаєш за результат.

Мій шлях — від студента до Lead SDET у GlobalLogic, SQUAD та Дії — підтвердив цю прогресію. Спочатку ти клікаєш. Потім автоматизуєш. Потім починаєш розуміти систему. А потім приходить ключове усвідомлення: твоя цінність не в тому, що ти зробив, а в тому, чи доїхав працюючий реліз до користувача. На цьому етапі поділ зникає. Залишається лише інженерія якості.

Ринок диктує нові правила: Delivery > Ролі

Подивіться на вакансії: «Automation QA з готовністю до manual». Це не компроміс, це симптом. Бізнес більше не купує «тип спеціаліста». Він купує результат. Йому потрібен інженер, який бачить систему цілісно, знаходить вузьке місце і прибирає його будь-яким інструментом. Сьогодні це автотест, завтра — SQL-скрипт для генерації даних, післязавтра — аналіз вимог. Гнучкість — це нова норма.

Пастка «Сізіфа»: Чому manual не масштабується

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

Пастка «Скриптописів»: Коли автоматизація не має сенсу

Інша крайність — автоматизація «у вакуумі». Код заради коду, тестовий шум та false positives. Без чіткої стратегії вибору рівнів тестування (піраміди тестування) автоматизація перетворюється на крихку UI-споруду, яка руйнується від будь-якої зміни в інтерфейсі. Такі тести не захищають реліз, вони створюють ілюзію безпеки.

Хто такий General / Fullstack QA?

Це інженер із T-shaped профілем: широкий продуктовий контекст плюс технічна глибина. Але головне — це Ownership. Він відповідає не за тест-кейс, а за те, щоб фіча працювала в руках користувача. Він розуміє, що автоматизація — це не мета, а засіб зниження ризиків.

Філософія Ownership: Героїзм як симптом

«Це не моя зона відповідальності» — це сигнал, що система зламана.

Ownership означає: немає даних — ти їх створюєш; немає інструменту — ти його пишеш; є блокер — ти його прибираєш.

Важливо: героїзм одного QA — це не сила команди. Героїзм — це симптом хворої системи. Якщо реліз тримається на тому, що хтось «впахав» — у вас немає процесів. Справжній інженер будує систему, яка працює стабільно в 9:00 ранку понеділка без жодного подвигу.

Стратегічний підхід: Піраміда та вибір шару

General QA не автоматизує «все через UI». Він слідує піраміді тестування:

1. Максимум на рівні Unit та Integration (API) — бо це швидкість та дешевизна.
2. Мінімум критичних сценаріїв на рівні UI (End-to-End) — бо це дорого і довго.
   Це дозволяє тримати баланс між глибиною перевірки та швидкістю фідбеку. Якщо ви намагаєтеся покрити все через браузер — ви будуєте «ріжок морозива», який розтане під тиском першого ж термінового релізу.

Як закривати регресію «на льоту»: Zero Manual Debt

Найбільший самообман: «потім автоматизуємо». Ні, не автоматизуєте.

Є лише одна робоча модель: протестував фічу → одразу автоматизував → більше не повертаєшся до цього руками. Це єдиний спосіб позбутися «хвостів» регресії. Це вимагає від інженера вміння обирати правильний інструментарій, який відповідає стеку технологій проекту та легко інтегрується в CI.

Код як інструмент підготовки даних

70–80% часу тестування — це не перевірка, а підготовка. General QA використовує код (API, SQL, скрипти) як асистента. Складні стани системи створюються за секунди. Це звільняє мозок для аналітики та складних кейсів, а не для рутини «створи-залогінься». Інженер будує «Data Factories» замість ручного заповнення форм.

Паралельність і швидкий фідбек: Філософія «парної розробки»

Ми маємо перестати чекати, поки «розробка закінчиться», аби «тестування почалося». Це лінійне мислення, яке вбиває швидкість.

Справжня паралельність виглядає так:

• Старт в один час: Підготовка до тестування та написання автоматизації має починатися паралельно з розробкою коду (Shift-Left).
• Адаптація «до деплою»: Якщо в процесі знайдено баг, QA адаптує або пише новий тест до того, як розробник задеплоїть фікс.
• Швидкий Дев-Тест: Це фактично «парна розробка». Ми готуємо перевірку заздалегідь, щоб після деплою фікса за хвилини дати розробнику відповідь: «Так, це виправлено, і ні, нічого не зламалося».

Це частина Continuous Testing — безперервного процесу, де якість перевіряється на кожному етапі життєвого циклу розробки (SDLC).

Автоматизація в беклозі — це борг

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

Говоріть мовою бізнесу: ROI та результати

Бізнесу байдуже на ваш coverage чи вибір мови програмування. Йому важливо: Time-to-Market, ризики та гроші.

QA перестає бути «центром витрат» і стає Multiplier, коли створює систему з високим ROI (Return on Investment). Ми автоматизуємо не все підряд, а те, що приносить найбільшу цінність: критичні шляхи користувача, найчастіші баги та найбільш часозатратні ручні перевірки.

Приклад покращень: Математика якості

Якщо ми спробуємо описати цей підхід математично, то отримаємо цікаве рівняння:

Manual + Automation = General QA

Але якщо ми згадаємо, що Manual та Automation — це лише функції одного й того самого процесу забезпечення якості (QA), то при скороченні змінних ми побачимо істину:

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

Перехід від моделі 4 Manual + 2 Automation до 6 General QA у моїй практиці дав наступні результати:

• Всі почали автоматизувати одразу (Continuous Testing).
• Регресія перестала бути окремою фазою — вона стала «невидимим» фоновим процесом.
• Релізи стали не тільки швидшими, а й значно частішими.
• Результат: мінус 62 робочих дні регресії на рік при зростанні кількості пройдених тест-кейсів з 2,3 тис. до 13 тис.

(це приклад тільки одного продукту з багатьох)

Це не про «робити більше», це про «робити розумніше»

Часто виникає побоювання: «Тепер інженери мають робити роботу за двох за ті ж гроші?». Насправді все навпаки. За допомогою такого підходу ми зменшуємо рутину. Коли ви прибираєте безкінечне ручне «проклацування», у вас вивільняється час.

Цей час можна інвестувати у:

• Складні та творчі задачі (Exploratory testing, Performance, Security).
• Інноваційні підходи до архітектури тестів.
• Покращення процесів, які реально впливають на бізнес.

Але для цього нам потрібні метрики. Ми маємо базуватися на фактах (Lead Time, Cycle Time, Change Failure Rate), а не на вайбах та чуйці. Тільки цифри доводять, що інженерія якості — це двигун продуктивності.

Що далі: Від ролей до інституцій

Масштабування — це перехід від «людей як системи» до «системи, що працює через людей». Ми повинні будувати інституції: одна модель якості, одна культура прийняття рішень, одна Definition of Done для всіх.

Тест на Bus Factor: якщо вас прибрати завтра, що зламається? Якщо «майже все» — ви і є система. Якщо «нічого критичного» — у вас є інституція.

Висновок

В кінці дня важливо лише одне: чи отримав користувач робочий продукт у потрібний момент.

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