Tester Học SQL Bắt Đầu Từ Đâu Cho Đúng?

Vì Sao Tester "Mù" SQL Sẽ Thiệt Thòi?

Dashboard test xanh lè, test case pass gần hết, release đúng lịch, nhưng tiền vẫn "bay" vì dữ liệu sai ở tầng dưới UI. Đây không phải chuyện hiếm, Chúng ta đã từng mổ xẻ một case y hệt.

Không có SQL, bạn chỉ kiểm tra được cái UI cho bạn thấy. Có SQL, bạn tự vào database, gõ một câu query, và có bằng chứng rõ ràng ngay trước mắt.

Vài lợi ích thấy ngay:

• Tự verify dữ liệu test thay vì chờ backend xác nhận
• Report bug kèm bằng chứng SQL, tăng độ tin cậy
• Phát hiện lỗi ẩn mà UI không bao giờ hiển thị
• Rút ngắn thời gian điều tra lỗi từ hàng giờ xuống vài phút

Tip: Bạn không cần giỏi SQL như DBA. Chỉ cần đủ để tự trả lời câu hỏi "dữ liệu này đúng hay sai?".

Một hệ thống có thể hiển thị đúng trên UI nhưng lưu sai dữ liệu bên dưới. Chẳng hạn:

• UI báo thanh toán thành công nhưng đơn hàng vẫn ở trạng thái PENDING
• Tổng tiền trên màn hình đúng nhưng số tiền lưu trong database bị lệch
• Người dùng đã bị trừ ví nhưng không được cấp quyền truy cập khóa học
• API trả về một order nhưng database lại tạo hai bản ghi
• Một order tồn tại nhưng không có dòng sản phẩm tương ứng
• Dữ liệu được lưu đúng giá trị nhưng liên kết nhầm sang người dùng khác

Đó là lý do Tester biết SQL có thể kiểm tra sâu hơn một bước. Thay vì chỉ hỏi “màn hình có đúng không?”, họ có thể tiếp tục hỏi “hệ thống thực sự đã lưu gì?”.

Khi kiểm thử một luồng quan trọng, bạn nên cố gắng đối chiếu ba lớp:

Nếu cả ba lớp nhất quán, bằng chứng để kết luận Pass sẽ đáng tin cậy hơn nhiều.

Mô Hình Dữ Liệu Tester Hay Đụng Nhất: Users – Orders – Order Items

Hầu hết hệ thống thương mại điện tử, edtech hay fintech đều xoay quanh 3 bảng lõi này. Nắm được chúng, bạn đọc hiểu phần lớn schema thực tế.

Trong schema này:

• orders.user_id cho biết đơn hàng thuộc về người dùng nào
• order_items.order_id cho biết dòng sản phẩm thuộc đơn hàng nào
• order_items.course_id dùng khi người học mua cả khóa học
• order_items.lesson_id dùng khi người học mở khóa một bài riêng lẻ
• orders.amount là số tiền được lưu ở cấp đơn hàng
• order_items.price là giá của từng dòng sản phẩm

Nắm được khóa chính và khóa ngoại sẽ giúp bạn biết phải JOIN các bảng qua cột nào. Đừng JOIN bằng tên, email hoặc trạng thái nếu đã có ID dành riêng cho quan hệ.

Nếu bạn đang test song song cả API lẫn database, khóa học API Testing cơ bản sẽ giúp bạn nối được request/response với dữ liệu thực tế trong 3 bảng này.

Đọc schema trước khi viết query

Tên cột không giống nhau ở mọi dự án. Tổng tiền đơn hàng có thể được đặt là amount, total_amount, grand_total hoặc một tên khác.

Thay vì đoán, hãy kiểm tra cấu trúc thật:

Việc xem schema trước giúp bạn:

• Biết chính xác tên bảng và tên cột
• Xác định kiểu dữ liệu trước khi viết điều kiện
• Tìm đúng cột dùng để JOIN
• Không đoán giá trị enum hoặc trạng thái
• Phân biệt cột bắt buộc với cột có thể để trống

Bộ Lệnh SQL Tester Cần Thành Thạo

Không cần học hết một cuốn giáo trình Database dày cộp. Tester chỉ cần nắm vững một nhóm lệnh nhỏ nhưng dùng lại liên tục mỗi ngày.

Ngoài ra, bạn nên làm quen với:

