Технічна співбесіда AQA

Чим технічна співбесіда AQA відрізняється від технічного скринінгу мануального QA?

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

Що таке «ширина» і «глибина» в структурі AQA-співбесіди й навіщо їх розрізняти?

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

Хто зазвичай веде технічну секцію AQA і як це впливає на розмову?

Секцію найчастіше проводить lead AQA, SDET або сеньйор-автоматизатор, іноді разом із розробником, який дивиться на твій код очима майбутнього рев'юера. Формат — розмова на 45–90 хвилин, часто з лайвкодингом або винесеним тестовим завданням. Знання, хто навпроти, змінює акценти: розробник у складі панелі почне питати про якість самого коду, читабельність, дизайн, а не лише про тестову логіку. Практичний висновок — не зводь підготовку до інструмента, бо частину часу оцінюватимуть тебе як інженера, а не лише як «того, хто пише тести».

«Розкажи про свій фреймворк» — чому це головне питання секції та як до нього готуватися?

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

Що казати, якщо архітектуру фреймворку проєктував не ти?

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

Чому завчене визначення провалюється на AQA-співбесіді?

Бо визначення тут — лише вхід у воронку поглиблення: що це → навіщо це, яку проблему розвʼязує → приклад з твого проєкту → коли це зайве або шкодить. Людина, яка прочитала означення, але не працювала з поняттям, проходить перший крок і валиться на другому-третьому: не може навести приклад із практики й не знає меж застосування. Показовий приклад — Page Object: означення відскакує від зубів, але кандидат губиться на тому, чим небезпечний god object і в якому шарі мають жити перевірки — у page object чи в тесті. Висновок для підготовки: вчи не абзаци, а трійки «навіщо → приклад із проєкту → межа».

Як підготувати тему так, щоб вона витримала воронку поглиблення?

До кожного поняття з мапи готуй не визначення, а три опори: навіщо воно (яку біль знімає), приклад із власного проєкту й межу — коли поняття зайве або починає шкодити. Визначення дає лише перший крок воронки, а грейд вирішується на кроках про приклад і про межу. Якщо на якусь тему в тебе немає прикладу з практики, це чесна діра, і сказати «читав, але руками не робив» сильніше, ніж імітувати досвід і замовкнути на уточненні. Відповідь «не знаю, але міркував би так…» звучить переконливіше за гладкий завчений абзац без опори на досвід.

«У вас тест іноді падає, іноді ні. Твої дії?» — як побудувати відповідь про флак?

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

Чому page.waitForTimeout або sleep — слабка відповідь на питання про синхронізацію?

Фіксована пауза не звʼязана з реальною подією, на яку ти чекаєш, тож вона одночасно і ненадійна, і марнотратна. Замало почекав — тест почервоніє на повільному прогоні; забагато — сюїта гальмує на кожному зеленому запуску. Правильний підхід — чекати на конкретну умову, а не на абстрактні секунди: web-first assertion у Playwright сама опитує стан, доки він не збіжиться, або поки не вийде таймаут. Тому відповідь «поставив би sleep побільше» одразу сигналить про поверхове розуміння синхронізації, а «замінив би фіксовану паузу на очікування конкретної умови» — про зріле.

Коли ретраї легітимні, а коли вони перетворюють набір на брехню?

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

Що на практиці означає теза «фейл тесту не дорівнює багу продукту»?

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

«Чому Playwright, а не Selenium чи Cypress?» — що насправді перевіряє це питання?

Майже ніколи — не те, який інструмент обʼєктивно «кращий». Інтервʼюер дивиться, чи розумієш ти архітектурні моделі за інструментами, чи просто переказав порівняльну табличку з блогу. Слабка відповідь перелічує фічі: «Playwright швидший і має автоочікування». Сильна називає компроміс і привʼязує його до контексту: дешева ізоляція через контексти й автоочікування з коробки зменшують флак, зате Selenium виграє зрілою екосистемою й підтримкою рідкісних браузерів. І тут теж цінується чесність про власну роль: якщо інструмент обрали до тебе — так і скажи, додавши, як ти розумієш причину вибору й де відчув його межі на практиці.

Чим принципово різняться архітектурні моделі Selenium, Playwright і Cypress?

Це три різні способи керувати браузером, і кожен має наслідки. Selenium працює через стандартний протокол W3C WebDriver — універсальний і зрілий, але зовнішній щодо браузера. Playwright тримає постійне зʼєднання по власному протоколу драйвера: для Chromium — на базі Chrome DevTools Protocol (CDP), для Firefox і WebKit — через патчені збірки, що дає дешеву ізоляцію контекстами й автоочікування. Cypress виконує код тесту всередині самого браузера, що зручно фронтенд-командам, але його модель ускладнює багатовкладкові й cross-origin сценарії. Наслідки моделей стосуються ізоляції, кросбраузерності, роботи з кількома вкладками й автоочікування — саме про ці компроміси й питають, а не про швидкість у вакуумі.

