Я б сказав так: у QA CV варто лишати тільки той стек, який я можу підтвердити роботою. Рекрутер часто дивиться резюме 5–10 секунд, а ATS шукає точні назви інструментів. Тому в CV мають бути конкретні технології, чіткі категорії і короткий зв’язок із моїми задачами.
Ось суть статті в кількох пунктах:
- Для Manual QA я вказую:
- типи тестування: functional, regression, smoke, exploratory, UI, acceptance
- платформи: Web, Mobile, Desktop
- роботу з документацією: test cases, checklists, bug reports, test reports
- інструменти: Jira, Azure DevOps, TestRail, Xray, Confluence, Slack
- Для Automation QA я виношу стек окремо:
- мови: Java, Python, JavaScript, TypeScript, C#, SQL
- UI-автоматизація: Selenium, Playwright, Cypress
- API: Postman, Newman, REST Assured, Karate, Swagger/OpenAPI
- тестові бібліотеки: JUnit, Mockito
- Для CI/CD та інфраструктури я додаю лише те, з чим працював у процесі тестування:
- Git, GitHub, GitLab, Bitbucket
- Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps Pipelines
- Docker, Kubernetes, Linux
- PostgreSQL, MySQL, MongoDB, Grafana, Browser DevTools
- Я не змішую manual і automation в один список, якщо хочу, щоб CV читалося без зайвого шуму.
- Я не пишу просто назви інструментів, а показую дію:
- баг-репорти в Jira
- тест-кейси в TestRail
- API-колекції в Postman
- автозапуск тестів через Jenkins або GitLab CI/CD
- Я підлаштовую назви під вакансію: якщо в описі є Playwright або GitHub Actions, саме так і пишу в CV.
Нижче – швидке порівняння, яке допомагає одразу зрозуміти різницю.
| Напрям | Що я вказую |
|---|---|
| Manual QA | типи тестування, платформи, баг-трекінг, тест-менеджмент, документація |
| Automation QA | мови, UI-фреймворки, API-інструменти, тестові бібліотеки |
| Hybrid QA | manual + automation, але окремими блоками |
| CI/CD та support tools | Git, пайплайни, БД, Docker, Linux, DevTools – лише якщо були в роботі |
Коротке правило просте: менше списків, більше точності. Якщо інструмент був у роботі – пишу. Якщо бачив його лише на курсі або один раз – прибираю.
QA CV Tech Stack: Manual vs Automation vs CI/CD
Build The Perfect Resume For QA Jobs Step By Step
sbb-itb-70ff7e0
Що вказувати для Manual QA
Для Manual QA в CV варто писати лише те, з чим ви справді працювали. Без прикрас. Якщо інструмент або тип тестування бачили один раз, але не використовували в роботі, краще його не додавати.
Для Manual QA зазвичай мають значення три речі: типи тестування, інструменти для роботи з дефектами і інструменти для документації.
Типи тестування, платформи та робота з документацією
Вказуйте ті типи тестування, які ви виконували на практиці: функціональне, регресійне, smoke, exploratory, UI, acceptance testing. Це дає змогу одразу зрозуміти, з якими задачами ви мали справу.
Так само з платформами: вкажіть Web, Mobile, Desktop – залежно від того, що саме тестували. Не все підряд, а лише ваш досвід.
Якщо ви регулярно писали тест-кейси, чеклісти, баг-репорти та звіти про тестування, це теж варто додати. Ключове слово тут – регулярно. Якщо робили це час від часу, краще не перебільшувати.
Баг-трекінг, тест-менеджмент та комунікація
Інструменти зручно ділити за категоріями. Так CV читається простіше, і рекрутер не продирається крізь суцільний список назв.
| Категорія | Інструменти |
|---|---|
| Баг-трекінг | Jira, Azure DevOps, Redmine |
| Тест-менеджмент | TestRail, Xray, SquashTM, HP ALM / Quality Center |
| Комунікація | Confluence, Slack, Microsoft Teams |
Якщо у вас є automation або API, їхній стек краще винести окремо. Не змішуйте його з manual-інструментами, інакше CV виглядатиме розмитим.
Як сформулювати інструменти, не перевантажуючи CV
Краще писати не просто назву інструмента, а що саме ви в ньому робили. Це звучить сильніше й одразу дає контекст.
Наприклад:
- баг-репорти в Jira
- тест-кейси в TestRail
- вимоги й звіти в Confluence
Тобто в стеку варто показувати дію, а не лише перелік назв. Якщо інструмент не використовували в проєкті, не додавайте його в CV.
І ще один момент: automation і API-інструменти відділяйте окремо, щоб не змішувати їх із manual-стеком.
Що вказувати для Automation QA та API-тестування
Стек Automation QA варто показувати окремим блоком: мови, фреймворки, інструменти для API та CI/CD. Після manual-стеку винесіть automation-інструменти окремо – так рекрутер одразу бачить, у чому ваш головний фокус.
Мови програмування та фреймворки для автоматизації
Вказуйте мови, якими ви писали тести: Java 8/11/17, JavaScript, TypeScript, Python, C#, SQL.
Фреймворки краще групувати за типом задач. Для UI-автоматизації підійдуть Selenium, Playwright або Cypress. Для unit- та інтеграційного тестування – JUnit, Mockito. Тут усе просто: залишайте лише те, з чим ви справді працювали на проєктах.
Якщо у вас був досвід із конкретною версією мови або фреймворку, вкажіть її прямо. Це дрібниця, але вона додає ясності.
Інструменти для API-тестування та як показати реальний досвід
Одна лише назва інструмента майже нічого не каже. Якщо пишете про Postman, одразу додавайте, що саме ви робили: створював колекції, запускав через Newman, перевіряв контракт у Swagger/OpenAPI. Якщо використовували скрипти, змінні середовища або глобальні змінні в Postman, теж варто це згадати.
Якщо у вакансії є вимога до REST Assured або Karate, і ви з ними працювали, ставте їх на перше місце. Це той випадок, коли порядок у списку має значення.
Нижче – коротке порівняння manual і automation-стеку.
Порівняння стеків: Manual QA vs Automation QA
| Категорія | Manual QA | Automation QA | Що вказати в CV |
|---|---|---|---|
| Основні інструменти | Баг-трекінг, тест-менеджмент | Selenium, Playwright, Cypress | Конкретні фреймворки та бібліотеки |
| API-тестування | Ручна перевірка API в Postman | Postman (скрипти), Newman, REST Assured, Karate | Автоматизація колекцій, інтеграція з CI/CD |
| Мови | Базовий SQL | Java, Python, JavaScript, TypeScript, C# | Рівень і контекст використання |
| Інфраструктура | Browser DevTools, логи | Docker, Jenkins, Git, Kubernetes | Досвід із середовищами та пайплайнами |
Далі цей стек доповнюють Git, CI/CD і платформені інструменти.
CI/CD, version control, platforms, and supporting tools
Після мов, фреймворків і API додайте інфраструктуру – але лише якщо вона справді була частиною вашого тестового процесу. Для hybrid та automation-ролей краще вказувати тільки ті інструменти, які напряму впливали на запуск, валідацію та підтримку тестів.
CI/CD, Git та основи інфраструктури
Якщо ви запускали тести в пайплайні, не пишіть просто назву інструмента. Покажіть, що саме робили. Наприклад: «Налаштував Jenkins jobs для запуску автотестів перед релізом» або «Конфігурував GitLab CI/CD для автоматичного запуску регресії на кожен Merge Request». GitHub Actions та Azure DevOps Pipelines варто згадувати тільки тоді, коли у вас був із ними практичний досвід.
З Git логіка така сама. Мало написати просто Git. Краще одразу додати дії: робота з гілками, pull/merge requests, розв’язання merge-конфліктів, code review для automation-скриптів. Якщо ви працювали через Bitbucket, GitLab або GitHub як платформу, вкажіть це окремо.
Потім можна додати середовища, бази даних і DevTools, якщо вони були частиною ваших перевірок.
Операційні системи, бази даних і DevTools
Linux є сенс згадувати, якщо ви перевіряли логи, налаштовували середовища або виконували базові дії на серверах. Docker і Docker Compose варто вносити лише тоді, коли ви самі підіймали тестові середовища, а не просто бачили їх у проєкті.
Для баз даних краще не зупинятися на загальному «SQL». Конкретика працює сильніше: PostgreSQL, MongoDB, MySQL – і відразу дія. Наприклад: «Писав SQL-скрипти для перевірки цілісності даних у PostgreSQL». Browser DevTools і Grafana теж доречні, якщо вони були частиною вашої щоденної роботи під час тестування.
Нижче – короткі формулювання, які добре працюють у CV.
Таблиця: Категорії QA-інструментів та формулювання для CV
| Категорія | Інструменти для CV | Приклад короткого формулювання в досвіді |
|---|---|---|
| Баг-трекінг | Jira, ServiceNow, Xray | Вів баги й покриття в Jira/Xray |
| Тест-менеджмент і документація | HP ALM, SquashTM, Confluence | Вів тест-сьюти й документацію |
| API-тестування | Postman, Newman, Swagger | Автоматизував API-перевірки в CI/CD через Newman |
| UI-автоматизація | Selenium, Playwright, Cypress | Писав і підтримував UI-автотести |
| CI/CD | GitLab CI/CD, Jenkins, Azure DevOps Pipelines | Налаштовував пайплайни для автозапуску тестів |
| Версіонування | Git, Bitbucket, GitHub | Працював з гілками, PR/MR і merge-конфліктами |
| Інфраструктура | Docker, Kubernetes, AWS | Піднімав і перевіряв тестові середовища |
| Бази даних та аналітика | PostgreSQL, MongoDB, MySQL, Grafana, DevTools | Перевіряв дані через SQL і логи в Grafana |
Як зробити tech stack коротким, релевантним і відповідним до вакансій
Що прибрати зі стеку
Після переліку manual, automation і CI/CD інструментів легко перейти межу й перетворити стек на довгий список “усього потроху”. Для QA це зазвичай не грає на руку. Короткий стек майже завжди виглядає сильніше за довгий, якщо він чітко відповідає ролі.
Залишайте тільки те, що напряму стосується вакансії. Прибирайте інструменти, які ви спробували один раз на курсі, застарілі технології без робочої практики та дублікати. Краще, коли стек короткий і зібраний за категоріями. Так його легше швидко прочитати й зрозуміти.
Після цього підправте назви інструментів і їхній порядок під конкретну вакансію.
Як адаптувати стек під кожну вакансію
Тут важливі не лише самі інструменти, а й те, як саме ви їх називаєте і в якому порядку показуєте. Найпростіший орієнтир – текст вакансії. Якщо назви у вашому CV збігаються з формулюваннями в описі, рекрутеру й hiring manager легше відразу побачити збіг.
Якщо у вакансії вказано GitLab CI, GitHub Actions або Playwright, саме ці назви й мають бути у CV. Без узагальнень і “схожих” замін. Це дрібниця, але вона часто вирішує, чи резюме виглядає влучним.
Порядок категорій теж має вагу. Те, що найбільше збігається з вакансією, ставте на початок. Простий принцип: найрелевантніше – першим.
Наприклад:
- для ролей у fintech варто винести вище тестування безпеки для fintech
- для ролей із фокусом на API – Newman, REST Assured та інтеграцію Postman-тестів у CI/CD
Якщо ви в активному пошуку, CV Postman може адаптувати CV під вакансії на DOU та Djinni й надсилати відгуки автоматично.
Висновок: мінімальна структура, яка працює
Логіка тут проста: працює короткий стек, який збігається з вакансією та підтверджений досвідом.
FAQs
Як показати рівень володіння інструментом?
Щоб показати рівень володіння інструментом у резюме, не зводьте все до сухого списку. Набагато краще, коли інструменти з’являються прямо в описі вашого досвіду та того, що ви зробили на практиці.
Так роботодавець бачить не лише назву сервісу чи програми, а й як саме ви з нею працювали.
Також не варто ставити собі оцінку за шкалою. Замість “Postman – 8/10” краще описати конкретні задачі. Наприклад: використовували Postman для тестування API, створення колекцій і інтеграції в CI/CD.
Такий підхід звучить сильніше, бо показує ваш досвід через дії, а не через самооцінку.
Чи варто додавати стек із курсів?
Так – але лише якщо у вас немає комерційного досвіду з цими технологіями. У такому разі стек дає рекрутеру більше контексту й допомагає швидше зрозуміти, що ви вже знаєте.
Але головне тут не змінюється: вирішальним фактором усе одно лишається практичний досвід, а не назви курсів чи програм, які ви пройшли.
Куди в CV краще винести tech stack?
Блок Tech stack краще винести в окремий розділ Skills або Technical Skills на першій сторінці CV – одразу після короткого Summary. Так рекрутеру та системам відбору простіше швидко зчитати ваші ключові компетенції.
Щоб усе виглядало охайно й читалося без зусиль, згрупуйте інструменти за категоріями:
- Test Management
- Bug Tracking
- Databases
- API Tools
- CI/CD
