QA Interview Hub · База знань · Тести
Manual QA
Web і клієнт-сервер
HTTP, браузер, DevTools
Що таке клієнт-серверна архітектура?
Клієнт (браузер, мобільний застосунок) відправляє запити, сервер обробляє їх і повертає відповіді. Сервер працює з базою даних та іншими сервісами.
Для QA це означає: баг може бути на клієнті (відображення, валідація), на сервері (логіка, дані) або на стику (неправильний запит, неочікувана відповідь). DevTools допомагає швидко локалізувати, де саме.
Браузер ──HTTP-запит──► Сервер (API) ──► База даних
◄─HTTP-відповідь─ ◄──
На співбесіді: Клієнт відправляє запит, сервер обробляє його, працює з базою і повертає відповідь. Коли я знаходжу баг, першим ділом визначаю, де він: якщо запит правильний, а відповідь неправильна — це бекенд; якщо відповідь правильна, а показано неправильно — фронтенд.
Які основні HTTP-методи і статус-коди?
Методи: GET — отримати, POST — створити, PUT — замінити повністю, PATCH — змінити частково, DELETE — видалити.
| Група | Приклади |
|---|
| 2xx успіх | 200 OK, 201 Created, 204 No Content |
| 3xx перенаправлення | 301, 302, 304 Not Modified |
| 4xx помилка клієнта | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422, 429 Too Many Requests |
| 5xx помилка сервера | 500, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
Часте питання: 401 — не автентифікований (хто ти?), 403 — автентифікований, але немає прав.
На співбесіді: GET отримує, POST створює, PUT замінює, PATCH змінює частково, DELETE видаляє. Коди: двохсоті — успіх, трьохсоті — перенаправлення, чотирьохсоті — помилка клієнта, п'ятисоті — сервера. Важлива різниця: чотириста один означає, що система не знає, хто ти, а чотириста три — знає, але не дає прав.
Чим відрізняються cookies, localStorage і sessionStorage?
| Cookies | localStorage | sessionStorage |
|---|
| Відправляються на сервер | Так, з кожним запитом | Ні | Ні |
| Термін життя | До expires або кінця сесії | Поки не видалять | Поки відкрита вкладка |
| Обсяг | ~4 КБ | ~5–10 МБ | ~5 МБ |
| Видимість між вкладками | Так | Так | Ні |
Для безпеки cookie з токеном має бути HttpOnly (недоступна з JS), Secure (лише HTTPS) і з SameSite.
На співбесіді: Cookies відправляються на сервер з кожним запитом і обмежені кількома кілобайтами. LocalStorage живе в браузері, поки його не очистять, а sessionStorage — лише поки відкрита вкладка. Для безпеки я перевіряю, що сесійна cookie має прапорці HttpOnly, Secure і SameSite.
Як ти використовуєш DevTools у тестуванні?
- Network — запити й відповіді, статуси, тривалість, payload; HAR-файл для баг-репорту.
- Console — JS-помилки й попередження.
- Elements — DOM, стилі, перевірка, що поле справді disabled, а не лише сіре.
- Application — cookies, localStorage, sessionStorage.
- Device toolbar — адаптивність і мобільні розміри.
- Network throttling — повільна мережа і офлайн.
На співбесіді: У DevTools я дивлюся вкладку Network — запити, статуси й тіла відповідей, і зберігаю HAR для баг-репорту. Console — на JS-помилки, Application — на cookies і сховища, device toolbar — на адаптивність, а throttling — щоб перевірити поведінку на повільній мережі.
Як підходити до кросбраузерного й адаптивного тестування?
Спершу визначити матрицю за аналітикою: які браузери, ОС і пристрої реально використовують клієнти. Потім пріоритизувати: найпопулярніші — повне тестування, решта — smoke критичних сценаріїв.
Перевіряти: верстку на брейкпойнтах, поведінку елементів форм, дати й числові формати, віртуальну клавіатуру на мобільних, орієнтацію екрана. Інструменти: емуляція в DevTools, реальні пристрої, хмарні ферми на кшталт BrowserStack.
На співбесіді: Я будую матрицю браузерів і пристроїв на основі аналітики, а не всього підряд. Найпопулярніші конфігурації тестую повністю, решту — smoke. Перевіряю верстку на брейкпойнтах, форми, формати дат і чисел, і обов'язково частину — на реальних пристроях, бо емуляція не все показує.
Що відбувається, коли вводиш URL
Спершу браузер розбирає URL і шукає IP-адресу домену через DNS: кеш браузера, кеш ОС, резолвер провайдера, а далі root, TLD і authoritative сервери. Потім встановлюється TCP-з'єднання через three-way handshake: SYN, SYN-ACK, ACK. Для HTTPS далі йде TLS handshake: сервер надсилає сертифікат, браузер його перевіряє, і сторони узгоджують ключі шифрування.
Потім браузер надсилає HTTP-запит з методом, заголовками й cookies. Запит може пройти через CDN, load balancer і reverse proxy, перш ніж потрапить на сервер застосунку. Сервер обробляє запит, звертається до БД чи інших сервісів і повертає відповідь зі статус-кодом, заголовками й HTML.
Браузер парсить HTML і будує DOM, паралельно завантажує CSS, JS, зображення та будує CSSOM. Далі йдуть layout, paint і composite — сторінка відображається. JavaScript виконується й може робити додаткові API-запити та змінювати DOM.
Фронтенд чи бекенд баг через DevTools
Головний інструмент — вкладка Network: знаходжу запит, пов'язаний з дією, і дивлюсь запит і відповідь. Якщо фронтенд відправив неправильні дані — невірні поля, формат, відсутній параметр — це баг фронтенду. Якщо запит правильний, а бекенд повернув помилку або неправильні дані — баг бекенду.
Якщо бекенд повернув коректні дані, а UI показує щось інше, баг на фронтенді: у відображенні, обробці чи стані. Якщо запит взагалі не відправився, дивлюсь вкладку Console на JS-помилки. Також перевіряю статус-коди: 5xx зазвичай вказує на бекенд, а 4xx потребує аналізу, хто з них неправий, за контрактом API.
Додатково: вкладка Application для cookies, localStorage і токенів, Elements для DOM і стилів, Performance для швидкодії. Можна повторити запит через Copy as cURL у Postman, щоб ізолювати бекенд від UI. У баг-репорт прикладаю запит, відповідь і HAR-файл.
Cookies vs localStorage vs sessionStorage
Cookies — невеликі дані до 4 КБ, які браузер автоматично надсилає з кожним запитом на відповідний домен. Їх може встановлювати і сервер через заголовок Set-Cookie, і JS. Мають термін дії та атрибути безпеки: HttpOnly (недоступні для JS, захист від XSS), Secure (лише HTTPS), SameSite (захист від CSRF).
localStorage зберігає близько 5–10 МБ даних, не надсилає їх на сервер автоматично і зберігає без терміну дії, доки їх не видалять. sessionStorage має схожий обсяг, але живе лише в межах однієї вкладки й очищається при її закритті. Обидва доступні лише через JavaScript і прив'язані до origin.
Для тестування: перевіряю, що чутливі дані, як токени сесії, зберігаються в HttpOnly cookies, а не в localStorage. Також перевіряю поведінку після логауту, закриття вкладки, в режимі інкогніто й у новій вкладці. У DevTools це видно на вкладці Application.
DOM, верстка й адаптивність
DOM (Document Object Model) — деревоподібне представлення HTML-документа в пам'яті браузера, яким JavaScript може керувати. Кожен тег стає вузлом, і зміна DOM змінює те, що бачить користувач. Саме з DOM працюють локатори в автотестах.
Верстку перевіряю на відповідність макету в Figma: відступи, шрифти, кольори, розміри, вирівнювання. Типові проблеми: текст, що вилазить за межі блоку, перекриття елементів, довгі слова, що ламають layout, відсутні стани hover, focus і disabled. Для аналізу використовую вкладку Elements у DevTools і розширення на кшталт PerfectPixel.
Адаптивність тестую через Device Mode у DevTools на різних брейкпойнтах, наприклад 320, 768, 1024 і 1440 пікселів, та на реальних пристроях. Також перевіряю орієнтацію екрана, масштабування, крос-браузерність і роботу з клавіатури. Для візуальної регресії можна використати скріншот-тести — Percy або Applitools.
Основи JavaScript
== порівнює з приведенням типів, тож '5' == 5 дає true, а null == undefined — теж true. === порівнює без приведення, враховуючи тип, тож '5' === 5 дає false. На практиці завжди використовую ===, щоб уникати неочевидних багів.
var має функціональну область видимості й hoisting зі значенням undefined, тому зараз майже не використовується. let і const мають блокову область видимості; let можна перезаписати, const — ні. Але const для об'єкта чи масиву не робить його незмінним: вміст можна змінювати, не можна лише перезаписати посилання.
JS однопотоковий, асинхронність реалізована через event loop: синхронний код виконується в стеку викликів, а колбеки чекають у чергах. Мікрозадачі (проміси) виконуються раніше за макрозадачі (setTimeout). Проміс має стани pending, fulfilled і rejected; async/await — синтаксичний цукор над промісами, помилки ловляться через try/catch.