Резюме тестувальника без досвіду: як потрапити в QA

Перше резюме тестувальника зазвичай пишуть у найнезручнішій ситуації: курси чи самостійне навчання позаду, комерційного досвіду немає, а у вакансіях Junior QA все одно просять «розуміння процесів» і «досвід роботи з Jira». Гарна новина в тому, що для ручного тестування досвід можна показати не лише посадою в компанії. Тестові документи, баг-репорти й перевірені API — це ті самі артефакти, які QA створює на роботі. Нижче — як зібрати такі докази, як їх описати в резюме і яких помилок уникати.

Що шукають у резюме Junior Manual QA

Від джуніора ніхто не чекає знання всіх інструментів. Рекрутер і QA Lead, який переглядає резюме, насамперед хочуть побачити кілька речей:

• Розуміння бази. Що таке тест-кейс і чек-лист, чим severity відрізняється від priority, які бувають види тестування, як виглядає життєвий цикл бага.
• Уміння знаходити й описувати дефекти. Баг-репорт, з яким розробник може працювати без уточнень, — одна з головних навичок ручного тестувальника.
• Технічну грамотність на рівні користувача-плюс. Відкрити DevTools і подивитися запит у вкладці Network, надіслати запит у Postman, написати простий SELECT.
• Англійську, достатню для читання документації та написання баг-репортів.
• Докази, а не лише слова. Посилання на реальні документи, які можна відкрити і переглянути.

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

Структура резюме тестувальника без досвіду

Резюме джуніора має вміщатися на одну сторінку. Порядок блоків трохи відрізняється від класичного: проєкти стоять вище за попередню роботу, бо саме вони доводять, що ви вмієте тестувати.

1. Контакти — імʼя, місто або формат роботи, телефон, пошта, LinkedIn і посилання на портфоліо (GitHub або папка з документами).
2. Профіль — 3–4 речення про те, хто ви і що вже вмієте.
3. Навички, згруповані за темами.
4. Проєкти — навчальне тестування реальних сайтів, застосунків і API.
5. Досвід роботи — попередня робота поза IT, описана через релевантні навички.
6. Навчання і сертифікація.
7. Мови.

Загальні принципи резюме для тих, хто починає з нуля в будь-якій професії, розібрано в статті Резюме без досвіду роботи. Тут зосередимося на тому, що специфічне для QA.

Навички: як згрупувати, щоб читалося

Суцільний рядок із двадцяти слів через кому рекрутер пробігає за секунду і нічого не запамʼятовує. Краще розбити навички на чотири групи:

• Теорія тестування: SDLC і STLC, види та рівні тестування (functional, regression, smoke), техніки тест-дизайну (класи еквівалентності, граничні значення, таблиця рішень), життєвий цикл дефекту, severity і priority.
• Інструменти: Jira, Google Sheets для тест-кейсів, Postman, Chrome DevTools, TestRail або інша TMS — лише ті, з якими ви справді працювали.
• Технічна база: HTTP-методи й коди відповідей, JSON, основи SQL (SELECT, WHERE, JOIN), базовий HTML і CSS, основи Git.
• Англійська: рівень за шкалою CEFR.

Як загалом відбирати й формулювати навички, щоб вони не виглядали порожнім переліком, — у статті Навички для резюме.

Портфоліо: як створити досвід, якого ще немає

Проєкти для резюме тестувальника можна зробити самостійно за кілька тижнів. Головне — щоб результат був публічним і охайним: посилання на документ, відкритий для перегляду, або репозиторій на GitHub.

Тестування публічного сайту або застосунку

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

Тест-кейси і баг-репорти в Google Sheets, Docs або на GitHub

Тест-кейси зручно вести в Google Sheets: ID, назва, передумови, кроки, очікуваний результат, фактичний результат, статус. Баг-репорти оформлюйте за класичною структурою: заголовок, середовище (браузер, ОС, пристрій), кроки відтворення, очікуваний і фактичний результат, severity, скриншот або відео. Якщо знайомі з Git, створіть репозиторій і заведіть баги як issues — це заразом показує базове вміння працювати з GitHub. Відкриваючи доступ до документів, перевірте, що посилання працює в режимі інкогніто.

Тестування API в Postman

Для практики є публічні навчальні API, створені саме для експериментів, наприклад JSONPlaceholder. Складіть колекцію запитів GET, POST, PUT, DELETE, перевірте коди відповідей і структуру JSON, додайте кілька простих перевірок у вкладці Tests. Колекцію можна експортувати й викласти на GitHub разом із коротким README.

Практика SQL

Встановіть локально SQLite або PostgreSQL, створіть невелику базу (наприклад, користувачі та замовлення) і напишіть запити, які знадобилися б тестувальнику: знайти замовлення без користувача, перевірити дублікати, порахувати записи за статусом. Файл із запитами і коротким поясненням — ще один проєкт у портфоліо.

Приклад опису проєкту в резюме

Проєкт описується так само, як посада: назва, період, посилання і 3–4 пункти з конкретними діями. Ось умовний приклад:

