QA Automation CV у 2026: булети, що бачать інженера

Знайомий QA Auto з трьома роками досвіду скинув CV з питанням: "Стек ок, чого не дзвонять". Відкриваю, перші три булети: "Писав автотести на Selenium", "Писав автотести на Cypress", "Писав автотести на Playwright". Три фреймворки, одне дієслово, нуль інформації. З цього рекрутер дізнається тільки, що ти вмієш писати назви тулз без помилок.

Чому всі QA Auto CV читаються однаково

Планка для QA Auto у 2025-2026 тихо піднялася. Фреймворки стали базою, у будь-якого джуна після курсів у CV вже стоять Selenium і Cypress з першого дня. Виграє вже не той, у кого більше тулз, а той, хто показав володіння шматком інфраструктури, на яку команда покладається щодня. Більшість CV у цій ролі досі читаються як Manual CV, до якого зверху насипали назв фреймворків: ті самі пасивні дієслова, ті самі відсутні числа, та сама енергія "написав N тестів". Звідси й однаковість.

Чим CV QA Auto має реально відрізнятися від QA Manual

Manual CV доводить, що ти думаєш як атакуючий: знаходиш edge-кейси і чітко їх документуєш. Auto CV має доводити інше: що ти будуєш системи, від яких залежать інші інженери. Manual-булет звучить так: "знайшов 47 critical багів, блокували реліз до фіксу". Auto-булет звучить так: "побудував фреймворк, який запускається на кожному PR і дає фідбек за 12 хвилин". Центр ваги зміщується з пошуку багів на володіння шматком CI. Якщо твоє Auto CV досі читається як CV bug-finder, до якого приклеїли Selenium, тебе прочитають як Manual, що вивчив тулзу, а не як інженера, що щось будує.

Анти-патерн "написав N тестів" і чим його замінити

"Написав 400+ автотестів", це найчастіший булет, який я бачу, і один з найслабших. Він каже мені, що ти видав обсяг, але нічого про те, що цей обсяг дав команді. Інженерний булет має три шари: що ти побудував, що воно замінило, що змінилось завдяки цьому. Порівняй: "Написав 420+ API-тестів на REST Assured" і "Написав 420+ API-тестів на REST Assured, що дозволило ловити 65% багів ще до фронтенд-релізу". Факт той самий. Другий варіант каже hiring-менеджеру, що ти розумієш, у якому місці воронки твої тести спрацьовують.

Чотири булети, які реально сигналять інженерну роботу

• Побудував з нуля фреймворк на Playwright + TypeScript, покрив 78% критичних сценаріїв, скоротив регресію з 3 днів до 4 годин
• Знизив flaky-тести з 18% до 3% через рефакторинг локаторів і стабілізацію очікувань по всьому suite
• Налаштував паралельний запуск на Selenium Grid + Docker, прогон suite впав з 95 до 22 хвилин
• Перевів legacy Selenium-тести на Playwright, кодова база зменшилась на 35%, час підтримки впав удвічі

Зверни увагу, що їх об'єднує. У кожному є конкретне число, до і після, і щось, що команда реально відчула. Жоден не каже "написав тести". Кожен звучить як інженерне володіння шматком системи.

Як список фреймворків видає junior проти senior

Junior QA Auto у списку інструментів пише все, чого торкався: "Selenium, Cypress, Playwright, Puppeteer, TestCafe, WebdriverIO, Nightwatch". Сім тулз з однаковою вагою, і немає підказки, з якою з них реально працював два роки на проді, а з якою провів вечір по туторіалу. Senior пише дві або три, але з глибиною: "Playwright (основний, 2 роки), Selenium (legacy-міграція), Cypress (на рівні читання на попередньому проєкті)". Сигнал старшинства, у пояснювальному дужці. Рекрутерка, що читає другий варіант, одразу знає, про який фреймворк питати на скринінгу.

CI/CD-робота, яку рекрутери не помічають

Більшість QA Auto-кандидатів реально роблять CI/CD-роботу і потім не пишуть її у CV, бо "це ж не зовсім QA". Помилка. Один булет, що перемикає тебе з "пише тести" на "володіє тест-пайплайном", звучить десь так: "Інтегрував автотести у GitLab CI, кожен PR отримував фідбек за 12 хвилин замість ручної перевірки на наступний день". Це речення каже hiring-команді, що ти розумієш, у якому місці dev-флоу живе твоя робота. Додай поряд другий булет про reporting-інфру: "Впровадив Allure-репорти і дашборд у Grafana, час розбору падінь впав на 40%". Усе, ти вже звучиш як tooling-інженер, а саме цим і є senior QA Auto позиції у 2026.

Що дописати у навички у 2026

• Запуск тестів у контейнерах (Docker, іноді Kubernetes для паралельних suite)
• API contract testing (Pact або подібне) поверх REST Assured / Postman
• Visual regression-тулзи (Percy, Applitools, Playwright snapshots)
• Observability для тест-ранів: Allure, ReportPortal, дашборди в Grafana
• Одна мова програмування на рівні чистого коду, не "знайомий з синтаксисом"
• Публічний GitHub з хоча б одним демо-фреймворком на публічний API

Різниця у зарплаті між Manual і Auto у 2026

Розрив реальний і за останній рік він збільшився. Mid QA Manual в Україні живе у вилці $1 200-2 000 на місяць, mid QA Auto, $1 800-3 200. В ЄС, 2 500-3 800 EUR за Manual mid проти 3 800-5 800 EUR за Auto mid. У США різниця на mid-рівні приблизно $25-35k на рік. Auto-премію платять не за знання фреймворку як такого, а за leverage. Один QA Auto, що тримає стабільний suite, звільняє два Manual-місця. Це арифметика, яку рахує hiring-менеджер, і твоє CV або показує цей leverage, або ні.

Типові помилки, через які CV відсіюють

• Сім фреймворків без жодного уточнення глибини, читається як випускник курсів
• Відсутній GitHub або профіль з одним форком і нулем власного коду
• "Написав 1000+ тестів" без жодної метрики, що ці тести зловили або зекономили
• Жодної згадки про CI, виглядає, ніби тести живуть тільки на твоєму ноуті
• У заголовку "QA Engineer" замість "QA Automation Engineer", по якому рекрутери реально шукають
• Нуль глибини у мові: одразу Java, Python, JS, TS, Kotlin списком в один рядок

ATS-пастка саме для QA Auto

Вакансії на цю роль пишуть "QA Automation Engineer", "Test Automation Engineer" і "SDET" приблизно як синоніми, залежно від компанії. ATS слабо матчить CV, у якому стоїть тільки одна з цих назв. Постав усі три десь у документі: заголовок як основну, інші дві у тагтлайні або summary. Дешевий хід, відчутний приріст recall.

Питання на інтерв'ю, на якому горять QA Auto

"Опиши, як стабілізуєш flaky-тест". Junior каже: "додам sleep". Mid каже: "заміню sleep на explicit wait". Senior каже: "спочатку перевіряю, чи flakiness у тесті, чи у системі під тестом. Якщо у тесті, дивлюся на стратегію локаторів, network conditions, таймінги анімацій і shared state між тестами. Якщо у системі, заводжу тікет, бо flaky-тест часто ховає реальний race condition". Остання відповідь сигналить, що для тебе тести, це діагностичний інструмент, а не нагрузка. Hiring-менеджери це запам'ятовують.