Як manual QA перейти в automation

Питання формулюється як вибір між внутрішнім переходом, новою junior-позицією, part-time роботою та спробою одразу претендувати на middle-рівень. Перед вибором важливо усвідомити: automation — це спосіб раніше й дешевше отримувати feedback про якість, а не окрема від тестування діяльність.

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

Уміння писати код саме по собі не означає middle або senior automation-рівень. Потрібні test strategy, impact analysis, risk management, test planning і вміння обрати правильний рівень перевірки. ШІ спрощує написання коду, але не вирішує за інженера, що варто автоматизувати і який feedback справді потрібен команді.

Частину сценаріїв краще перевіряє автоматизація: великі масиви даних, інсталяції, API та повторювані комбінації. Інші властивості — usability, анімації, адаптивність і візуальна якість — часто потребують людської оцінки. Сильна роль поєднує обидва способи роботи.

Manual QA вже знає домен, продукт, архітектурні межі та командні процеси. Ці знання не зникають після появи коду, тому перехід на automation не повинен автоматично означати downgrade до junior. Це розширення набору інструментів для тих самих інженерних задач.

Практична домовленість може мати горизонт близько пів року: обрати дорогі end-to-end або data-heavy перевірки, автоматизувати їх і показати вимірний результат — швидший feedback та зекономлений ручний час. Досягнення такої цілі є аргументом для підвищення, а не для зниження зарплати.

Part-time junior automation додає новий домен, процеси, команду й онбординг, тому часто забирає вечори, але не дає пропорційної користі. На поточному проєкті вже відомо, які ручні сценарії тривають годинами, де нестабільне середовище і до кого звернутися по доступ або технічну зміну.

Рекомендований шлях — автоматизувати власну повторювану роботу й використати вивільнений час для наступних перевірок. Так з’являється реальний досвід із Playwright, Selenium або API tests, конкретні технічні проблеми для обговорення на співбесіді та портфоліо виконаних сценаріїв без подвійного онбордингу.

Знання test design, ризиків, вимог, bug reporting, Agile і тестової стратегії залишаються частиною роботи automation engineer. Quality assurance описується не як відповідальність однієї ролі, а як командний процес; автоматизація допомагає зробити його feedback loop швидшим.

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

Якщо менеджмент наполягає, що middle або senior manual QA має почати automation лише як junior, автор радить продовжити практику на знайомому продукті й паралельно готувати зміну компанії. Для співбесіди корисно підготувати конкретні приклади: які перевірки автоматизовано, які проблеми довелося вирішити і який feedback вони прискорили.

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

Шанс внутрішнього переходу залежить не стільки від типу компанії, скільки від зрілості конкретного promotion process, competency matrix і менеджера. У поточній компанії легше знайти корисний automation scope, бо вже відомі система й контакти; водночас саме там можуть бути найжорсткіші уявлення про старий грейд.

Фінальна рекомендація: спочатку перевірити можливість прозорої внутрішньої домовленості. Якщо компанія визнає automation як upskilling — залишатися простіше. Якщо вимагає необґрунтованого downgrade — набрати доказовий досвід на поточному продукті й шукати зовнішній перехід.