10 задач QA на перший місяць роботи: потренуйся заздалегідь

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

Але хороша новина в тому, що більшу частину того, чим ти займешся в перший місяць, можна відрепетирувати заздалегідь. Ми підібрали 10 найтиповіших задач розберемо десять задач QA-спеціаліста, щоб ти відрепетирував їх до виходу на роботу.

Хто такий QA і чим він зайнятий у перший місяць

QA (quality assurance, забезпечення якості) стежить за тим, щоб продукт працював так, як задумано, і знаходить проблеми раніше за користувача. 

Джуніор у перший місяць роботи здебільшого:

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

Але при цьому роботу тестувальника часто плутають із роллю розробника:

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

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

Чому варто відрепетирувати все заздалегідь

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

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

За цією арифметикою стоять конкретні суми:

1. Година простою критичного застосунку у великій компанії коштує більше 300 000 доларів.
2. Середня ціна витоку даних у США вже дійшла до 9,44 мільйона доларів (CloudQA). 
3. Команди розробки витрачають 30-50% часу на виправлення багів і незаплановані переробки. 

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

Ринок це цінує і в грошах. За зимовим опитуванням DOU за грудень 2025 року медіанна зарплата Junior QA в Україні зросла до 887 доларів, а загальна медіана по QA досягла 2250 доларів – це рекорд за весь час спостережень (DOU).

Хочеш не просто читати про задачі QA, а почати готуватися до них на практиці? На курсі QA від Genius.Space ти зможеш системно розібратися в тестуванні і підійти до першої роботи впевненіше.

Десять задач, до яких можна підготуватися

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

1. Вивчити продукт очима користувача. Відкрий застосунок і пройди основні сценарії: реєстрацію, вхід, оплату, ключові кнопки. Усе, що здалося дивним, записуй – це перші кандидати в баги.
2. Налаштувати оточення і отримати доступи. У перший день ти запросиш акаунти в баг-трекері, тестовий стенд і посилання на документацію. Поки доступів немає, робота стоїть, тож збери список потрібного заздалегідь і спокійно нагадуй про нього команді.
3. Прочитати вимоги і поставити питання. Тобі дадуть user story або опис фічі з критеріями приймання. Твоя робота – зрозуміти, яка поведінка вважається правильною, і уточнити все, що описано розмито.
4. Пройти смоук-тест. Смоук перевіряє, що базові функції взагалі запускаються після свіжого білда. Це перше, що тобі довірять робити самому.
5. Відтворити чужий баг. Візьми вже заведену задачу і повтори кроки, щоб побачити проблему своїми очима. Якщо баг не повторюється, це теж результат, про який потрібно повідомити.
6. Написати свій перший баг-репорт. Знайдену проблему треба описати так, щоб розробник повторив її без жодного питання. Як це зробити по кроках – у наступному розділі.
7. Скласти тест-кейси на маленьку фічу. Тобі дадуть невеликий шматок функціональності і попросять описати, що і як перевіряти. Почни з позитивних сценаріїв, потім додай негативні і граничні значення.
8. Прогнати регресію. Після правок розробників потрібно перевірити, що старі функції не зламалися. Часто це готовий чек-лист, який ти проходиш по пунктах.
9. Перевірити фікс і закрити баг. Коли розробник пише «пофіксив», ти повторюєш кроки з репорту і дивишся, чи зникла проблема. Задача закривається тільки після цього.
10. Долучитися до командних ритуалів. Стендапи, грумінг і планування – це ті місця, де ти розповідаєш про свій статус і чуєш контекст проєкту.

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

Знайомство з продуктом, читання вимог і смоук відпрацьовуються на будь-якому публічному застосунку: заведи акаунт де завгодно і пройди шлях користувача з блокнотом. 

Баг-репорти, тест-кейси і роботу в трекері найпростіше репетирувати на безкоштовному тарифі Jira або Qase.