• LIMIT: Giới hạn số dòng khi khám phá dữ liệu
• DISTINCT: Xem những giá trị khác nhau đang tồn tại
• COUNT: Đếm bản ghi
• SUM: Tính tổng dữ liệu
• COALESCE: Thay thế giá trị NULL
• Alias với AS: Đặt tên kết quả dễ đọc hơn

SELECT và WHERE

Ví dụ một câu query thực chiến để tìm đơn hàng có tổng tiền bất thường:

Thay vì dùng SELECT *, hãy chọn đúng những cột phục vụ mục tiêu kiểm thử. Kết quả sẽ dễ đọc hơn và người khác cũng hiểu được bạn đang kiểm tra điều gì.

DISTINCT

Nếu chưa biết một cột trạng thái đang chứa những giá trị nào, hãy kiểm tra trước:

SELECT DISTINCT status
FROM orders
ORDER BY status;

Cách này hữu ích với:

• Trạng thái đơn hàng
• Trạng thái bài nộp
• Loại giao dịch ví
• Vai trò người dùng
• Loại nội dung được mua

INNER JOIN và LEFT JOIN

Muốn xem đơn hàng cùng thông tin người mua:

SELECT
    o.id AS order_id,
    u.name AS user_name,
    u.email,
    o.amount,
    o.status,
    o.created_at
FROM orders AS o
JOIN users AS u
    ON u.id = o.user_id
ORDER BY o.created_at DESC
LIMIT 20;

Muốn tìm user chưa có đơn hàng:

SELECT
    u.id,
    u.name,
    u.email
FROM users AS u
LEFT JOIN orders AS o
    ON o.user_id = u.id
WHERE o.id IS NULL
ORDER BY u.created_at DESC
LIMIT 20;

Thử sức với câu hỏi nhanh này trước khi qua phần thực hành:

INNER JOIN chỉ trả về những dòng có dữ liệu khớp ở cả hai bảng. LEFT JOIN giữ lại toàn bộ dữ liệu từ bảng bên trái, kể cả khi bảng bên phải không có bản ghi tương ứng.

Với Tester, LEFT JOIN rất quan trọng vì nó giúp tìm dữ liệu bị thiếu. Nếu đang tìm order không có item mà dùng INNER JOIN, những order lỗi đó có thể bị loại khỏi kết quả.

GROUP BY và HAVING

WHERE lọc dữ liệu trước khi nhóm. HAVING lọc kết quả sau khi đã GROUP BY.

Ví dụ tìm những người dùng có từ hai đơn hàng trở lên:

SELECT
    user_id,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount
FROM orders
GROUP BY user_id
HAVING COUNT(*) >= 2
ORDER BY order_count DESC
LIMIT 50;

Thực Hành: Đối Chiếu Tổng Tiền Đơn Hàng Có Đúng Không?

Đây là bài toán tester gặp gần như mỗi sprint có tính năng thanh toán tương tự case test thanh toán từng phân tích: Số tiền hiển thị trên UI có thực sự khớp với tổng các dòng sản phẩm trong đơn không?

Query đối chiếu (reconciliation query), tự chạy thử bên dưới:

Bất kỳ dòng nào query trả về đều là nghi phạm. Ghi lại thành test case rõ ràng, đừng chỉ nói "sai số tiền":

Query này sử dụng LEFT JOIN để không bỏ sót order không có item.

Nếu một order không có order_items, SUM(oi.price) sẽ trả về NULL. Hàm COALESCE(..., 0) chuyển giá trị đó thành 0 để phép đối chiếu vẫn hoạt động.

Cách đọc kết quả:

Nếu query trả về danh sách dài, cách điều tra root cause bug production sẽ giúp bạn khoanh vùng nhanh hơn thay vì report tràn lan.

Kiểm tra order không có item

SELECT
    o.id,
    o.user_id,
    o.amount,
    o.status
FROM orders AS o
LEFT JOIN order_items AS oi
    ON oi.order_id = o.id
WHERE oi.id IS NULL
ORDER BY o.created_at DESC
LIMIT 50;

Query này nên trả về 0 dòng nếu mọi order đều có ít nhất một item hợp lệ.

Kiểm tra trạng thái thanh toán

Những query trên chuyển quy tắc nghiệp vụ thành điều kiện có thể kiểm tra:

