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

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

Бо екран показує не запис у базі, а те, що вирішив намалювати клієнтський код: кеш, оптимістичне оновлення стану, відповідь, склеєну з кількох джерел. «Збережено» — це лише рішення фронтенду показати успіх; сам запит у базу міг упасти, зберегти старе значення чи створити дубль. Джерело істини одне — таблиці, тому перевіряти треба не тост, а рядок: піти в базу й звірити колонку за ключем. Для 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, робить не те. Другий — реальні дані: на проді є edge cases (сирітські записи, 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.