Із десяти задач дві відбирають у джуніора найбільше сил – зрозумілий баг-репорт і перші тест-кейси. На них і зупинимося докладніше.

Як написати перший баг-репорт

Зрозумілий баг-репорт відповідає на три питання – що зламалося, як це повторити і що мало було статися замість цього. Чим менше питань залишається в розробника, тим швидше вийде правка.

Західні QA-гайди сходяться в наборі обов’язкових полів: це заголовок, оточення, кроки відтворення, очікуваний і фактичний результат, доказ і оцінка серйозності (BrowserStack). 

Збери свій перший репорт за таким порядком:

1. Придумай заголовок, з якого одразу зрозуміла суть. Погано: «Оплата не працює». Добре: «Помилка 500 при оплаті карткою Visa на кроці підтвердження, Chrome 120, staging».
2. Вкажи оточення. Браузер і його версія, операційна система, пристрій, стенд. Частина багів живе тільки в одній зв’язці, і без цих даних розробник їх не побачить.
3. Опиши кроки відтворення по порядку і нумеруй їх. Перший крок – звідки стартуємо (URL або екран), останній – дія, після якої з’являється проблема. Кожен крок містить одну дію, щоб по ньому можна було пройти буквально.
4. Розділи очікуваний і фактичний результат. Очікуваний – що мало статися після останнього кроку. Фактичний – що сталося насправді, без домислів про причину.
5. Додай доказ. Скриншот, коротке відео, лог із консолі або відповідь сервера. Візуальний доказ знімає половину уточнювальних питань.
6. Простав severity і priority. Severity – технічна тяжкість поломки, priority – ділова терміновість правки. Ці два поля незалежні, і джуніор частіше помиляється саме в їх змішуванні.

Різниця між severity і priority збиває з пантелику майже всіх новачків, і краще запам’ятати її на прикладах. Косметичний одрук на сторінці оплати має низьку severity, але високий priority, тому що його бачить кожен покупець. Критичний збій в адмінці, якою користуються двоє людей, навпаки, тяжкий за severity і терпимий за priority.

Severity	Що значить	Приклад
Critical	продукт не запускається або падає, обійти не можна	застосунок крашиться при вході
Major	ламається важлива функція, обхідний шлях є	товар не зберігається в кошику
Minor	функція працює, але з вадою	з’їжджає верстка кнопки на мобільному
Trivial	косметика, на роботу не впливає	одрук у тексті листа

З тест-кейсами логіка схожа. Береш маленьку фічу, наприклад форму входу, і описуєш перевірки від простого до складного: 

• спочатку вхід із вірними даними, 
• потім із невірним паролем, 
• потім порожні поля і надто довгі значення. 

Так ти закриваєш позитивні, негативні і граничні сценарії, окрім очевидного «щасливого шляху».

Інструменти, які варто спробувати до співбесіди

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

Інструмент	Для чого	Складність	Ціна
Jira	задачі і баг-трекінг	середня	платний, є безкоштовний тариф до 10 людей
Qase / TestRail	зберігання і прогін тест-кейсів	проста–середня	платні, у Qase є безкоштовний тариф
Chrome DevTools	верстка, консоль, мережеві запити	проста	безкоштовно
Postman	ручна перевірка API	середня	безкоштовно, є платні тарифи
Charles / Fiddler	перехоплення і аналіз трафіку	складна	тріал або безкоштовна версія

Тарифи в інструментів час від часу змінюються, тож перед встановленням зазирни на сайт розробника. Для старту вистачить зв’язки Jira плюс DevTools: у першій ти вчишся заводити і вести баги, у другій – бачити, що відбувається всередині сторінки: помилки в консолі і мережеві запити. Postman підключай, коли дійдеш до перевірки бекенду.

Читай також: Скільки заробляє QA-тестувальник у 2026 році: порівняння зарплат в Україні та за кордоном

Розбір ситуації: шлях одного баг-репорту

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

