Бази даних у роботі QA

У чому різниця між базою даних і СУБД?

Суть одним реченням: база даних — це самі дані, а СУБД — програма-сервер, що ними керує. База даних (database, БД) — набір таблиць конкретного застосунку: замовлення, користувачі, платежі. СУБД (database management system) — окремий серверний процес, який ці дані зберігає, обслуговує запити й контролює доступ: PostgreSQL, MySQL, SQL Server, Oracle. Фраза «у нас Postgres» — про СУБД; всередині одного такого сервера може жити кілька баз різних застосунків. Практичний наслідок: з'єднання ти встановлюєш із СУБД, а запити адресуєш конкретній базі в ній. Це питання-фільтр, на якому інтерв'юер швидко бачить, чи кандидат орієнтується в термінах.

Навіщо тестувальнику SQL? Коли ти лізеш у базу?

База — це джерело істини: UI й API показують уже оброблений зріз даних — із кешами, фільтрами й обчисленнями на льоту, — а база тримає первинні факти. Інтерв'юер хоче почути не визначення, а живі сценарії. Звірити правду з інтерфейсом — порахувати те саме напряму в базі й порівняти з дашбордом (коли цифра на UI не сходиться з базою, це вже класичний баг). Підготувати тестовий стан — знайти чи виставити потрібний запис швидше, ніж прокликувати весь сценарій руками. Розслідувати баг — побачити, на якому кроці ланцюжок обірвався (запис у users є, а в email_queue немає — значить, проблема в черзі листів, а не в реєстрації). Бачити невидиме — soft-delete, статуси фонових завдань, аудит-лог, які застосунок ховає. І підсилити баг-репорт рядком із бази замість самого скриншота.

Що безпечніше — SELECT чи UPDATE, і чому на проді треба бути обережним?

SELECT безпечний, бо нічого не змінює — лише читає; UPDATE/DELETE змінюють дані, і на проді це необоротно. На проді живуть справжні дані справжніх користувачів: зіпсував — і це одразу видно всім, а «скасувати» для тисячі змінених рядків не існує. Тому левова частка SQL у щоденній роботі QA — саме читання, і навчання логічно починати з SELECT. Червоний прапорець для інтерв'юера — кандидат, який спокійно каже «та я просто зроблю DELETE». Сильна відповідь згадує read-only дисципліну й пастку забутого WHERE.

Чому UPDATE чи DELETE без WHERE — це катастрофа?

Модифікуючий запит без умови зачіпає всі рядки таблиці, а не один потрібний: UPDATE orders SET status = 'cancelled' без WHERE скасує геть усі замовлення в базі. Підступність у тому, що більшість клієнтів застосовують зміну одразу — autocommit увімкнений за замовчуванням, тож окремої команди «підтвердити» немає й відкотити нема як. Одна забута умова — і стан зіпсовано незворотно. Захист простий: спершу прогнати SELECT з тим самим WHERE і глянути на кількість рядків у результаті. Очікував один, а бачиш 5000 — умова надто широка, міняти зарано.

Чим реляційна база відрізняється від NoSQL?

Реляційна база зберігає дані в таблицях (рядки й стовпці) із заздалегідь заданою фіксованою схемою, таблиці пов'язані через ключі, працюють через SQL і дають сильні гарантії цілісності — це PostgreSQL, MySQL, SQL Server, Oracle. NoSQL — парасолька над усім, що влаштоване інакше: гнучка або відсутня схема, зв'язки часто на рівні застосунку, у кожної родини своя мова чи API, а сила — у масштабі, швидкості й гнучкості замість строгої цілісності. Практичний наслідок для QA — інший клас багів: не «порушено зовнішній ключ», а «поле, яке ми чекали, у половині документів просто відсутнє», бо схему ніхто не змушує. Бонус до відповіді — що це різні інструменти під різні задачі, а не «старе проти нового»: багато систем використовують і реляційну базу як основне сховище, і Redis як кеш поверх неї.

Які є основні родини NoSQL і чим вони відрізняються?

NoSQL — не одна база, а кілька різних моделей під різні задачі. Документні (MongoDB) зберігають записи-документи в JSON-подібному форматі з гнучкою схемою — можна класти документи різної форми в одну колекцію. Ключ-значення (Redis) — найпростіша модель «дістань значення за ключем», дуже швидка, типово як кеш. Колонкові (Cassandra) оптимізовані під величезні обсяги й інтенсивний запис. Графові (Neo4j) зберігають вузли й зв'язки між ними — зручно для соцграфів і рекомендацій. Спільне для всіх — гнучкіша схема й легше горизонтальне масштабування, але за це часто платять слабшими гарантіями узгодженості (eventual consistency — «колись узгодиться»).

Де база даних стоїть у клієнт-серверній архітектурі?

