Є думка, яка вже багато років стає дедалі популярнішою в бізнес-колах: тестування — це не складно. Будь-хто може клікнути по продукту і сказати, чи працює він. Навіщо тоді окремий спеціаліст, окремий процес, окремий бюджет?
Логіка приваблива, особливо під час оптимізації витрат. Продакт-менеджер і так знає продукт краще за будь-кого. Сейлз і так розуміє, що важливо клієнту. Розробник і так бачить код зсередини. А ще є AI, який може згенерувати тести за хвилину. Навіщо платити людині, яка «просто клікає»?
І справді — в більшості компаній тестування вже відбувається без тестувальників. Продакт перевіряє фічу перед демо. Сейлз проходить по флоу перед важливим дзвінком. Менеджер із Customer Success клікає перед онбордингом нового клієнта. Це явище навіть інколи називають Shadow QA. І бізнес дивиться на нього і думає: «ось, все працює і без QA».
Але тут є одна принципова помилка. Те, що відбувається — це не тестування. Розберімося, чому «тестують усі» і «є QA-спеціаліст» — це дві абсолютно різні реальності. І чому плутанина між ними коштує бізнесу значно дорожче, ніж зарплата тестувальника.
Коли ми говоримо «ручне тестування», ми мимоволі описуємо роботу руками, а не головою. Майкл Болтон, один із авторів методології Rapid Software Testing, роками наполягає: сам термін «ручне тестування» шкодить професії. Він зводить складну інтелектуальну діяльність до механічних дій — і саме тому бізнес так легко вірить, що її може виконати будь-хто.
Але якщо подивитись на те, що насправді робить досвідчений тестувальник — картина інша. Він не просто клікає. Він моделює систему, думає про ризики, ставить під сумнів припущення, шукає те, чого ніхто не очікує знайти. Це інтелектуальна робота, яка виглядає як «клікання» лише для стороннього спостерігача.
І саме тому її так легко недооцінити — і так дорого помилитись у цій оцінці.
«ПЕРЕВІРИТИ І ПРОТЕСТУВАТИ» — ЦЕ НЕ ОДНЕ Й ТЕ САМЕ
Коли продакт перевіряє фічу перед демо, він не шукає проблеми. Він шукає підтвердження, що все добре. Це принципово різний режим мислення — і він майже ніколи не знаходить те, чого не очікує знайти.
Болтон формулює це чітко: тестування — це не підтвердження того, що софт працює у вакуумі. Це дослідження поведінки системи в різних, часто непередбачуваних умовах. Різниця між «перевірити» і «протестувати» — це різниця між запитанням «чи працює це?» і запитанням «за яких умов це може зламатись, і чи важливо це для користувача?».
Перше питання ставить будь-хто. Друге — людина з певним типом мислення, яке формується роками досвіду і рефлексії.
Продакт, який клікає перед демо, проходить щасливий шлях. Він не думає про граничні стани, про поведінку системи під навантаженням, про те що станеться якщо користувач зробить щось несподіване. Не тому що він некомпетентний — а тому що це не його задача і не його спосіб думати.
НАВИЧКИ, ЯКІ НЕ ЗАСТАРІВАЮТЬ І НЕ ЗМІНЮЮТЬСЯ
Коли говорять про заміну тестувальників — AI, автоматизацією або «будь-ким» — зазвичай мають на увазі заміну механічної частини роботи. І так, механічну частину справді можна автоматизувати.
Найважливіші навички тестувальника — системне мислення, критичне мислення, фокус на ризиках, здатність швидко навчатись і осмислювати нову ситуацію — не застарівають так, як мова програмування чи черговий фреймворк. Аналіз і критичне мислення можуть підсилюватись інструментами — але не замінюватись ними.
Це навички, які дозволяють не просто знайти баг, а зрозуміти що він означає для бізнесу. Не просто запустити тест, а поставити під сумнів саму постановку задачі. Не просто звітувати про результат, а розповісти стейкхолдерам про ризики зрозумілою мовою. Саме це не може зробити ні AI, ні продакт із чеклістом, ні «людина з вулиці».
Зелений дашборд у CI/CD нічого не говорить продакту про те, чи поводиться фіча так, як очікує реальний користувач. Автоматизація без критично мислячої людини за нею — це не гарантія якості, а хибне відчуття безпеки. Якщо нетехнічні команди не довіряють результатам тестування — автоматизація не економить час, вона просто додає зайвий шар впевненості, якої насправді немає.
Болтон каже про це прямо: якщо будуєш щось важливе і не хочеш себе обманювати — потрібні люди, які залишаються професійно невпевненими що все добре. Люди, чия робота — шукати приховані, рідкісні, тонкі, непередбачувані проблеми. Не підтверджувати що все окей, а сумніватись у цьому методично.
Shadow QA виглядає як економія. На практиці це дублювання роботи найдорожчих людей у компанії.
Продакт-менеджер, який годину тестує перед релізом — це година без стратегії, без дослідження користувачів, без roadmap. Сейлз, який перевіряє продукт перед дзвінком — це тривога замість підготовки. І при цьому ніхто не дивиться на систему цілісно, бо кожен перевіряє тільки своє і тільки те, що вже очікує побачити.
Компанії, які прибирають QA заради економії, зазвичай не бачать прямого зв'язку між цим рішенням і наступним великим інцидентом у продакшені. Зв'язок є — він просто відкладений у часі.
Рекомендуємо курси по темі
КОГО НАСПРАВДІ МОЖНА ЗАМІНИТИ
Замінити можна людину, яка виконує інструкції по кроках. Автоматизувати можна перевірку того, що вже відомо і передбачено.
Не можна замінити людину, яка думає про продукт як систему. Яка запитує «а що якщо» до того, як це питання поставить користувач у найгірший момент. Яка перетворює знайдені проблеми на зрозумілу розмову про ризики з людьми, які приймають рішення.
Саме зараз, коли AI генерує код швидше ніж будь-коли, а релізи відбуваються щодня — системне мислення про якість стає ціннішим. Не тому що так красиво звучить. А тому що швидкість без нього просто швидше приводить до проблем.