«Що б ти автоматизував на новому проєкті першим?» — як відповісти по-сеньйорному?

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

«Хто має писати автотести — AQA чи розробники?» — як відповісти сильно?

Тут немає єдиної правильної відповіді, і сама спроба видати одну — слабкий хід. Сильний кандидат говорить про ownership: автоматизація — командний спорт, а не колодязь однієї ролі. Ключова теза, яку варто озвучити, — один флакі-тест підриває довіру до всього gate, тому спільне володіння набором важливіше за те, чиї руки написали конкретний тест. Добре сюди вплести shift-left і data-testid як контракт із розробкою: коли тестопридатність обговорюють до написання фічі, питання «хто пише» стає менш гострим. Відповідь має показати, що ти бачиш процес і довіру до gate, а не ділиш зони відповідальності по посадах.

Що таке shift-left і чому data-testid називають контрактом із розробкою?

Shift-left — це зсув уваги до якості ліворуч по потоку розробки: тестопридатність фічі обговорюють до того, як її написали, а не після. data-testid тут — атрибут-контракт: розробка домовляється лишати в розмітці стабільні гачки для локаторів, і тоді тести не ламаються від кожного косметичного рефакторингу верстки. Це і є прикладна форма співпраці: замість того щоб AQA полював за крихкими селекторами постфактум, команда закладає зачіпки заздалегідь. Практичний наслідок — менше флаку від зміни DOM і менше конфліктів «ви знову переверстали й поламали нам тести».

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

Сеньйор мислить вартістю володіння набором, а не кількістю тестів. Показові метрики — час прогону (чи не став gate занадто повільним, щоб його поважали), стабільність набору (частка флакі-падінь) і escape rate — скільки дефектів просочилося в прод повз автоматизацію. Разом вони відповідають на головне питання: чи набір усе ще окуповується, чи його підтримка вже коштує дорожче за користь. Звідси й зріле рішення — коли зупинити автоматизацію певної ділянки, бо вона перестала окупатися. Кількість тестів сама по собі нічого не каже: тисяча крихких e2e гірша за сотню надійних.

Чому «залежить від контексту» буває і сильною, і слабкою відповіддю водночас?

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

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

Кейс 1. «Розкажи про фреймворк»: розклад по шарах із «чому» й альтернативою

Питання звучить м'яко, але це вхід у половину секції. Слабко — перелічити інструменти («Playwright, TypeScript, Page Object, GitHub Actions, Allure»). Сильно — намалювати шари й до кожного мати причину рішення та відкинуту альтернативу. Ось та сама розповідь, розкладена в таблицю, якою її і варто тримати в голові перед дошкою:

Що дивиться інтервʼюер і чому:

• Кожен рядок має колонку «чому». Різниця між джуном і мідлом проходить тут: джун опише, що зроблено, мідл — чому й що було замість. Колонка альтернатив — це і є те, що інтервʼюер витягуватиме питанням «а чому не інакше».
• Не привласнюй чужих рішень. Якщо шар ізоляції проєктував тимлід, чесна формула: «цю частину закладав не я, ось як я розумію її логіку, а особисто я писав тести поверх неї». Це поважають більше за впевнену розповідь, що валиться на другому уточненні.
• Готуй розповідь так, щоб кожен рядок витримував свердління. Інтервʼюер зупиниться на тому шарі, де ти впевнений, і копатиме вглиб — саме там вирішується грейд, тому веди розмову туди, де тобі є що захищати.

Кейс 2. Воронка поглиблення: як тоне завчене визначення

Визначення тут — лише перший із чотирьох кроків: що це → навіщо → приклад із проєкту → коли шкодить. Ось та сама тема (Page Object) у двох кандидатів. Репліки реконструйовані, але діалог типовий.

Кандидат A (завчене визначення):

— Що таке Page Object? — Патерн, де кожна сторінка застосунку — окремий клас із методами взаємодії та локаторами всередині. — Навіщо він? — Щоб не дублювати код і легше підтримувати тести. — Наведи приклад зі свого проєкту, де він реально врятував. — Ну… скрізь у нас Page Object, на кожну сторінку клас… — А коли Page Object зайвий або шкодить? — (пауза) Не знаю, ми завжди його використовуємо.

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

Кандидат B (реальне розуміння):

