Тестування БД: цілісність даних і міграції

Тост «Збережено» блимнув — чому цього мало, щоб вважати дані збереженими?

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

Число «Разом: 3 замовлення» на екрані — звідки воно може братися?

Одне й те саме число може приходити чотирма різними шляхами, і перевіряти їх треба по-різному. Пряма колонка — поле форми лягло один-в-один у стовпець (users.email), перевірка тривіальна. Зшивка через JOIN — значення збирається запитом з кількох таблиць і в жодній окремій не існує (імʼя клієнта в customers, позиції в order_items). Агрегат на льоту — це COUNT(*) чи SUM(amount), у базі немає колонки «разом», є рядки, які треба порахувати. Кешований лічильник — той самий count зберігають окремою денормалізованою колонкою orders_count, щоб не рахувати щоразу. Практичний висновок: перш ніж писати SELECT, зʼясуйте у розробника або з відповіді API, поле пряме, обчислене чи кешоване — від цього залежить, з чим ви звіряєте UI.

Що таке сирітський запис (orphan) і як його знайти?

Сирітський запис — це рядок, що посилається на батька, якого вже немає: замовлення з customer_id = 42, тоді як клієнта 42 видалили. Формально базі мав би завадити це зовнішній ключ (foreign key) з налаштованим ON DELETE, але сироти зʼявляються постійно. Класичний спосіб знайти їх — LEFT JOIN дитячої таблиці з батьківською і фільтр на NULL у батьківському ключі (або NOT EXISTS). Порожній результат — інваріант цілісності виконано; непорожній — у вас дані, які UI не покаже (батька немає), а звіт порахує неправильно. Це один із найтиповіших питань на співбесіді про цілісність даних.

Чому зовнішній ключ не завжди рятує від сиріт?

Тому що на практиці FK часто або вимкнений, або обійдений. Ключі вимикають заради швидкості масового імпорту й не завжди вмикають назад. Використовують мʼяке видалення (soft delete): клієнту лише проставили deleted_at, рядок фізично на місці, а замовлення далі на нього посилаються — формально ключ цілий, а логічно це вже сирота. Дані заливають в обхід застосунку — сідами, ручними скриптами, ETL, — де перевірку цілісності легко пропустити. Тому QA не покладається на «ну там же є FK», а перевіряє інваріант окремим запитом.

Що таке розсинхрон агрегатів і чому цей баг такий підступний?

Розсинхрон агрегатів — це коли кешоване зведене значення більше не збігається з тим, що воно мало б підсумовувати: posts.comments_count каже «5», а реальний COUNT дає 4. Типові причини: лічильник оновлюється окремо від самих даних (не в одній транзакції), тригер покриває не всі шляхи запису, або масовий update, backfill чи ручний фікс пройшли повз код, який тримає кеш у синхроні. Перевірка — порівняти кеш із перерахунком: LEFT JOIN на дочірню таблицю, GROUP BY і HAVING, де кешоване значення не дорівнює COUNT. Підступність у тому, що баг тихий: число виглядає правдоподібно, ніхто не помічає, поки клієнт не поскаржиться, що бачить «5 коментарів», а відкриває — чотири.

Що таке міграція і з яких частин вона зазвичай складається?

Міграція — версійована зміна схеми, яка живе в репозиторії поруч із кодом: нова колонка, таблиця чи індекс описані окремим кроком. Інструмент (Flyway, Liquibase, Prisma Migrate, міграції Rails чи TypeORM) памʼятає, які кроки вже застосовані, і накочує нові по черзі — так схема на всіх середовищах сходиться до одного стану. Всередині кроку зазвичай дві частини: up застосовує зміну, down — скасовує. Головне для QA — розуміти, що up і down симетричні лише щодо схеми, а не щодо даних.

Чому «відкотимо міграцію, якщо що» — небезпечна ілюзія?

