This is a question I get asked a lot: "If I tested it on the UI, why do I need to test the database too?" Because they test different things. The UI can show you a green tick while the database is on fire. Let me break down exactly what gets tested where.
| Feature | What to Verify in UI | What to Verify in Database |
|---|---|---|
| User Registration | Form validation, success message, redirect | All fields saved correctly, no truncation, correct data types, timestamps |
| Login | Error messages, session creation, redirect | Password stored as hash (not plain text), last_login updated, failed_attempts incremented |
| Money Transfer | Balance display updated, confirmation shown | Sender balance decreased, receiver increased, transaction record created, ACID compliance |
| Product Search | Results displayed, filters work, pagination | Query uses index (not full table scan), results match query criteria exactly |
| Order Placement | Cart total correct, order confirmation page | Order record created, all line items saved, inventory decremented, payment record exists |
| Profile Update | Updated name displayed on screen | Only intended fields changed, updated_at timestamp refreshed, old values in audit log |
| Account Deletion | Confirmation dialog, redirect to home | User record deleted/soft-deleted, child records handled (cascade/nullify), sessions invalidated |
| Report Generation | Report displays with correct numbers | Query returns accurate aggregations, no missing rows, correct GROUP BY logic |
User places an order for 3 items worth Rs 500 each. The UI shows "Order placed successfully! Total: Rs 1,500." Great. Now check the database:
-- UI says total = Rs 1500. Let us verify.
-- Check 1: Does the order exist?
SELECT order_id, user_id, total_amount, status, created_at
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 1;
-- Verify: total_amount = 1500.00, status = 'pending' or 'confirmed'
-- Check 2: Are all 3 line items saved?
SELECT product_id, quantity, unit_price, (quantity * unit_price) AS line_total
FROM order_items
WHERE order_id = 5001;
-- Verify: 3 rows, each with quantity=1 and unit_price=500.00
-- Check 3: Does the sum match the order total?
SELECT SUM(quantity * unit_price) AS calculated_total
FROM order_items
WHERE order_id = 5001;
-- Verify: 1500.00 — matches the orders.total_amount
-- Check 4: Was inventory updated?
SELECT product_id, stock_quantity
FROM products
WHERE product_id IN (SELECT product_id FROM order_items WHERE order_id = 5001);
-- Verify: stock_quantity decreased by 1 for each productKey Point: The UI test tells you the order was placed. The database test tells you the order was placed correctly — with the right amount, the right items, the right inventory update, and the right transaction record.
Q: Why is database testing needed if you already test the UI?
A: UI testing verifies what the user sees. Database testing verifies what actually happened behind the scenes. The UI can display "Success" while the data is corrupted, truncated, or partially saved. Database testing catches issues like missing constraints, orphan records, wrong calculations in triggers, data type mismatches, and performance bottlenecks — none of which are visible in the UI. Both types of testing are complementary and necessary for comprehensive quality assurance.
Key Point: UI testing checks what the user sees. DB testing checks what actually happened. You need both for full coverage.