Тестове завдання

Що таке тестове завдання і що саме воно перевіряє?

Тестове (test assignment, home task) — етап воронки найму, де компанію цікавить не обсяг твоїх знань, а манера роботи наодинці з задачею. Усна технічна секція міряє ерудицію під тиском розмови; тестове віддає рецензенту готовий продукт — видно, як ти розбираєш сиру постановку на частини, що вважаєш вартим уваги і як оформлюєш результат, коли ніхто не підказує. Для QA це майже дзеркало щоденної роботи: узяти недоописану фічу, вигадати перевірки, розставити пріоритети й здати артефакт, зрозумілий колезі. Тому й фільтр показовий — усне «я володію технікою тест-дизайну» легко проговорити, а тестове показує, чи справді ти нею користуєшся.

Які основні формати тестового трапляються для QA?

Попри різні формулювання, майже все зводиться до трьох типів, і розпізнати тип — перше, що варто зробити, бо він задає очікуваний артефакт. Перший — спроєктувати перевірки для фічі за описом, макетом чи демо; на виході набір тест-кейсів або чекліст, найтиповіший варіант для manual junior. Другий — знайти дефекти в навмисно зламаному білді й оформити їх багрепортами; тут дивляться і на спостережливість, і на якість оформлення. Третій — покрити публічний застосунок автотестами, з віддачею репозиторію, який рецензент клонує й запускає; найважчий за трудомісткістю формат для AQA. Іноді типи комбінують (спершу чекліст, потім автоматизація частини), а якщо формат із постановки неясний — це перше, що варто уточнити в рекрутера, а не домислювати.

На що дивиться рецензент, коли читає тестове?

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

Чому більша кількість кейсів чи знайдених багів не робить тестове сильнішим?

Бо рецензент читає не рядки, а мислення за ними, і купа рівноцінних кейсів це мислення радше ховає. Сорок перевірок, звалених без пріоритету, з однаковою вагою, не кажуть, що для тебе критичне, а що ти дописав «щоб було» — виходить розмите полотно. П'ять продуманих кейсів логіну з негативами й межами важать більше за тридцять варіацій одного happy-path, бо демонструють вибір і тест-дизайн. Те саме з багами: десять дрібних косметичних знахідок слабші за три добре оформлені дефекти з чіткими кроками, у яких видно розуміння severity. Обсяг сам собою — не аргумент; аргумент — що саме ти вирішив покрити першим і чому.

Що таке пріоритезація в тестовому і чому її називають найрідшим навиком junior?

Пріоритезація — це коли з порядку і акцентів твого артефакту зрозуміло, які перевірки ти пройшов би першими, якби мав лише годину. Спершу критичний шлях (critical path) і сценарії з найбільшим ризиком, потім усе другорядне — така послідовність сама говорить за твоє мислення. Junior найчастіше грішить рівним списком, де все важливе однаково, бо здається, що «розставити пріоритети» — це необов'язкова прикраса; насправді саме тут видно зрілість. Уміння сказати «ось ці десять — головні, решта — за наявності часу» цінніше за повний, але плаский перелік. Це прямий сигнал ризик-орієнтованого мислення, якого й чекають від тестувальника.

Навіщо на початку тестового явно виписувати припущення?

Тому що будь-яке тестове недоописане навмисно, і те, що ти робиш із цими прогалинами, — частина перевірки. Рядок на кшталт «припускаю, що email обов'язковий, валідується за RFC, ліміт 254 символи» показує аналітичне мислення краще, ніж мовчазний здогад, за яким рецензент не бачить, свідомий він чи випадковий. Явні припущення перетворюють невизначеність на прочитане рішення: видно, що ти помітив діру у вимогах і закрив її обґрунтовано, а не проігнорував. Це також страхує тебе на захисті — ти вже зафіксував, з якими вхідними працював, і претензія «а чому не врахував X» знімається посиланням на власний список. Дешевий за зусиллями хід, який відразу відрізняє кандидата, що думає, від того, що вгадує.

Що таке скоуп-блок і з чого він складається?

