Manual QA

Процеси й Agile

Scrum, shift-left, релізи

Які церемонії є в Scrum і яка там роль QA?

Planning — оцінюю обсяг тестування, ризики, щоб тестування влізло в спринт.
Grooming / Refinement — ставлю питання до вимог, пропоную критерії приймання, шукаю граничні випадки.
Daily — статус, блокери: немає середовища, баг блокує тестування.
Review / Demo — показую або допомагаю показати результат.
Retrospective — що покращити в процесі якості.

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

Що таке Definition of Ready і Definition of Done?

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

DoD — коли задача вважається завершеною: код у main, code review пройдено, тести написано й пройдено, баги критичного рівня закрито, документацію оновлено.

QA впливає на обидва: не приймати в спринт задачу без критеріїв приймання і не закривати її без перевірки.

На співбесіді: Definition of Ready — критерії, коли задачу можна брати в роботу: зрозумілі вимоги, критерії приймання, макети. Definition of Done — коли вона завершена: код злитий, протестовано, критичних багів немає. Як QA я стежу за обома: без критеріїв приймання задачу в спринт не беремо, без перевірки — не закриваємо.

Що таке shift-left і як QA може дати ранній фідбек?

Shift-left — перенесення тестування якомога раніше в процес, бо дефект у вимогах у рази дешевший за дефект у проді.

Рев'ю вимог і макетів до початку розробки.
Участь у грумінгу: граничні випадки, негативні сценарії, суперечності.
Тест-кейси до того, як фіча готова, — розробник бачить, що перевірятиметься.
Тестування API, коли UI ще немає.

На співбесіді: Shift-left — це тестування якомога раніше. Я рев'ю вимоги й макети ще до розробки, на грумінгу питаю про граничні й негативні сценарії, пишу тест-кейси заздалегідь, щоб розробник бачив, що перевірятиметься, і тестую API ще до появи UI.

Як ти підтримуєш реліз і перевірку після релізу?

До релізу: регресія, перевірка release notes, підтвердження, що всі задачі релізу протестовані, рішення go/no-go разом з командою.

Під час і після: smoke на проді критичних сценаріїв (без реальних транзакцій або на тестових акаунтах), перевірка міграцій і конфігурацій, моніторинг помилок і логів у перші години, готовність до rollback.

На співбесіді: Перед релізом я проводжу регресію і даю рекомендацію go або no-go. Після деплою роблю smoke критичних сценаріїв на проді на тестових акаунтах, перевіряю логи й моніторинг і разом з командою знаю, за яких умов робимо відкат.

Роль QA в Scrum-церемоніях і Definition of Done

На грумінгу й sprint planning QA аналізує user stories з точки зору тестованості, ставить питання по граничних випадках і допомагає сформулювати acceptance criteria. Також оцінює обсяг тестування, щоб естімейт команди включав і його. Тут QA найефективніше запобігає дефектам — ще до написання коду.

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

Definition of Done — спільний для команди чек-лист, коли задача вважається повністю завершеною. Зазвичай включає: код пройшов review, написані й проходять unit- та автотести, виконано мануальне тестування за acceptance criteria. Також — немає відкритих критичних багів, оновлено документацію, зміни задеплоєні на тестове середовище. Acceptance criteria специфічні для конкретної story, а DoD — для всіх задач.

Cypress у Jenkins або GitLab CI

В основі — запуск npx cypress run у пайплайні з потрібними параметрами: браузер, конфіг, спеки, змінні середовища. Найзручніше використовувати офіційний Docker-образ cypress/included або cypress/browsers, де вже встановлені браузери й залежності. У GitLab CI це окрема job у .gitlab-ci.yml, у Jenkins — стейдж у Jenkinsfile.

Секрети — логіни, токени, URL середовищ — передаються через CI/CD variables або credentials Jenkins, а не зберігаються в репозиторії. Кешування node_modules і Cypress binary пришвидшує прогони. Паралелізація робиться кількома job, кожна з яких запускає свою частину спеків — вручну, через parallel: у GitLab, або через Cypress Cloud з параметрами --record --parallel.

Артефакти: скріншоти й відео з папок cypress/screenshots і cypress/videos зберігаються лише при падінні, щоб не займати місце. Для звітів використовують Mochawesome або Allure, а JUnit-репортер дає інтеграцію зі вкладкою тестів у GitLab чи Jenkins. Також налаштовують сповіщення в Slack чи Teams з результатом і посиланням на звіт.

Які тести на якому етапі пайплайна

Принцип — швидкий зворотний зв'язок: що ближче до розробника, то швидшими мають бути тести. На кожен коміт і merge request запускаються лінтер, unit-тести, API-тести й smoke-набір E2E, загалом кілька хвилин. Merge request не можна змерджити, якщо цей етап не пройшов, — це quality gate.

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

Перед релізом — повна регресія на staging, UAT і мануальне тестування нових фіч. Після деплою на продакшн — короткий smoke для перевірки, що основні флоу працюють. Нестабільні тести не повинні блокувати пайплайн: їх ізолюють у карантин і виправляють окремо.