UI зелёный. Тесты проходят. Команда довольна.
А баг уже живёт в базе. Тихо. Незаметно. До поры до времени.
Вот как его найти.
📍 1. Ищи дубли там, где их не должно быть
Пользователь нажал кнопку дважды, UI показал один результат. А в базе - два заказа.
SELECT user_id, COUNT(*)
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 1
Один запрос - и дубль найден.
📍 2. Ищи "осиротевшие" записи
Пользователь удалён. А его заказы остались. И висят в системе без владельца.
SELECT * FROM orders
WHERE user_id NOT IN (SELECT id FROM users)
Никто не жаловался. Но данные уже грязные.
📍 3. Ищи NULL там, где его не должно быть
Поле обязательное. А в базе - NULL.
SELECT * FROM orders
WHERE total_price IS NULL
Значит где-то не отработала валидация.
Или сценарий который никто не тестировал.
📍 4. Ищи несоответствие статусов
Заказ "доставлен".
А оплата не проведена.
SELECT * FROM orders
WHERE status = 'delivered'
AND payment_status != 'paid'
Бизнес теряет деньги. UI об этом молчит.
📍 5. Ищи аномалии во времени
updated_at раньше чем created_at.
Или заказ создан в будущем.
SELECT * FROM orders
WHERE updated_at < created_at
Такого быть не должно. Но бывает.
⚠️ Почему это важно
UI показывает то, что разработчик решил показать. БД показывает правду.
Баги в данных:
• не падают с ошибкой
• не видны в интерфейсе
• накапливаются со временем
• всплывают в самый неподходящий момент
🎯 Главная мысль
Сильный QA не ждёт когда баг проявится в UI, он идёт в данные. И находит то, что никто не искал.
👇 А вы проверяете данные напрямую или доверяете интерфейсу?
Пишите в комменты 🙂
📓 Заметки тестировщика