Сам застосунок даних не зберігає — він тримає бізнес-логіку, а зберігання делегує окремому процесу, СУБД. Натискання кнопки в UI перетворюється на ланцюжок: сервер застосунку виконує логіку, шле СУБД SQL-запит по мережі й отримує назад рядки. Нерідко СУБД крутиться взагалі на окремій машині й слухає власний мережевий порт — це самостійний сервер зі своєю зоною відповідальності. Для QA важливо, що ця сама СУБД приймає з'єднання не лише від застосунку: власним клієнтом можна зайти повз UI й API прямо до джерела істини й побачити дані без кешу, форматування та прикладних обмежень доступу, які ховають частину даних у застосунку.

Як ти під'єднаєшся до бази — що для цього потрібно?

Потрібен клієнт і набір параметрів підключення. Клієнт — це програма, яка вміє під'єднатися до СУБД і виконати запит: консольний (psql для PostgreSQL, mysql для MySQL) або графічний (DBeaver, DataGrip, pgAdmin); новачку зазвичай простіше в GUI — там видно дерево таблиць, працює автодоповнення, а результат виводиться сіткою. Незалежно від клієнта, набір параметрів однаковий: host (адреса сервера), port (мережевий порт), database (ім'я бази всередині СУБД), user, password і часто sslmode. Ці параметри нерідко пакують в один рядок підключення (connection string) виду postgresql://user:pass@host:5432/db. Доступи — адресу, логін, пароль — дає команда (зазвичай DevOps або тимлід), а не вигадуєш сам; і правило гігієни: пароль — це секрет, у код тестів і в репозиторій він потрапляти не має, автотести читають параметри підключення зі змінних оточення.

Які порти за замовчуванням у популярних СУБД?

Варто знати напам'ять: PostgreSQL — 5432, MySQL/MariaDB — 3306, SQL Server — 1433, Oracle — 1521. Це дефолти, зашиті в клієнти й документацію, тож у типовому рядку підключення до Postgres ти й побачиш 5432. Але це саме значення за замовчуванням: на конкретному стенді адміністратор може повісити СУБД на інший порт з міркувань безпеки чи через кілька інстансів на одній машині. Тому порт завжди беруть із параметрів підключення, які дала команда, а не «бо Postgres же на 5432».

Що таке діалект SQL і чому запит зі StackOverflow може впасти?

У SQL є стандарт (ISO/IEC 9075), тож базові конструкції — SELECT, WHERE, JOIN, GROUP BY — виглядають однаково майже скрізь; розходження починаються на краях, і саме сукупність таких відхилень називають діалектом конкретної СУБД. Найчастіші розбіжності — пагінація (LIMIT 10 у PostgreSQL/MySQL проти TOP 10 у SQL Server), автоінкремент (SERIAL проти AUTO_INCREMENT проти IDENTITY), конкатенація рядків (|| проти CONCAT() проти +) і лапки для імен. Тому запит, скопійований зі StackOverflow під іншу СУБД, падає з незрозумілою помилкою синтаксису: там був TOP, а тут потрібен LIMIT; або || у MySQL за замовчуванням означає не склеювання рядків, а логічне «або». Звідси практичне правило: спершу з'ясуй, яка перед тобою СУБД, і тільки потім пиши запит.

Read-only — це те саме, що нульовий вплив на прод?

Ні, і це поширена ілюзія. Read-only означає, що ти нічого не змінюєш, але не означає, що ти нічого не навантажуєш. Важкий SELECT без обмеження на прод-таблиці в мільйони рядків може з'їсти ресурси СУБД і зачепити живих користувачів — база почне тупити для всіх. Тому на проді обмежуй вибірки через LIMIT, плануй важкі запити поза піком навантаження і, за можливості, ходи на репліку замість основної бази. Тобто безпечний за наслідками ще не означає безкоштовний за навантаженням — повага до прода не зникає від того, що ти «просто читаєш».

Як забезпечити read-only дисципліну на практиці?

Найнадійніший запобіжник — проси окремий обліковий запис лише для читання (read-only user): тоді СУБД фізично не дасть тобі щось змінити, навіть якщо ти помилишся в запиті. Далі йдуть звички: перед модифікуючим запитом — спершу SELECT з тим самим WHERE, щоб побачити майбутній радіус ураження; якщо для тесту таки потрібен запис — тільки на власних ізольованих даних у dev/тестовому середовищі, а не наосліп на спільному стенді. Страхувальною сіткою може бути транзакція (BEGIN … перевірив … ROLLBACK), але вона працює, лише якщо її явно відкрити: з увімкненим autocommit кожен окремий запит фіксується одразу. І на проді читай з LIMIT та з репліки, щоб не навантажити основну базу.

Дані на UI не збігаються з базою. З чого почати діагностику?