Скоуп-блок — короткий вступ, з якого починається сильний артефакт замість того, щоб одразу сипати кейсами. У ньому три частини: припущення (що ти вважаєш правдою за браку вимог), межа скоупу (що тестуєш, а що свідомо лишаєш поза, наприклад навантаження й безпеку) і питання, які поставив би аналітику в реальній роботі. Разом вони фіксують правила гри, які замовник не прописав, і показують, що ти не вигадуєш вимоги мовчки. Це та сама дисципліна, що й у гарячому релізі: якщо скоуп не зафіксували за тебе — зафіксуй його сам. Без цього блоку навіть добрі кейси читаються як «протестував що встиг», а з ним — як усвідомлений зріз.

Що таке таймбокс і чому написати «витратив N годин» — не слабкість?

Таймбокс (timebox) — свідомо поставлений собі ліміт часу (типово дві-чотири години), у який ти вкладаєш роботу й про який чесно звітуєш наприкінці. Це не зізнання в лінощах, а сигнал зрілості: рамка показує, що ти здатен видати промовистий зріз у заданих межах, а не розтікаєшся нескінченним списком. Глибокий зріз одного критичного шляху майже завжди виграє в поверхневого «все потроху», бо перше показує тест-дизайн, а друге — лише витривалість. До того ж таймбокс рятує від головної пастки формату: задачу «протестуйте форму логіну» можна закопати на два дні через локалі, таймзони й конкурентні сесії, а можна дати сильний зріз за пів дня. Рамка тут — інструмент фокусу, а не виправдання.

Чому «протестувати все підряд» — програшна стратегія?

Бо вона виглядає як ретельність, а дає розмите полотно без фокусу. Тестове завжди можна розкрити нескінченно — додати локалі, unicode, доступність, конкурентні сесії, — і той, хто женеться за повнотою, або вигорає й здає із запізненням, або віддає широкий, але неглибокий перелік, де кожен кейс — ще одна варіація happy-path. Рецензент у такому полотні не бачить, що для тебе критичне, бо все подано з рівною вагою. Замість ширини виграє глибина по одному-двох напрямках: краще ретельно покрити критичний шлях із негативами й межами, ніж торкнутися всього по верхах. «Все підряд» — це не покриття, а відмова від пріоритезації, і читається саме так.

Для автотест-проєкту — чому найперший фільтр не якість коду, а те, чи він запускається?

Тому що в рецензента обмаль часу: репозиторій, який після клонування не стартує, просить ручного налаштування бази або валиться на першій же команді, він просто закриє — до читання тестів справа не дійде. Хоч якою елегантною була б архітектура, оцінюють лише те, що вдалося запустити. Тому послідовність рецензування жорстка: спершу питання «чи є README з командою запуску», потім «чи тести взагалі проходять», і лише після цього — читання структури й рішень. Провал на першому кроці обнуляє все решту, хоч би яким гарним був тест-дизайн усередині. Звідси практичний висновок: перед відправкою клонуй проєкт у чисту теку й пройди сценарій рецензента сам.

Що обов'язково має бути в README тестового автопроєкту?

README — це вхідні двері, і воно мусить за пів хвилини відповісти на чотири питання: що це, як установити, як запустити, що покрито. Мінімум — назва й стек, вимоги до оточення (наприклад, версія Node.js), команда запуску в один-два рядки і список покритого функціоналу. Сильний README додає ще дві секції — «рішення й компроміси» (чому дані готуєш через API, чому оплату лишив поза скоупом) і «що додав би з більшим часом». Ці розділи перетворюють твої свідомі рішення з невидимих на прочитані: рецензент бачить інженерну логіку, а не здогадується про неї. Ідеал запуску — npm ci && npm test без кроків «спершу підніми Docker, потім заповни .env руками»; якщо змінні потрібні — поклади .env.example зі значеннями за замовчуванням.

Що навіть у трьох тестах показує рецензенту твою інженерну культуру?

Дрібниці, які видно з першого файлу. Локатори за пріоритетом — getByRole, getByLabel, data-testid замість крихких XPath, прив'язаних до розмітки. Сторінки, винесені в page object, а не скопійовані селектори в кожному тесті. Підготовка стану через API замість того, щоб клікати той самий флоу мишею перед кожною перевіркою. Жодних waitForTimeout із магічним числом — тільки web-first очікування, які самі дочікуються потрібного стану. Один охайний тест, зроблений так, каже про тебе більше, ніж двадцять скопійованих: рецензент екстраполює цю акуратність на те, як ти писатимеш увесь фреймворк у роботі.

Чому overengineering у тестовому — червоний прапорець, а не плюс?

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

Навіщо до артефакту додавати супровідний текст, якщо кейси й так є?