Джуніор Аня на другому тижні помітила, що не проходить оплата. Вона завела задачу із заголовком «Оплата не працює» і текстом «натискаю кнопку, нічого не відбувається». Через годину розробник повернув тікет із питаннями: 

• на якому кроці, 
• якою карткою, 
• у якому браузері, 
• чи є помилка в консолі. 

Задача повисла, а час пішов.

Аня переписала репорт заново. Заголовок став точним: «Помилка 500 при оплаті карткою Visa на кроці підтвердження, Chrome 120, staging». Вона додала п’ять пронумерованих кроків, розвела очікуваний і фактичний результат, додала скриншот консолі з кодом помилки. 

Розробник відтворив проблему за сорок хвилин і знайшов причину в обробнику платежу.

Обидві версії писала одна й та сама людина з одним і тим самим старанням, уся різниця звелася до структури. Перший варіант змусив розробника гадати і перемикатися між задачами, другий дав йому всі дані одразу.

Чек-лист на перший тиждень

За перший тиждень на робочому місці тобі потрібно:

• отримати доступи до баг-трекера, тестового стенда і документації;
• дізнатися, де команда заводить баги і за яким шаблоном;
• пройти основні користувацькі сценарії продукту;
• з’ясувати, як влаштований реліз-флоу і хто його запускає;
• розібратися, чим staging відрізняється від production на проєкті;
• уточнити, що входить у твою зону відповідальності, а що ні;
• знайти ментора або бадді і домовитися, коли йому можна ставити питання;
• завести особистий файл із термінами і питаннями, які трапилися за день.

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

Три промпти, які прискорять підготовку

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

Ціль: швидко накидати тест-кейси на форму і не забути сценарії. Промпт: «Ти досвідчений QA-інженер. Ось опис форми реєстрації: [встав опис]. Склади список тест-кейсів – позитивні, негативні і граничні значення. Для кожного вкажи кроки, очікуваний результат і severity.»

Ціль: зрозуміти, чого не вистачає у твоєму баг-репорті, до відправлення розробнику. 

Промпт: «Перевір мій баг-репорт як ревʼюер. Ось він: [встав текст]. Скажи, яких даних не вистачає для відтворення, і запропонуй точніший заголовок.»

Ціль: не пропустити неясні місця в user story перед тестуванням. Промпт: «Ось user story і критерії приймання: [встав]. Постав 10 уточнювальних питань, які поставив би тестувальник, щоб знайти прогалини у вимогах і граничні випадки.»

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

Якщо ці задачі здалися тобі цікавими, значить QA може бути хорошим напрямом для старту в IT. На курсі QA від Genius.Space ти зможеш пройти шлях від бази до практики і підготуватися до перших реальних задач.

Часті запитання

Чи потрібно вміти програмувати, щоб почати в QA? 

На старті в ручному тестуванні код майже не потрібен. Базовий SQL і розуміння, як влаштований HTTP-запит, знадобляться через кілька місяців, а мови програмування – уже при переході в автоматизацію.

Чим тестувальник відрізняється від розробника? 

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

Що важливіше в перший місяць – швидкість чи уважність? 

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

Скільки багів я маю знаходити? 

Жодної норми в штуках немає, і гнатися за числом шкідливо. Один точно описаний критичний баг цінніший за десяток косметичних причіпок.

Що робити, якщо баг не відтворюється? 

Усе одно завести задачу і чесно вказати частоту, наприклад «повторилося 2 рази з 10». Розробнику важливо знати про плаваючу проблему, навіть якщо ти не спіймав її стабільно.

Чи обов’язковий сертифікат на кшталт ISTQB? 

Не обов’язковий, але на старті він відчутно впливає на дохід. За даними DOU, Junior Manual QA із сертифікацією заробляють у середньому на 38% більше, ніж без неї

Скільки заробляє джуніор-тестувальник в Україні? 