Тому що down відновлює структуру, а не вміст. Якщо up зробив DROP COLUMN phone, телефони зникли разом із колонкою; down створить колонку phone заново — але порожню, повертати вже нічого. Rollback схеми не дорівнює rollback даних. Тому для деструктивних міграцій «ми просто відкотимо» не працює, і на проді замість down частіше їдуть уперед: накочують наступну міграцію, яка виправляє стан (roll-forward). Правильне питання розробнику на рев'ю: «а що робить down цієї міграції і чи не втратимо ми дані?».

Чому не всі міграції взагалі оборотні?

Крім втрати даних при DROP, є ще технічні причини. Додавання NOT NULL-колонки без дефолту на непорожню таблицю впаде або надовго заблокує таблицю — бо базі нічим заповнити наявні рядки. Зміна типу може не мати зворотного перетворення: з text в integer — не завжди, бо в тексті могло лежати те, що в число не лягає. Деякі операції в проді роблять окремими кроками саме тому, що прямий відкіт неможливий. Для QA це означає: питання «чи можна відкотити?» не риторичне — на нього є конкретна відповідь для кожної міграції.

Чому міграцію треба тестувати на копії реальних даних, а не на порожній тестовій базі?

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

Що таке rolling deploy і чому через нього не можна робити RENAME COLUMN «в лоб»?

Rolling deploy — це викладка, під час якої новий і старий код працюють одночасно кілька хвилин, поки інстанси оновлюються по черзі. Якщо в цей момент зробити ALTER TABLE ... RENAME COLUMN name TO full_name, інстанси зі старим кодом, які ще читають name, почнуть падати одразу — колонки з таким іменем уже немає. Тому схема мусить бути беквард-сумісною: сумісною з кодом, що вже крутиться. Це головна причина, чому зміну схеми не роблять однією руйнівною операцією, а розтягують на серію сумісних.

Що таке expand-contract і з яких кроків він складається?

Expand-contract (він же parallel change, паралельна зміна) — патерн безпечної зміни схеми серією сумісних кроків, розтягнутою на кілька релізів. Expand — додаємо нову колонку full_name, не чіпаючи стару name; код пише в обидві, стара логіка досі читає name і працює. Backfill — заповнюємо full_name для старих рядків. Switch — новий реліз перемикає читання на full_name; обидві колонки ще на місці, тож і відкотити реліз безпечно. Contract — коли жоден код більше не торкається name, окремою пізнішою міграцією її видаляють. Так руйнівну операцію (RENAME) замінюють на ланцюг сумісних, і в кожен момент часу схема годиться і для старого, і для нового коду.

Що QA перевіряє на кожному етапі expand-contract?

Після expand — що старі сценарії не зламані: беквард-сумісність, стара колонка й стара логіка досі працюють. Після switch — що нові дані читаються з нової колонки, а не зі старої. Після contract — що ніщо більше не звертається до зниклої колонки (жоден запит, звіт чи фоновий джоб на неї не спирається). Найчастіший провал, який має ловити QA, — стрибок з expand одразу в contract в одному релізі: команда забуває, що під час деплою живий ще й старий код, і той падає на зниклій колонці.

Що таке backfill і на яких двох рівнях його перевіряють?

Backfill — це заповнення заднім числом: нова колонка чи таблиця отримує значення, обчислені з рядків, які вже є. Додали full_name — мільйону старих користувачів його треба проставити з first_name і last_name. На великих таблицях це роблять батчами, щоб одна довга транзакція не тримала блокування на мільйонах рядків. QA перевіряє його на двох рівнях. Звірка кількостей (count reconciliation) — чи не пропущено рядки: скільки лишилось із порожнім full_name; нуль — заповнено всіх, не нуль — backfill не доїхав. Рядкова звірка (row-level) — чи правильні самі значення: кількість може зійтися, а формула брехати (зайвий пробіл, переплутані колонки, обрізаний рядок), тому вибірково порівнюють обчислене значення з очікуваним.

Чому успішна count-звірка ще не доводить, що backfill правильний?

Бо count каже лише скільки рядків заповнено, а не що саме в них лежить. Кількість може повністю зійтися — жодного NULL, — а значення бути неправильні: формула склеїла з зайвим пробілом, переплутала first_name і last_name, обрізала довгий рядок. Тому після count-звірки роблять рядкову: беруть рядки, де збережене значення не дорівнює перерахованому за формулою очікуваному, і дивляться, що там. Плюс перевіряють ідемпотентність — чи можна перезапустити backfill, не зіпсувавши вже заповнені рядки, бо після збою його часто запускають повторно, і «двічі — той самий результат» має виконуватись.