Бо артефакт — лише половина, а друга половина — як ти його подаєш. Супровід (для автопроєкту це секції README, для чекліста — вступний абзац) фіксує твої припущення, пояснює, що і чому ти пріоритизував, називає відомі прогалини й план «якби мав більше часу». Без нього свідомі компроміси залишаються невидимими, і мовчазна відсутність, скажімо, тесту на оплату читається як недогляд. З ним та сама відсутність звучить інженерним рішенням: «оплату виніс поза скоуп, бо вона залежить від зовнішнього провайдера й потребує тестових карток». Різниця величезна — той самий обсяг роботи сприймається або як прогалина, або як усвідомлений вибір, і супровід вирішує, як саме.

У тестового буває продовження-дзвінок. Як на ньому обґрунтовувати свої рішення?

Треба бути готовим захистити кожен вибір і робити це через відкрите визнання меж, а не через удавану повноту. Сильний хід — самому назвати, чого не покрив і чому: «happy-path оформлення я свідомо не автоматизував, бо він найдорожчий у підтримці й найкрихкіший — покрив би його вручну». Таке звучить як інженерне рішення, тоді як спроба вдавати, що ти встиг усе, розколупується інтерв'юером за одне уточнювальне питання. Готуй обґрунтування до чотирьох речей: пріоритезації («чому це, а не те»), прогалин («що додав би з часом»), роботи зі скоупом («скільки витратив і чому зупинився») і — для AQA — власного коду («чому така структура, чому тут мок»). Чесне «ось межа й ось причина» завжди міцніше за фасад, який не витримує першого ж тику.

Як відрізнити чесне тестове від замаскованої безкоштовної праці?

За чотирма ознаками, які працюють у зв'язці. Чесне завдання має обмежений обсяг (реально дві-чотири години), синтетичну або публічну ціль (демо-застосунок, тренувальне API), чіткий бриф і компанію, готову дати фідбек. Сумнівне — навпаки: тебе просять тестувати їхній реальний продакшн-продукт із розмитим «пошукайте в нас баги й побачимо», скоуп нічим не обмежений, від тебе хочуть повноцінний автоматизаційний каркас, який потім заберуть, або кілька раундів безоплатної роботи поспіль. Junior особливо вразливий, бо вкладає п'ятнадцять-двадцять годин «щоб точно взяли», а у відповідь нерідко отримує тишу. Головний маркер — межа: чесна компанія рамку дає сама, експлуататор навмисно лишає її відкритою.

Що робити, якщо тестове схоже на замасковану безкоштовну працю?

Діяти без конфронтації, але й без наївності — і головний інструмент тут таймбокс. Постав собі стелю годин незалежно від амбіцій завдання й віддай сфокусований зріз із поміткою «ось приблизно N годин роботи, решту радо обговорю на дзвінку»: так ти й показуєш підхід, і не працюєш задарма нескінченно. Другий крок — заздалегідь спитати рекрутера про очікуваний обсяг і час; здорова компанія сприйме таке питання спокійно, а якщо у відповідь прилетіло роздратування — це вже багато каже про її внутрішні процеси. Реальний продукт із відкритим скоупом — привід уточнити очікування, а не мовчки вкладати вихідні. Систематична експлуатація тестовими — це вже симптом ширших проблем найму, і на такий сигнал варто зважати нарівні з іншими червоними прапорцями.

Чому «я свідомо не покрив happy-path оплати» звучить сильніше за удавану повноту?

Бо це показує, що ти керуєш скоупом, а не просто робиш усе, до чого дотягнувся. За фразою стоїть ланцюжок рішень: ти оцінив вартість підтримки цього сценарію, його крихкість і залежність від зовнішнього провайдера — і зробив обґрунтований вибір лишити його поза автоматизацією, покривши вручну. Це мова інженера, який розуміє компроміси, а не виконавця, що заповнює прогалину аби була. Удавана ж повнота крихка: варто інтерв'юеру спитати «а що буде, якщо провайдер віддасть таймаут», і фасад «я все покрив» розсипається, бо покриття було номінальним. Відкрито названа й обґрунтована межа виграє, тому що її не можна розколупати — вона вже врахована.

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

Кейс 1. Скоуп-шапка для розмитої постановки

