Get in touch
or send us a question?
CONTACT

Tại sao tester nên biết SQL?

Tester vẫn có thể làm việc rất ổn, khi không biết SQL là gì và nó hoạt động thế nào. Tuy nhiên, nếu tester không biết SQL hoặc không quan tâm đến cách chương trình xử lý thông tin bên trong nó, thì có thể bị sót bug (lỗi) trong quá trình kiểm thử phần mềm.

Tester có cần biết SQL không?

Trên thực tế, không phải dự án nào tester cũng được phép truy cập vào mã nguồn (source code) và database (cơ sở dữ liệu). Khi tham gia các dự án đó, dù có biết hay không biết về SQL cũng không giúp ích gì nhiều cho tester. Và khi ai đó nói “biết SQL” thường là họ đang muốn đề cập đến kiến thức về cơ sở dữ liệu (DB – database) hay các hệ quản trị cơ sở dữ liệu (DBMS) như MS SQL Server, Oracle, hay Postgres. Đây gọi là relational database (cơ sở dữ liệu có quan hệ), ngoài ra còn có NOSQL và nhiều dạng lưu trữ khác mà không cần cơ sở dữ liệu.

Theo nhận định cá nhân, mình chắc chắn một điều rằng, nếu tester “biết về SQL” thì sẽ biết cách dữ liệu được lưu trữ, xử lý như thế nào bên trong một ứng dụng phần mềm. Điều này giúp nhóm mình tìm ra lỗi sớm hơn và hiệu quả hơn. Thậm chí là trong các buổi thảo luận về yêu cầu hay thiết kế của chương trình.

Một số test case bị bỏ sót khi tester không biết SQL

Khi kiểm thử một ứng dụng phần mềm, nếu chỉ thao tác trên UI (User Interface – giao diện người dùng), tester có thể bỏ qua một số trường hợp. Hoặc các bạn sẽ nghĩ rằng một chức năng đã được lập trình đúng, tuy nhiên thực tế thì ngược lại – Xem thêm khái niệm false negative.

Ví dụ, khi bạn xóa một đơn hàng (gọi là Order) trên màn hình một ứng dụng web. Làm thế nào để bạn chắc chắn rằng, “chức năng xoá đơn hàng” đã thực hiện đúng đắn?

Có bạn sẽ trả lời, thì sau khi xóa xong, đơn hàng biến mất khỏi danh sách các đơn hàng, và khi tìm kiếm đơn hàng đó (dựa vào mã đơn hàng – OrderID chẳng hạn), chương trình báo kết quả “Không tìm thấy” thì đồng nghĩa là “chức năng xoá đơn hàng” đã được thực hiện đúng.

Có thể nhóm bạn đã bỏ sót một “con bug” (lỗi) mà khách hàng và người dùng không bao giờ phát hiện ra. Vì “may mắn” là trên UI không có màn hình nào để liệt kê các chi tiết đơn hàng (gọi là OrderDetails) của mọi đơn hàng.

Như vậy, nếu như bạn tìm không thấy đơn hàng sau khi xóa nó, KHÔNG có nghĩa là chức năng xóa đơn hàng đã được lập trình đúng! Tại sao?

Nếu như chức năng xoá đơn hàng, chỉ thực hiện việc “xóa đơn hàng” ra khỏi bảng Orders. Ví dụ OrderID 10248 bị xoá khỏi bảng Orders bên dưới, thì còn OrderDetails là những sản phẩm được chọn trong đơn hàng đó thì sao?

  1. Trường hợp thứ nhất, nếu chương trình xoá luôn những OrderDetails liên quan (thuật ngữ chung là “cascade delete” – tạm dịch là “xoá dây chuyền”), thì mọi thứ sẽ ổn và không chỉ chi tiết đơn hàng bị xoá, mà các thông tin khác có liên quan đến đơn hàng này đều bị xoá.
  2. Trường hợp thứ hai, bạn nghĩ sao nếu chương trình chỉ thực hiện xoá dòng có OrderID = 10248 ra khỏi bảng Orders bên dưới, trong khi mọi thứ khác như OrderDetails của nó thì vẫn còn nguyên? BUG!
SQL - Bảng Order
Orders

Ví dụ bảng OrderDetails

SQL - Bảng Order
OrderDetails

Điều tương tự có thể xảy ra khi cập nhật dữ liệu. Một test case có thể ghi nhớ ở đây là khi cập nhật hoặc xoá dữ liệu (ví dụ 1 đơn hàng), chúng ta phải đặt câu hỏi “what if” (chuyện gì sẽ xảy ra) cho những thông tin liên quan đến dữ liệu đó.
Nguồn: https://www.testing.vn/sql-for-tester