Що таке ETL і як QA звіряє source проти target?

ETL (extract-transform-load) — конвеєр, який забирає дані з джерела, перетворює їх і кладе в інше місце: сховище даних (data warehouse) для звітності, аналітичну базу, суміжний сервіс. Для QA тестування ETL зводиться до звірки двох баз — source і target. Рівнів три: кількості (з source вийшло стільки ж рядків і грошей, скільки прийшло в target), ключові агрегати (сума платежів за день має зійтися з обох боків) і вибіркова перевірка трансформації (кілька десятків конкретних записів звіряють руками після перетворення). Якщо цифри розійшлися, підозрюваних троє: рядки загубились (надто жорсткий фільтр), рядки задвоїлись (повторний прогін без дедуплікації) або трансформація спотворила значення — округлення, зсув таймзони, NULL, що став нулем.

Source і target в ETL розійшлися. Чому це не завжди баг у коді?

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

Чому довідники між середовищами — тиха загроза, і чому код має спиратися на code, а не на id?

Довідник (reference data) — таблиця-словник на кшталт статусів замовлень, кодів валют, ролей чи типів документів; заповнюється сідами або окремими data-міграціями. Загроза тиха, бо нічого не падає: просто на тесті під status_id = 5 лежить «Скасовано», а на проді під тим самим id — «Повернуто». Автотест зелений — на його середовищі все узгоджено, — а прод із тією самою логікою робить не те. Звідси інваріант: довідникові рядки мають бути детерміновані й ідентичні на всіх середовищах, включно з id. А код має чіплятися за стабільний ключ (code = 'CANCELLED'), бо автоінкрементний id — випадковість конкретної бази: на різних середовищах він міг проставитися по-різному.

Тест зелений на стейджі, падає на проді. Де копати перш ніж писати «баг у коді»?

Серед версій відповіді очікують не лише «баг у коді», а розсинхрон даних між середовищами. Найперший підозрюваний — довідники/сіди: той самий id означає різні статуси на стейджі й проді, і логіка, привʼязана до id, робить не те. Другий — реальні дані: на проді є крайові випадки (сироти, NULL, дублі, значення, яких немає в чистій тестовій базі), і саме вони чіпляють баг, невидимий на стейджі. Третій — стан середовища й міграції: чи всі міграції доїхали на прод, чи не залишилась колонка з попереднього етапу expand-contract. Сильна відповідь показує, що кандидат розрізняє «баг застосунку» і «розбіжність середовищ/даних», а не одразу заводить дефект на розробника.

Три кейси, де база вирішує, зелений тест чи прихований баг: звірка того, що показав UI, з тим, що реально лягло в таблиці (плюс пошук сиріт і розсинхрону лічильника), рев'ю ризикової міграції за схемою expand-contract, і перевірка backfill на двох рівнях разом зі звіркою ETL source проти target. Скрізь — що дивитися і чому.

Кейс 1. UI сказав «Збережено» — питаємо базу

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

test('баланс на екрані збігається з базою після оплати', async ({ page }) => {
  await page.getByRole('button', { name: 'Оплатити' }).click();
  await expect(page.getByTestId('toast')).toHaveText('Збережено');

  const onScreen = await page.getByTestId('balance').innerText();

  const { rows } = await db.query(
    'SELECT balance FROM accounts WHERE user_id = $1',
    [userId],
  );
  // правда не в тості, а в рядку
  expect(onScreen).toBe(formatMoney(rows[0].balance));
});

Далі — два інваріанти цілісності, які UI взагалі не покаже. Сироти: замовлення, що посилаються на неіснуючого клієнта.

-- Порожній результат = сиріт немає (інваріант виконано)
SELECT o.id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.id = o.customer_id
WHERE c.id IS NULL;

Розсинхрон денормалізованого лічильника: кешований comments_count проти реального підрахунку.