Постановка від рекрутера — один рядок: «Протестуйте форму логіну на нашому демо-стенді, надішліть результат до понеділка». Спокуса — одразу почати писати кейси. Сильний хід — почати з блоку, який фіксує рамку, бо саме її замовник свідомо не задав. Такий блок стає першим екраном артефакта (окремий аркуш у Google Sheets чи перший абзац документа):

ПРИПУЩЕННЯ
- email обов'язковий, валідується за форматом, ліміт 254 символи
- пароль: мінімум 8 символів, є показ/приховування
- після 5 невдалих спроб — тимчасове блокування (точний ліміт уточнити)
- мова інтерфейсу одна (en), локалі й таймзони поза скоупом

У СКОУПІ
- позитивний вхід валідними даними
- негативні: порожні поля, невалідний email, невірний пароль
- крайові: 254 символи в email, пробіли по краях, регістр email
- поведінка після кількох невдалих спроб

ПОЗА СКОУПОМ (свідомо)
- навантаження й безпека (SQL-інʼєкції, brute force на проді)
- крос-браузерність — лише Chromium у цьому зрізі
- відновлення пароля — окремий флоу, окреме завдання

ПИТАННЯ ДО АНАЛІТИКА
- який точний ліміт спроб і час блокування?
- email case-sensitive чи ні?
- чи є вимога до складності пароля понад довжину?

ТАЙМБОКС: 2.5 години. Далі — пріоритетний список того, що покрив би наступним.

Що тут працює і чому:

• Припущення знімають претензії заздалегідь. Рецензент бачить, що діри у вимогах ти помітив і закрив обґрунтовано, а не протестував навмання. На захисті рядок «я припустив ліміт 254 за RFC» звучить як аналітика, а мовчазний здогад — як вгадування.
• Явна межа «поза скоупом» читається як рішення, а не як прогалина. «Безпеку виніс поза зріз» — інженерний вибір; та сама відсутність без згадки — недогляд.
• Питання до аналітика показують реальний робочий рефлекс. У продукті ти б уточнив це в постановника; тут ти демонструєш, що не вигадуєш вимоги мовчки.
• Таймбокс перетворює обмеження на силу. «2.5 години, далі — пріоритетний список» сильніше за нескінченне полотно: видно, що ти вмієш дати сфокусований результат у рамках.

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

Кейс 2. AQA-проєкт, який стартує однією командою

Найперший фільтр автотест-тестового — чи воно взагалі запускається в рецензента з чистої теки. Тому проєкт починається не з тестів, а з README й скрипта запуску. Мінімальний package.json, де npm test веде прямо в Playwright, без «спершу зроби ще щось»:

{
  "name": "qa-assignment",
  "scripts": {
    "test": "playwright test",
    "report": "playwright show-report"
  },
  "devDependencies": {
    "@playwright/test": "^1.48.0"
  }
}

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

import { test, expect } from '@playwright/test';

test('заблокований користувач бачить помилку входу', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Username').fill('blocked_user');
  await page.getByLabel('Password').fill('ValidPass123');
  await page.getByRole('button', { name: 'Login' }).click();

  // web-first очікування само дочікується появи алерту, без waitForTimeout
  await expect(page.getByRole('alert')).toContainText(/locked out/i);
});

Що дивитися і чому:

• npm ci && npm test — і все. Якщо рецензент мусить піднімати Docker чи руками заповнювати .env, шанс, що він дійде до тестів, падає. Потрібні змінні — клади .env.example зі значеннями за замовчуванням, не змушуй гадати.
• getByRole / getByLabel замість XPath. Прив'язка до ролі й підпису переживає зміну розмітки; крихкий //div[3]/span[2] ламається від першого рефакторингу верстки.
• Немає waitForTimeout з магічним числом. expect(...).toContainText(...) сам чекає на потрібний стан; фіксована пауза або флакне на повільному CI, або марно гальмує на швидкому.
• Три робочі тести б'ють недописаний «фреймворк» на 500 рядків. Абстракції під три сценарії — це overengineering і червоний прапорець: рецензент читає його як невміння відрізнити потрібне від передчасного, а не як силу.

README при цьому не формальність, а вхідні двері: назва й стек, вимоги (Node.js 22+), команда запуску, список покритого, а нижче — секції «рішення й компроміси» та «що додав би з часом». Саме вони перетворюють мовчазну відсутність тесту на оплату з недогляду на прочитане рішення.

Кейс 3. Розпізнати замасковану безкоштовну працю

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