Навчальний проєкт: тестування вебмагазину електроніки (самостійний проєкт, 2026) — посилання на документи

• Проаналізував функції реєстрації, пошуку та кошика; склав чек-лист на 60 перевірок і 25 тест-кейсів із застосуванням класів еквівалентності та граничних значень.
• Провів функціональне тестування в Chrome і Firefox та на мобільному розширенні екрана; оформив 12 баг-репортів із кроками відтворення, severity і скриншотами.
• Перевірив запити кошика у вкладці Network у DevTools і знайшов розбіжність між ціною в інтерфейсі та у відповіді сервера.
• Вів задачі та дефекти на Kanban-дошці в Jira.

Цифри в прикладі умовні — у своєму резюме вказуйте реальні кількості з власних документів. Повний зразок резюме з усіма блоками дивіться на сторінці повний зразок резюме QA.

Приклад профілю

Слабко: «Відповідальний і комунікабельний, швидко навчаюся, хочу розвиватися в IT.»

Краще: «Junior Manual QA без комерційного досвіду, пройшов навчання з основ тестування ПЗ. Самостійно протестував вебмагазин і публічне API: написав тест-кейси, чек-листи та баг-репорти, працював у Jira, Postman і DevTools. Маю 3 роки досвіду в підтримці клієнтів — звик детально відтворювати проблеми користувачів і чітко їх описувати. Англійська — B1.»

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

Як описати попередній досвід поза IT

Попередня робота — не порожнє місце в резюме, якщо описати її через навички, потрібні тестувальнику:

• Підтримка клієнтів — уточнення проблеми, відтворення кроків, передача запитів технічній команді з точним описом.
• Бухгалтерія, логістика, робота з документами — уважність до деталей, звірка даних, пошук розбіжностей.
• Продажі, адміністрування — робота з CRM або обліковими системами, розуміння того, як користувач взаємодіє з продуктом.
• Викладання, написання інструкцій — вміння структуровано документувати процеси.

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

Курси, сертифікація й англійська

У блоці навчання вкажіть курси з тестування, які ви пройшли, з назвою організатора та роком. Не варто перелічувати всі безкоштовні відеоуроки — достатньо того, що дало основу для проєктів. Існує міжнародна сертифікація ISTQB Foundation Level; якщо вона у вас є, вкажіть її окремим рядком, якщо ви до неї готуєтеся — можна так і написати.

Рівень англійської вказуйте чесно, за шкалою CEFR: A2, B1, B2. Формулювання на кшталт «вільно» або «технічна англійська» без рівня мало що кажуть, а завищений рівень швидко стає очевидним на співбесіді, частину якої можуть провести англійською. Якщо плануєте відгукуватися на вакансії іноземних компаній, знадобиться окрема версія резюме — див. Резюме англійською.

Типові помилки

• Інструменти, з якими ви не працювали. Якщо в навичках стоїть TestRail, на співбесіді можуть попросити розповісти, як ви в ньому вели прогони. Краще менше, але з підтвердженням.
• Selenium без жодного рядка коду. Автоматизація — окремий напрям. Якщо у вас немає репозиторію з автотестами, Selenium у резюме Manual QA викликає більше запитань, ніж додає балів.
• Загальні якості замість фактів. «Відповідальний, уважний, комунікабельний» пише майже кожен. Уважність краще показати 12 акуратними баг-репортами.
• Посилання, які не відкриваються. Закритий доступ до Google Docs чи порожній репозиторій працюють проти вас.
• Помилки в самому резюме. Для тестувальника друкарська помилка в резюме — особливо невдалий знак. Перечитайте текст так, ніби шукаєте баги.
• Одна версія для всіх вакансій. Якщо у вакансії згадано мобільне тестування або API, підніміть відповідний проєкт вище — як це зробити швидко, пояснюємо в статті Як адаптувати резюме під вакансію.

Де шукати вакансії Junior QA в Україні

Вакансії для початківців у тестуванні публікують на Djinni, у розділі вакансій DOU, на Work.ua та в LinkedIn. На Djinni і DOU варто заповнити профіль кандидата, а в LinkedIn — вказати бажану роль у заголовку. Трапляються також стажування та позиції Trainee QA, які компанії анонсують на своїх сайтах і в соцмережах.

Перед відправкою перевірте резюме в ATS-чекері разом із текстом вакансії: він покаже, яких ключових слів бракує і чи коректно читається файл. Для джуніора також важливий короткий супровідний лист — 3–5 речень про те, чому вам цікавий QA і яким проєктом ви пишаєтеся найбільше.

Коротко

• Без комерційного досвіду головне в резюме тестувальника — докази: тест-кейси, баг-репорти, колекція Postman, SQL-запити за посиланням.
• Ставте блок проєктів вище за попередню роботу і описуйте кожен проєкт 3–4 пунктами з конкретними діями.
• Групуйте навички: теорія тестування, інструменти, технічна база, англійська.
• Попередній досвід поза IT описуйте через уважність, відтворення проблем і документування.
• Не вказуйте інструменти, з якими не працювали, і рівень англійської, якого не підтвердите.