Перше питання — не «де баг у застосунку», а «до якого середовища й до якої бази я реально під'єднаний». Дуже часто «дані не збігаються» тому, що клієнт дивиться в dev, хоча тестуєш stage, або читає з репліки, до якої свіжий запис ще не доїхав через затримку реплікації. База рідко буває одна: є основна (primary) і копії для читання (репліки), між якими дані їдуть із лагом, а в мікросервісній архітектурі кожен сервіс може мати власну базу — тож один і той самий факт у різних місцях з'являється не одночасно. Тільки переконавшись, що дивишся в правильну базу правильного середовища, має сенс порівнювати цифри й підозрювати продукт.

У UI запис зник, а в базі він на місці. Що це означає?

Найімовірніше — soft-delete, м'яке видалення. Застосунок часто не стирає рядок фізично, а лише виставляє мітку: deleted_at із датою або is_active = false. Через UI елемент пропадає, бо застосунок фільтрує такі записи, але в базі рядок лишається на місці з усіма даними. Це не баг, а типовий патерн: він потрібен для аудиту, відновлення й історії. Для QA це важливо на двох рівнях — по-перше, «видалення» варто перевіряти саме в базі (чи справді проставилася мітка), по-друге, не сплутати soft-delete зі справжнім зникненням даних під час розслідування.

Що таке репліка й чому той самий факт видно в одному місці, а в іншому ще ні?

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

Чому паролі до баз не можна хардкодити в тестах?

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

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

Кейс 1. База як незалежний оракул: UI каже 120, API — 118

Дашборд показує «120 активних замовлень», API у відповіді віддає 118, користувач у чаті клянеться про 121. Хто має рацію — знає лише база. UI й API вже інтерпретують дані: щось відфільтрувалося, щось закешувалося, щось порахувалося на льоту. Тому замість суперечки «чий лічильник правильний» рахуємо те саме напряму в джерелі істини.

-- незалежний підрахунок того самого, що показує дашборд
SELECT count(*) AS active_orders
FROM orders
WHERE status = 'active'
  AND deleted_at IS NULL;

Результат бази — це якір, до якого прикладаємо кожну цифру:

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

• Умова в WHERE має точно повторювати логіку застосунку. Якщо дашборд рахує без урахування soft-delete, а ти забув deleted_at IS NULL, розбіжність буде рукотворна — не в продукті, а у твоєму запиті. Спершу з'ясуй, що саме застосунок вважає «активним».
• Збіг API з базою, а UI — ні локалізує баг у фронтенді або в шарі кешу/агрегації, а не в даних. Це вже конкретний, а не абстрактний баг-репорт.
• Рядок із бази підсилює репорт. «Дашборд показує 120, а SELECT count у базі дає 118» звучить переконливіше за скриншот — це відтворюваний доказ, а не враження.

Кейс 2. Анатомія катастрофи: UPDATE без WHERE і безпечний воркфлоу

Задача звучить невинно: «переведи замовлення №4471 у статус cancelled на стейджі, щоб перевірити банер». Небезпечний варіант і те, на що він насправді перетворюється:

-- НЕБЕЗПЕЧНО: забули WHERE — скасовано ВСІ замовлення в таблиці
UPDATE orders SET status = 'cancelled';

Autocommit увімкнений за замовчуванням, тож зміна застосовується одразу — окремого «підтвердити» немає, відкотити нема як. Безпечний воркфлоу перевертає порядок: спершу подивитися, кого зачепиш, і лише потім міняти.

-- Крок 1: той самий WHERE, але SELECT — читаємо, кого зачепимо
SELECT id, status FROM orders WHERE id = 4471;

-- Крок 2: переконалися, що це рівно 1 потрібний рядок — тепер міняємо
UPDATE orders SET status = 'cancelled' WHERE id = 4471;

Правило прийняття рішення перед будь-яким модифікуючим запитом:

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

• SELECT перед UPDATE — не формальність, а перевірка радіуса ураження. Побачив 5000 замість 1 — забутий чи надто широкий WHERE, і ти щойно уникнув інциденту.
• Найнадійніший запобіжник — read-only обліковий запис. Тоді СУБД фізично відхилить UPDATE, і жодна забута умова не спрацює. Проси такий доступ у команди з першого дня.
• cancelled через SQL — це не те саме, що скасування через застосунок. Прямий запис у базу оминає бізнес-логіку: не спишуться бонуси, не піде лист, не оновиться пов'язана таблиця. Тому запис у базу — інструмент підготовки стану, а не заміна тестуванню сценарію через UI.

Кейс 3. «Дані не збігаються» — а насправді не та база

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

-- швидка перевірка, де я насправді
SELECT current_database();        -- та база, що очікую?
SELECT inet_server_addr();        -- той хост/стенд, що очікую?
SELECT count(*) FROM orders WHERE id = 90271;  -- запис узагалі є?