— А коли Page Object зайвий або шкодить? — Коли екран простий і клас перетворюється на тонку обгортку над одним локатором — це зайва абстракція, читати важче, ніж прямий локатор у тесті. І ще одна пастка — god object: у нас один клас розрісся до сотні методів, ми його порізали за смисловими блоками. Перевірки я тримаю в тесті, а не в page object: об'єкт відповідає за «як натиснути», а тест — за «що має статися».

Що дивиться інтервʼюер і чому:

• Визначення — лише перший крок воронки. Грейд вирішується на «приклад із проєкту» й «межа застосування», а не на гладкості формулювання.
• Чесна діра сильніша за імітацію. Якби кандидат A сказав «Page Object я використовував, але про його межі не думав» — це чесніше й безпечніше, ніж пауза після спроби вдати досвід.
• Готуй трійки, а не абзаци. До кожної теми з мапи — «навіщо → приклад із проєкту → межа», інакше друге-третє уточнення топить.

Кейс 3. «Тест іноді падає, іноді ні»: каркас замість «додати sleep»

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

Останній рядок — головна дисципліна: фейл тесту не дорівнює багу продукту, спершу зʼясуй, що впало. Далі — показова деталь, за якою одразу видно рівень: фікс жорсткого очікування.

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

test('поява алерта: очікування умови, а не фіксована пауза', async ({ page }) => {
  await page.goto('https://app.example.com/checkout');
  await page.getByRole('button', { name: 'Оплатити' }).click();

  // Антипатерн: фіксована пауза — або флак на повільному прогоні, або марна затримка
  // await page.waitForTimeout(3000);
  // await expect(page.getByRole('alert')).toBeVisible();

  // Правильно: web-first assertion сама опитує стан, доки умова не збіжиться або не вийде таймаут
  await expect(page.getByRole('alert')).toBeVisible();
});

Про ретраї — окремою тезою, бо саме тут видно зрілість:

// Легітимно: тег виділяє відомий флак — ретраї вмикаються точково (окремий прогін/проєкт за тегом), зі статистикою повторів
test('нестабільний сторонній віджет', { tag: '@flaky' }, async ({ page }) => {
  // ...
});

// Небезпечно: глобальні retries маскують і реальні баги продукту, що проявляються не щоразу
// retries: 2  // у конфізі «на весь набір» — набір тихо перетворюється на брехню

Що дивиться інтервʼюер і чому:

• Каркас, а не рецепт. «Додати очікування» — лише один пункт з першого рядка таблиці; сильна відповідь показує всю таксономію й порядок діагностики.
• Ретрай — остання лінія з моніторингом, не заміна діагностики. Легітимний ретрай гасить відомий зовнішній шум; ретрай, яким глушать незрозумілу нестабільність, ховає баги й убиває довіру до gate.
• «Що впало?» перед «де баг?». Дуже часто винен не застосунок: протух токен, фікстура не створила запис, тести побилися за спільний стан — і це знахідка про тест, а не про продукт.

Формат і тактика секції

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

Розмова про фреймворк

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

Пастка завчених визначень

• Розумію воронку поглиблення: що це → навіщо → приклад із проєкту → коли зайве чи шкодить, і знаю, що завчене валиться на другому-третьому кроці.
• До кожної теми готую трійку «навіщо → приклад із проєкту → межа застосування», а не абзац визначення.
• Можу пояснити на прикладі Page Object, де мають жити перевірки й чому god object — це погано.

Флакі-тести

• Маю каркас відповіді про флак: таксономія причин (синхронізація, дані, порядок і залежності, оточення/CI, реальний баг продукту) → діагностика → ретраї, а не список рецептів.
• Можу пояснити, чому фіксована пауза (waitForTimeout/sleep) — антипатерн, і показати очікування конкретної умови замість неї.
• Розрізняю легітимний ретрай (свідоме гасіння відомого шуму з моніторингом) і ретрай-маскування, що перетворює набір на брехню.
• Тримаю як окрему тезу: фейл тесту не дорівнює багу продукту — спершу зʼясовую, що впало, потім заводжу дефект.

Вибір інструмента

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

Стратегія і співпраця (сеньйорний рівень)

• Можу пояснити, що автоматизувати першим (критичний шлях, смоук, найдорожчі баги), чому не варто гнатися за «100% автоматизації» й чим небезпечний «ріжок морозива» — перевернута піраміда з крихких e2e.
• Знаю роль shift-left і data-testid як контракту з розробкою, розумію ownership набору й чому один флакі-тест підриває довіру до всього gate.
• Мислю метриками володіння набором: час прогону, стабільність, escape rate — і знаю, коли автоматизація перестає окуповуватися.
• Умію сказати «залежить від контексту» й одразу назвати, від чого саме (зрілість команди, ризик фічі, частота релізів).