Практичний сценарій. Рекрутер надсилає доступ до їхнього робочого кабінету зі словами «протестуйте, що знайдете, зробіть повну тест-стратегію продукту, обсяг на ваш розсуд». Три праві стовпці таблиці засвічуються одночасно — реальний продукт, відкритий скоуп, стратегія «на виніс». Це не привід грюкнути дверима, але привід не вкладати п'ятнадцять годин наосліп.

Що робити:

• Таймбокс рятує в будь-якому разі. Постав собі стелю (наприклад, три години), віддай сфокусований зріз одного критичного флоу з поміткою «ось приблизно N годин, решту радо обговорю на дзвінку». Так ти показуєш підхід, не працюючи задарма без меж.
• Уточни очікування заздалегідь. Питання рекрутеру про очікуваний обсяг і час — нормальне; адекватна компанія відповість спокійно, а роздратування у відповідь саме по собі є відповіддю про внутрішні процеси.
• Свідомо звужуй ціль. Замість «повної стратегії продукту» віддай стратегію одного модуля з явним «це зразок мого підходу на прикладі X» — і артефакт сильний, і межа очевидна.

Формати й розпізнавання завдання

• Розрізняю три формати тестового: чекліст/тест-кейси для фічі, пошук і оформлення багів, автотест-проєкт для AQA — і знаю, який артефакт від мене чекають у кожному.
• Розумію, що формат диктує очікуваний результат: постановка «спроєктуй перевірки» і «покрий автотестами» вимагають зовсім різного.
• Знаю, що при неясному форматі перше рішення — уточнити в рекрутера, а не домислювати мовчки.
• Можу пояснити, чому багрепорт оцінюють не за кількістю знахідок, а за якістю оформлення: кроки відтворення, фактичний і очікуваний результат, severity, докази.

Що насправді оцінюють

• Знаю три критерії рецензента — покриття (важить розподіл позитив/негатив/граничні, а не довжина списку), пріоритезація, оформлення; кількість кейсів сама по собі не важить.
• Можу пояснити, чому пріоритезація — найрідший навик junior: порядок кейсів має показувати критичний шлях і ризики, а не рівну купу.
• Розумію, чому назва кейсу має описувати перевірку, а не дію («клік туди-сюди»), і чому єдиний формат читається як сигнал охайності.
• Знаю, що явно виписані припущення відрізняють аналітика від того, хто мовчки вгадав вимоги.

Скоуп і час

• Розумію, що тестове недоописане навмисно, і робота з невизначеністю — частина перевірки.
• Можу зібрати скоуп-блок: припущення, у скоупі / поза скоупом, питання до аналітика — і зафіксувати рамку сам, якщо її не задали.
• Знаю принцип таймбоксу: поставити стелю годин (типово 2–4) і чесно вказати витрачений час як ознаку зрілості, а не слабкості.
• Можу пояснити, чому глибокий зріз одного критичного шляху б'є поверхневе «все потроху», а «тестую все підряд» — це відмова від пріоритезації, а не ретельність.

Тестове для AQA

• Знаю, що перший фільтр автопроєкту — чи він узагалі запускається (а не якість коду), і чому маленьке й робоче б'є велике й зламане, а overengineering каркасу — червоний прапорець.
• Можу написати мінімальний, але повний README: що це, як установити, як запустити, що покрито, плюс компроміси й «якби більше часу».
• Розумію ідеал запуску npm ci && npm test без ручного підняття Docker чи заповнення .env руками; змінні — через .env.example.
• Знаю ознаки інженерної культури в коді: локатори за пріоритетом (getByRole, getByLabel, data-testid), page object, підготовка стану через API, web-first очікування замість waitForTimeout.

Подача, захист і межі

• Розумію, що артефакт — лише половина: супровід (секції README чи вступний абзац) робить компроміси прочитаними, а на захисті кожен вибір обґрунтовую через відкрите визнання меж, а не удавану повноту.
• Знаю типові питання продовження: чому це, а не те; що додав би з часом; скільки витратив і чому зупинився; які припущення зробив.
• Можу відрізнити чесне тестове (обмежений обсяг, синтетична ціль, чіткий бриф, фідбек) від замаскованої безкоштовної праці (реальний продукт, відкритий скоуп, повний фреймворк, кілька безоплатних раундів).
• Знаю, що робити із сумнівним завданням: таймбокс і помітка «N годин», плюс уточнення обсягу в рекрутера заздалегідь.