Медіана Junior QA у грудні 2025 року – 887 доларів чистими, і це перше зростання з 2022 року. Далі цифра швидко росте з переходом на Middle.

Manual чи Automation обрати новачку? 

Почни з manual, щоб зрозуміти сам процес тестування і продукт. Автоматизацію беруть поверх цієї бази, і перехід туди пізніше дає прибавку до зарплати.

Що відповідати на стендапі в перший тиждень? 

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

Як швидко розібратися в незнайомому продукті? 

Пройди його як звичайний користувач до кінця хоча б одного сценарію, а паралельно читай вимоги на цей шматок. Зв’язка «пройшов сам плюс прочитав, як має бути» дає розуміння швидше, ніж читання документації у відриві від інтерфейсу.

Чи нормально ставити багато питань? 

Так, у перший місяць це очікувано, і хороший ментор до цього готовий. Єдине прохання команди зазвичай одне: спочатку п’ять хвилин пошукай відповідь сам, потім питай.

Словник термінів

Цих слів вистачить, щоб розуміти 90% розмов команди в перші тижні. 

Термін	Значення
QA	Забезпечення якості, робота над тим, щоб продукт відповідав очікуванням.
QC	Контроль якості, перевірка готового результату на відповідність вимогам.
Тестування	Процес пошуку розбіжностей між тим, як продукт працює, і тим, як має.
Баг (дефект)	Помилка в роботі програми, поведінка, що відрізняється від очікуваної.
Баг-репорт	Опис знайденого дефекту з кроками, результатами і доказом.
Тест-кейс	Набір кроків і очікуваний результат для перевірки одного сценарію.
Чек-лист	Список того, що потрібно перевірити, без детальних кроків.
Тест-план	Документ про те, що, як і в які строки тестуватиметься.
Precondition	Умова, яка має виконуватися до початку кроків тест-кейсу.
Кроки відтворення	Пронумерована послідовність дій, що приводить до бага.
Очікуваний результат	Поведінка, яка вважається правильною за вимогами.
Фактичний результат	Те, що відбувається насправді при виконанні кроків.
Severity	Технічна тяжкість бага, ступінь поломки продукту.
Priority	Ділова терміновість виправлення бага.
Смоук-тест	Швидка перевірка, що базові функції запускаються після нового білда.
Саніті (sanity)	Вузька перевірка конкретної області після точкової правки.
Регресія	Перевірка старих функцій на предмет поломки після змін.
Функціональне тестування	Перевірка того, що функції роблять те, що повинні.
Нефункціональне тестування	Перевірка швидкості, навантаження, зручності і безпеки.
Exploratory	Дослідницьке тестування без заздалегідь написаних кейсів.
Позитивний тест-кейс	Сценарій із коректними даними і очікувано успішним результатом.
Негативний тест-кейс	Сценарій із некоректними даними для перевірки реакції на помилку.
Граничні значення	Перевірка на краях допустимого діапазону, наприклад порожнє і максимально довге поле.
Оточення (environment)	Набір умов, у яких працює продукт: браузер, ОС, стенд.
Staging	Тестовий стенд, наближений до бойового, де перевіряють перед релізом.
Production	Бойове середовище, яким користуються реальні люди.
Білд	Зібрана версія застосунку, готова до перевірки.
Реліз	Випуск версії продукту користувачам.
Спринт	Короткий робочий відрізок, зазвичай один-два тижні, з набором задач.
Стендап	Коротка щоденна зустріч команди про статус задач.
Грумінг	Зустріч, де команда розбирає і уточнює майбутні задачі.
Acceptance criteria	Критерії приймання, умови, за яких задача вважається виконаною.
User story	Опис вимоги від особи користувача у форматі «як X, я хочу Y, щоб Z».
Баг-трекер	Система для заведення і відстеження багів, наприклад Jira.
API	Інтерфейс, через який частини застосунку обмінюються даними.