-- Рядки, де кеш розійшовся з реальністю
SELECT p.id, p.comments_count AS cached, COUNT(cm.id) AS actual
FROM posts AS p
LEFT JOIN comments AS cm ON cm.post_id = p.id
GROUP BY p.id, p.comments_count
HAVING p.comments_count <> COUNT(cm.id);

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

• Тост — не оракул. «Збережено» означає лише, що клієнт так вирішив намалювати; запит у базу міг упасти чи зберегти старе. Асертимо рядок за ключем, а не текст тоста.
• Пряме поле чи кешоване — різна перевірка. Якщо balance — денормалізований лічильник, він може відставати від реальних транзакцій; тоді додатково звіряємо його з SUM по руху коштів, а не лише з екраном.
• Сироти — це дані, яких UI не бачить. Клієнта немає, тож на екрані замовлення не зʼявиться, а звіт його порахує. Непорожній результат першого запиту — готова знахідка.
• Розсинхрон лічильника — тихий баг. Число «5 коментарів» виглядає правдоподібно, поки хтось не відкриє й не побачить чотири. HAVING cached <> actual ловить це до клієнта.

Кейс 2. Рев'ю міграції: чи справді її можна відкотити

На рев'ю прилетіла міграція, що «просто перейменовує колонку». У проді rolling deploy — старий і новий код працюватимуть одночасно кілька хвилин. Питання QA не «чи компілюється», а «що станеться зі старим кодом і чи не втратимо дані».

Небезпечний варіант, який ловимо на рев'ю:

-- up
ALTER TABLE users RENAME COLUMN name TO full_name;
-- down
ALTER TABLE users RENAME COLUMN full_name TO name;

Безпечний — expand-contract, розтягнутий на релізи. Реліз 1 (expand): додати нову колонку, код починає писати в обидві.

-- Реліз 1: expand — стара колонка недоторкана, старий код працює
ALTER TABLE users ADD COLUMN full_name text;

Далі backfill старих рядків, окремий реліз перемикає читання на full_name, і лише коли жоден код не торкається name — окрема пізніша міграція DROP COLUMN name (contract).

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

• RENAME в лоб валить старий код. Під час деплою інстанс, що ще читає name, миттєво падає — колонки вже немає. Саме тому руйнівну зміну розбивають на сумісні кроки.
• down повертає схему, не дані. Якби up робив DROP COLUMN phone, його down відтворив би порожню колонку — телефони вже втрачені. «Відкотимо, якщо що» для деструктивних міграцій не працює; на проді роблять roll-forward.
• Найтиповіший провал — expand одразу в contract. Додали й видалили в одному релізі, забувши про живий старий код. Contract — завжди окремий пізніший реліз.
• Тестувати на копії реальних даних. NOT NULL без дефолту чи зміна типу на порожній тестовій базі пройдуть; на проді з мільйоном рядків — впадуть.

Кейс 3. Backfill і ETL: рахуємо не лише «скільки», а й «що саме»

Backfill проставив full_name мільйону користувачів батчами. Перша перевірка — count-звірка: чи не пропущено рядки.

-- Скільки лишилося незаповненими (0 = доїхав до всіх)
SELECT COUNT(*) FROM users WHERE full_name IS NULL;

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

-- IS DISTINCT FROM: бо <> з NULL дасть NULL і тихо пропустить рядок
SELECT id, full_name, first_name || ' ' || last_name AS expected
FROM users
WHERE full_name IS DISTINCT FROM first_name || ' ' || last_name;

Та сама логіка звірки — між двома базами в ETL: скільки платежів вийшло з джерела, стільки й прийшло в сховище.

-- source
SELECT COUNT(*), SUM(amount) FROM payments WHERE created_at::date = '2026-07-16';
-- target (сховище)
SELECT COUNT(*), SUM(amount) FROM fact_payments WHERE payment_date = '2026-07-16';

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