Дерево причин розбіжності, від найчастішої до рідшої:

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

• Реплікаційний лаг — типове джерело флаку, а не баг. Запис пішов у primary, а наступний запит потрапив на репліку для читання, де його ще немає. Симптом упізнаваний: локально (одна база) зелено, у CI проти primary+репліки — плавучі падіння одразу після створення даних.
• Soft-delete легко сплутати зі зникненням. Якщо перевіряєш «видалення», перевіряй саме мітку в базі (чи проставився deleted_at), а не факт, що елемент зник з екрана — зникнути він може й через фільтр.
• Перше — середовище, потім продукт. Поки не переконався, що current_database() і хост саме ті, що очікуєш, будь-яка розбіжність цифр нічого не доводить: можливо, ти просто дивишся в паралельну реальність.

База, СУБД і архітектура

• Розумію різницю між базою даних (самі дані, таблиці) і СУБД (програма, що ними керує: PostgreSQL, MySQL, SQL Server, Oracle) — підключаюся до СУБД, а працюю з конкретною базою в ній.
• Можу пояснити, де СУБД в клієнт-серверній архітектурі: застосунок тримає бізнес-логіку, а по дані ходить до окремого процесу СУБД мовою SQL по мережі, часто на окремій машині; до тієї ж СУБД QA може під'єднатися напряму в обхід UI й API — до джерела істини без кешу, форматування й прав доступу застосунку.
• Знаю, що база рідко одна: є основна (primary) і репліки для читання із затримкою, а в мікросервісах кожен сервіс може мати власну базу.

Навіщо QA лізе в базу

• Можу назвати сценарії SQL для QA замість визначення: звірити правду з UI (незалежний оракул — порахувати те саме напряму в базі й порівняти з дашбордом), підготувати тестовий стан, розслідувати баг, побачити приховане, підсилити баг-репорт.
• Знаю, що база показує, на якому кроці обірвався ланцюжок (запис у users є, а в email_queue немає означає проблему в черзі листів, а не в реєстрації).

Реляційні vs NoSQL

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

Клієнти й параметри підключення

• Знаю два типи клієнтів: консольні (psql, mysql) і графічні (DBeaver, DataGrip, pgAdmin) — і чому для новачка GUI зручніший.
• Можу перелічити параметри підключення (host, port, database, user, password, часто sslmode) і що вони пакуються в один рядок підключення виду postgresql://user:pass@host:5432/db.
• Впізнаю порти за замовчуванням (PostgreSQL 5432, MySQL/MariaDB 3306, SQL Server 1433, Oracle 1521, на стенді може бути інший) і правила гігієни: доступи бере в команди, паролі до баз не хардкодить і не комітить, для автотестів параметри беруться з оточення.

Read-only дисципліна на проді

• Розумію головне правило trainee: на спільних стендах, і особливо на проді, тестувальник тільки читає — необоротну помилку в проді нема чим відкотити.
• Можу пояснити, чому SELECT безпечний (нічого не змінює), а UPDATE/DELETE без WHERE — катастрофа: зачіпає всі рядки, а autocommit застосовує зміну одразу.
• Знаю запобіжники: окремий read-only обліковий запис (СУБД фізично не дасть змінити), SELECT із тим самим WHERE перед модифікацією, запис лише на своїх ізольованих dev-даних, транзакція BEGIN … ROLLBACK (але при autocommit не спрацює сама).
• Розумію, що read-only не дорівнює нульовому впливу: важкий запит без LIMIT на великій прод-таблиці навантажить базу й зачепить живих користувачів — тому LIMIT, не в пік, і з репліки.

Діалекти SQL

• Розумію, що ядро SQL (SELECT, WHERE, JOIN, GROUP BY) стандартизоване й переносне, а краї — діалект, який різниться між СУБД.
• Знаю ключові розбіжності: пагінація (LIMIT проти TOP), автоінкремент (SERIAL / AUTO_INCREMENT / IDENTITY), конкатенація (|| / CONCAT / +), лапки для імен.
• Можу пояснити, чому запит зі StackOverflow під іншу СУБД падає з помилкою синтаксису — і що перед написанням запиту треба знати, з якою СУБД працюєш.

Типові пастки при розбіжностях

• Розумію, що «дані не збігаються» часто означає не той стенд або репліку з лагом, а не баг застосунку — перше перевіряю, до якого середовища й бази реально під'єднаний; сюди ж реплікаційний лаг як джерело флаку (запис пішов у primary, тест читає з репліки, де його ще немає, і бачить порожньо).
• Знаю soft-delete: у UI запис зник, а в базі рядок на місці з міткою deleted_at або is_active = false — застосунок його ховає, база ні.