Query trả về 0 dòng không chứng minh toàn bộ hệ thống không có lỗi. Nó chỉ cho biết chưa tìm thấy dữ liệu vi phạm đúng điều kiện đang được kiểm tra.

Viết bug report từ kết quả SQL

Thay vì chỉ ghi “sai tổng tiền”, hãy cung cấp:

• Order ID
• User ID hoặc email
• Giá trị hiển thị trên UI
• Giá trị API trả về
• orders.amount
• Tổng order_items.price
• Khoảng chênh lệch
• Trạng thái order
• Thời điểm xảy ra
• Query dùng để xác minh

Ví dụ:

Order order_123 đang ở trạng thái PAID. orders.amount là 540.000 đồng nhưng tổng order_items.price là 490.000 đồng, chênh lệch 50.000 đồng. Đính kèm request ID và reconciliation query để điều tra.

Một bug report như vậy giúp Developer biết ngay dữ liệu nào sai, sai ở đâu và kiểm tra lại bản sửa bằng cách nào.

Lỗi Tester Hay Gặp Khi Học SQL (Và Cách Né)

Phần lớn Tester học SQL bị nản vì học sai cách: Học như đang đào tạo để làm DBA, không phải để test.

Một số lỗi khác Tester mới học SQL thường gặp:

• Dùng SELECT * cho mọi tình huống
• Không thêm LIMIT khi khám phá bảng lớn
• JOIN bằng cột không phải khóa
• Dùng INNER JOIN khi đang tìm dữ liệu bị thiếu
• Đoán tên cột mà không đọc schema
• Không xử lý giá trị NULL
• Chỉ quan tâm query có chạy mà không xác định kết quả mong đợi
• Thay đổi dữ liệu trước khi lưu bằng chứng
• Học cú pháp tách rời khỏi quy tắc nghiệp vụ

Lộ Trình Học SQL Cho Tester + Lời Kết

Để học đúng hướng, bạn có thể chia nhỏ thành lộ trình thực hành:

Tuần 1: Đọc dữ liệu

• Viết SELECT với đúng cột cần kiểm tra
• Lọc bằng WHERE
• Sắp xếp bằng ORDER BY
• Giới hạn kết quả bằng LIMIT
• Làm quen với NULL

Tuần 2: Đọc quan hệ

• Hiểu khóa chính và khóa ngoại
• Thực hành INNER JOIN
• Thực hành LEFT JOIN
• Tìm dữ liệu không có quan hệ
• Đối chiếu user với order

Tuần 3: Kiểm tra dữ liệu tổng hợp

• Dùng COUNT
• Dùng SUM
• Nhóm dữ liệu với GROUP BY
• Lọc nhóm bằng HAVING
• Đối chiếu amount với tổng item

Tuần 4: Gắn SQL với test case

• Chuyển quy tắc nghiệp vụ thành query
• Xác định kết quả Pass/Fail
• Lưu query vào test evidence
• Viết bug report kèm dữ liệu
• Dùng lại query cho regression test

Trong lúc chờ khóa SQL Cơ Bản Cho Tester/QA của T5Edu ra mắt, bạn có thể bắt đầu ngay với khóa Testing cơ bản để chắc nền tảng kiểm thử, hoặc đọc thêm Lộ Trình Học Tester: Từ Zero Đến Chuyên Nghiệp và 7 ngày thử nghề Tester để định hình lộ trình tổng thể.

Vài điều cần nhớ:

• Tester không cần giỏi SQL như DBA, chỉ cần đủ để tự verify dữ liệu
• Ưu tiên SELECT, WHERE, JOIN, GROUP BY trước khi học thứ phức tạp hơn
• Đọc schema thật trước khi viết query
• Dùng LEFT JOIN khi cần tìm dữ liệu liên quan bị thiếu
• Xác định kết quả mong đợi trước khi chạy query
• Report bug kèm reconciliation query sẽ tăng độ tin cậy ngay lập tức
• Kết hợp UI, API và database để có bằng chứng kiểm thử đầy đủ

Nếu tuần sau bạn có đợt regression test cho tính năng thanh toán, hãy thử tự chạy 1 câu query đối chiếu tổng tiền trước khi report bug thay vì chỉ tin vào UI.

Còn bạn, hiện tại bạn đang gặp khó nhất ở JOIN hay ở việc tự tin đọc schema database?