• Нуль у count — необхідна, але не достатня умова. Він доводить лише повноту (немає NULL), не коректність. Обовʼязкова друга перевірка — рядкова звірка значень.
• Ідемпотентність. Backfill після збою часто перезапускають; переконайтеся, що повторний прогін не подвоює й не перезатирає вже коректні рядки — «двічі той самий результат».
• Розбіжність source/target — три причини. Загублені рядки (фільтр відсік більше, ніж мав), задвоєні (повторний прогін без дедуплікації), спотворення в трансформації (округлення, таймзона, NULL → 0).
• Спершу перевір «дані, що спізнились». Вчорашній запис міг приїхати сьогодні — вчорашня звірка «недорахує» без жодної помилки в коді. Це не дефект, а часове вікно; заводити баг — лише переконавшись, що річ не в late-arriving.

Мапінг UI/API ↔ таблиці

• Розумію, чому UI не джерело правди: він показує кеш, оптимістичний стан чи зшиту з кількох джерел відповідь, а правда лише в таблицях.
• Можу назвати чотири шляхи, звідки береться число на екрані (пряма колонка, JOIN, агрегат на льоту, кешований лічильник), і знаю, що тип поля диктує, з чим звіряти UI.
• Можу написати звірку екранного значення з базою прямо в автотесті — витягнути число з UI й зіставити з SELECT за тим самим ключем.

Сироти й розсинхрон агрегатів

• Можу пояснити, що таке сирітський запис (orphan) — рядок, що посилається на неіснуючого батька, — і знайти сиріт через LEFT JOIN + parent.id IS NULL (або NOT EXISTS).
• Розумію, чому зовнішній ключ не завжди рятує: FK вимикають для імпорту, soft delete лишає рядок «живим», дані ллють в обхід застосунку.
• Можу пояснити розсинхрон агрегатів (кешований comments_count розійшовся з реальним COUNT після операції повз код), знаю запит-перевірку LEFT JOIN + GROUP BY + HAVING (кеш ≠ COUNT) і розумію, чому цей баг тихий.

Міграції: up, down, rollback

• Знаю, що міграція — версійована зміна схеми в коді (up застосувати / down відкотити), а інструмент тримає список застосованих і накочує нові по черзі.
• Можу пояснити, чому down повертає схему, але не дані (down після DROP COLUMN відтворює порожню колонку), і чому на проді частіше roll-forward, а не down.
• Знаю, чому не всі міграції оборотні: NOT NULL без дефолту на непорожню таблицю, зміна типу без зворотного перетворення.
• Розумію, чому міграцію тестують на копії реальних даних, а не на порожній базі — на порожній усе завжди зелене.

Беквард-сумісність і expand-contract

• Можу пояснити rolling deploy (старий і новий код працюють одночасно) і чому RENAME COLUMN «в лоб» валить старий код, що ще читає стару назву.
• Можу перелічити кроки expand-contract: expand (додати нову, писати в обидві) → backfill → switch (читати нову) → contract (видалити стару).
• Знаю, що QA перевіряє на кожному етапі: після expand — старе не зламане; після switch — читається нова колонка; після contract — ніщо не чіпає зниклу.
• Розумію найтиповіший провал: стрибок з expand одразу в contract в одному релізі, забувши про живий старий код.

Backfill

• Можу пояснити, що таке backfill — заповнення нової колонки даними з наявних рядків, часто батчами.
• Знаю два рівні перевірки — count-звірка (нічого не пропущено, немає NULL) і рядкова звірка значень — і чому самої count-звірки замало (формула може брехати: пробіл, переплутані колонки, обрізаний рядок).
• Можу пояснити ідемпотентність backfill: перезапуск після збою не має псувати вже заповнені рядки.

ETL і довідники між середовищами

• Розумію, що тестування ETL — це звірка source vs target (кількості, ключові агрегати, вибіркові трансформовані рядки), і знаю три причини розбіжності: загублені рядки, задвоєні, спотворення в трансформації.
• Можу пояснити «дані, що спізнились» (late-arriving) і чому розбіжність source/target тут не баг коду.
• Знаю інваріант довідників: детерміновані й однакові між середовищами (той самий id не має означати різні статуси на test і prod), а код спирається на стабільний code, а не на автоінкрементний id.