Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học này, chúng ta đã bàn nhiều về cách xây dựng chiến lược test, đo lường chất lượng và dẫn dắt đội ngũ. Nhưng có một loại "chất lượng" mà nếu bạn làm sai, hậu quả không phải là một bug rớt lên production, mà là công ty bị phạt hàng tỷ đồng, bị đình chỉ dịch vụ, hoặc lãnh đạo phải hầu tòa. Đó là chất lượng tuân thủ (compliance quality).
Nếu bạn đang làm QA cho một ngân hàng, ví điện tử, sàn thương mại điện tử, công ty bảo hiểm hay bất kỳ nền tảng nào xử lý dữ liệu cá nhân và tiền của người dùng Việt Nam, thì tuân thủ pháp luật không còn là "việc của phòng pháp chế". Nó trở thành một phần trực tiếp trong phạm vi kiểm thử của bạn. Một tính năng chạy đúng về mặt chức năng nhưng lưu số CCCD không mã hóa, hay cho phép chuyển tiền mà không xác thực đủ mạnh, là một tính năng fail — dù mọi test case chức năng đều pass màu xanh.
Điều khiến QA Lead ở Việt Nam bối rối là bức tranh pháp lý đang thay đổi rất nhanh: Luật An toàn Thông tin Mạng, Nghị định 13/2023 về bảo vệ dữ liệu cá nhân, các quy định của Ngân hàng Nhà nước (SBV), và chuẩn quốc tế PCI-DSS nếu bạn xử lý thẻ. Bài học này sẽ giúp bạn hiểu bức tranh đó đủ sâu để biến các yêu cầu pháp lý mơ hồ thành test case cụ thể, và để tự tin ngồi vào bàn với auditor mà không bị động.
Khái niệm cốt lõi
Compliance testing là gì và khác gì với functional testing
Compliance testing là hoạt động kiểm chứng rằng sản phẩm và quy trình vận hành tuân thủ các yêu cầu bắt buộc đến từ luật pháp, quy định của cơ quan quản lý, hoặc chuẩn ngành. Điểm khác biệt cốt lõi so với functional testing nằm ở nguồn gốc của "yêu cầu": functional requirement đến từ Product Owner, còn compliance requirement đến từ nhà nước và cơ quan quản lý — và bạn không có quyền thương lượng nó xuống thành "nice to have".
Với vai trò QA Lead, nhiệm vụ của bạn là dịch những điều khoản pháp lý viết bằng ngôn ngữ luật thành các tiêu chí kiểm thử có thể verify được. Ví dụ, điều luật nói "dữ liệu cá nhân phải được bảo vệ", bạn phải biến nó thành: mật khẩu lưu dưới dạng hash bcrypt/argon2 chứ không plaintext, dữ liệu nhạy cảm được mã hóa khi truyền (TLS 1.2 trở lên) và khi lưu trữ (at rest), có log truy cập, có cơ chế xóa dữ liệu theo yêu cầu chủ thể.
Bốn khung pháp lý bạn phải nắm
1. Luật An toàn Thông tin Mạng (ATTT) — Đây là luật khung về an toàn thông tin ở Việt Nam, quy định trách nhiệm bảo vệ hệ thống thông tin theo cấp độ (từ cấp độ 1 đến cấp độ 5). Hệ thống ngân hàng lõi hay hệ thống thanh toán quốc gia thường được phân loại cấp độ 3–5, kéo theo yêu cầu kiểm thử bảo mật, đánh giá lỗ hổng và kiểm tra định kỳ nghiêm ngặt hơn nhiều so với một blog nội bộ.
2. Nghị định 13/2023/NĐ-CP về Bảo vệ Dữ liệu Cá nhân (PDPD) — Có hiệu lực từ 01/07/2023, đây là văn bản quan trọng nhất về quyền riêng tư dữ liệu ở Việt Nam, thường được ví như "GDPR phiên bản Việt". Nó phân biệt dữ liệu cá nhân cơ bản (họ tên, ngày sinh, số điện thoại) và dữ liệu cá nhân nhạy cảm (dữ liệu sức khỏe, sinh trắc học, quan điểm chính trị, tình trạng tài chính...). Nghị định yêu cầu phải có sự đồng ý (consent) rõ ràng của chủ thể trước khi xử lý, phải có hồ sơ đánh giá tác động xử lý dữ liệu cá nhân, và trao cho người dùng quyền truy cập, chỉnh sửa, rút lại đồng ý và yêu cầu xóa dữ liệu.
3. Quy định của Ngân hàng Nhà nước (SBV) — Nếu bạn làm trong lĩnh vực ngân hàng/fintech, các thông tư của SBV chi phối rất sâu. Đáng chú ý là các quy định về an toàn giao dịch trực tuyến và xác thực giao dịch: giao dịch giá trị lớn phải dùng yếu tố xác thực mạnh (ví dụ Soft OTP theo tiêu chuẩn cao, hoặc sinh trắc học đối chiếu với CCCD gắn chip theo lộ trình xác thực sinh trắc học có hiệu lực từ 2024–2025). SBV cũng quy định về sao lưu dữ liệu, dự phòng thảm họa (DR), và báo cáo sự cố.
4. PCI-DSS (Payment Card Industry Data Security Standard) — Đây là chuẩn quốc tế, không phải luật Việt Nam, nhưng bắt buộc với bất kỳ tổ chức nào lưu trữ, xử lý hoặc truyền dữ liệu thẻ thanh toán. Nó có 12 nhóm yêu cầu cốt lõi, trong đó những điều ảnh hưởng trực tiếp đến QA gồm: không bao giờ lưu CVV/CVV2, mã hóa PAN (số thẻ) khi lưu và truyền, phân tách môi trường thẻ (cardholder data environment) khỏi phần còn lại, và không dùng dữ liệu thẻ thật trong môi trường test.
Vai trò của QA trong vòng đời tuân thủ
QA không phải là người viết chính sách tuân thủ — đó là việc của phòng Legal/Compliance và Security. Nhưng QA là tuyến kiểm chứng cuối cùng trước khi hệ thống ra thị trường. Bạn là người chứng minh bằng bằng chứng (evidence) rằng những gì chính sách yêu cầu đã thực sự được hiện thực hóa trong sản phẩm. Vì thế, tư duy quan trọng nhất là: mọi kết quả kiểm thử tuân thủ phải để lại dấu vết (audit trail) — test case, kết quả, screenshot, log — vì auditor sẽ hỏi "chứng minh đi".
Tình huống thực tế
Tình huống 1: Ví điện tử và cơn ác mộng CVV
Một công ty ví điện tử tại TP.HCM (gọi là "PayViet") chuẩn bị tích hợp thanh toán thẻ quốc tế. Đội dev, để tiện debug, đã log toàn bộ payload request thanh toán vào hệ thống logging tập trung — bao gồm cả số thẻ và CVV. Test chức năng pass hết: nạp tiền thành công, hoàn tiền thành công.
Trong đợt đánh giá PCI-DSS trước khi go-live, một QA có kinh nghiệm về compliance đã đọc kỹ file log ở môi trường staging và phát hiện CVV được ghi ra dưới dạng plaintext. Đây là vi phạm nghiêm trọng nhất của PCI-DSS: CVV tuyệt đối không được lưu dưới bất kỳ hình thức nào, kể cả trong log tạm.
Bài học rút ra: Compliance testing không chỉ nhìn vào giao diện và kết quả cuối. QA phải soi cả những nơi dữ liệu "chảy qua" — log, cache, message queue, file tạm, bản backup. Nếu QA này chỉ test theo happy path chức năng, lỗi này lọt lưới và công ty có thể bị đối tác thẻ đình chỉ dịch vụ, thiệt hại doanh thu tính bằng tháng.
Tình huống 2: Ngân hàng số và yêu cầu xác thực sinh trắc học của SBV
Một ngân hàng số ở Hà Nội triển khai tính năng chuyển khoản. Theo lộ trình của SBV, các giao dịch trên một ngưỡng giá trị nhất định (ví dụ trên 10 triệu đồng mỗi lần hoặc tổng trên 20 triệu đồng mỗi ngày) phải được xác thực bằng sinh trắc học khớp với dữ liệu CCCD gắn chip.
QA Lead ở đây đã làm đúng bài: thay vì chỉ test "chuyển 5 triệu thành công", cô xây một ma trận test dựa trên ngưỡng — chuyển 9.999.000đ (dưới ngưỡng, chỉ cần OTP), 10.000.001đ (trên ngưỡng, bắt buộc khuôn mặt), và các trường hợp cộng dồn trong ngày vượt ngưỡng. Đội test còn kiểm tra cả kịch bản khuôn mặt không khớp CCCD phải bị từ chối giao dịch, chứ không được "cho qua vì tiện".
Bài học rút ra: Với quy định SBV, các ngưỡng và giá trị biên (boundary values) chính là nơi rủi ro tuân thủ tập trung. Một test suite tốt phải phủ đúng boundary quanh mọi ngưỡng pháp lý, và phải test cả luồng từ chối, không chỉ luồng chấp nhận. Nếu chỉ test giao dịch nhỏ, ngân hàng có thể vô tình cho phép giao dịch lớn lọt qua mà không xác thực mạnh — đúng thứ mà SBV đang siết để chống lừa đảo chuyển tiền.
Tình huống 3: Sàn thương mại điện tử và quyền xóa dữ liệu theo Nghị định 13
Một sàn TMĐT (gọi là "ChoOnline") bổ sung tính năng "Xóa tài khoản" để đáp ứng quyền của chủ thể dữ liệu theo Nghị định 13/2023. Về mặt giao diện, khi người dùng bấm xóa, tài khoản biến mất, không đăng nhập lại được — test UI pass.
Nhưng QA điều tra sâu ở tầng dữ liệu phát hiện: hệ thống chỉ soft delete (đặt cờ is_deleted = 1), thông tin cá nhân vẫn nằm nguyên trong database, và tệ hơn, vẫn được đồng bộ sang hệ thống phân tích marketing. Nghị định 13 yêu cầu khi chủ thể rút đồng ý và yêu cầu xóa, dữ liệu cá nhân phải thực sự được xóa hoặc ẩn danh hóa (anonymize), trừ các trường hợp luật cho phép lưu giữ.
Bài học rút ra: "Xóa" trong ngôn ngữ pháp lý không giống "ẩn khỏi màn hình" trong ngôn ngữ kỹ thuật. QA phải verify hành vi tuân thủ ở tầng dữ liệu và cả ở các hệ thống downstream (data warehouse, CRM, backup). Bài học lớn hơn: compliance testing thường phải "đi xuyên tường" giữa các hệ thống, chứ không dừng ở một service.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để đưa compliance vào chiến lược test một cách có hệ thống.
Bước 1 — Lập bản đồ quy định áp dụng (Regulatory mapping). Ngồi với phòng Legal/Compliance và Security để liệt kê tất cả khung pháp lý áp dụng cho sản phẩm: ATTT (hệ thống của bạn ở cấp độ mấy?), Nghị định 13, thông tư SBV nào, có chạm dữ liệu thẻ để cần PCI-DSS không. Kết quả là một danh sách rõ ràng, không phỏng đoán.
Bước 2 — Dịch quy định thành yêu cầu kiểm thử (Requirement traceability). Với mỗi điều khoản, viết ra một hoặc nhiều tiêu chí verify được. Lập một ma trận truy vết: cột trái là điều khoản pháp lý, cột phải là test case ID tương ứng. Ma trận này chính là thứ auditor muốn thấy đầu tiên.
Bước 3 — Ưu tiên theo rủi ro. Không phải điều khoản nào cũng có rủi ro như nhau. Việc lưu CVV hay cho giao dịch lớn qua mà không xác thực có mức độ nghiêm trọng cao nhất. Dồn nguồn lực test vào những vùng rủi ro pháp lý cao trước (đây chính là tinh thần risk-based testing áp dụng vào compliance).
Bước 4 — Thiết kế test case bao gồm cả luồng từ chối và luồng dữ liệu. Với mỗi yêu cầu, đảm bảo có test cho: luồng hợp lệ được chấp nhận, luồng vi phạm bị từ chối, và dữ liệu được xử lý/lưu trữ đúng ở mọi tầng (transit, at rest, log, backup).
Bước 5 — Chuẩn bị dữ liệu test tuân thủ. Không dùng dữ liệu cá nhân thật hay thẻ thật ở môi trường test. Với PCI-DSS đây là yêu cầu bắt buộc. Dùng số thẻ test do tổ chức thẻ cung cấp và dữ liệu cá nhân giả (synthetic data) đã ẩn danh.
Bước 6 — Thu thập bằng chứng (evidence). Mỗi lần chạy compliance test, lưu lại kết quả, screenshot, và log. Đóng gói thành bộ hồ sơ audit. Khi cơ quan quản lý hoặc auditor PCI đến, bạn xuất ra ngay thay vì cuống cuồng chạy lại.
Bước 7 — Tích hợp vào release gate. Đưa các compliance test trọng yếu thành điều kiện bắt buộc trong quy trình release. Không pass compliance gate thì không được lên production, bất kể áp lực deadline.
Lỗi thường gặp & mẹo
Lỗi 1: Coi compliance là việc "làm một lần rồi thôi". Quy định thay đổi (SBV ra thông tư mới, Nghị định được cập nhật), và mỗi lần code đổi có thể phá vỡ trạng thái tuân thủ. Mẹo: đưa compliance test cốt lõi vào bộ regression tự động, chạy định kỳ chứ không chỉ trước audit.
Lỗi 2: Chỉ test trên UI, bỏ qua tầng dữ liệu. Rất nhiều vi phạm nằm ở nơi mắt thường không thấy: log, database, backup, hệ thống downstream. Mẹo: với mỗi yêu cầu bảo vệ dữ liệu, luôn tự hỏi "dữ liệu này còn nằm ở đâu nữa?".
Lỗi 3: Dùng dữ liệu production thật để test. Đây vừa là rủi ro rò rỉ, vừa vi phạm chính các quy định bạn đang kiểm. Mẹo: xây pipeline sinh dữ liệu test ẩn danh, và cấm tuyệt đối import dump production vào staging.
Lỗi 4: QA đứng ngoài, đợi Legal ném yêu cầu sang. Ngôn ngữ luật rất mơ hồ với kỹ sư. Mẹo: chủ động ngồi cùng Legal/Security để diễn giải điều khoản, hỏi lại đến khi ra được tiêu chí đo lường được. Bạn là cầu nối giữa luật và code.
Lỗi 5: Quên test luồng từ chối và trường hợp biên. Vi phạm tuân thủ hay xảy ra ở đúng ngưỡng và ở các case ngoại lệ. Mẹo: quanh mỗi ngưỡng pháp lý, luôn có test ngay dưới, ngay trên và đúng ngưỡng.
Mẹo tổng quát: Xây một checklist tuân thủ dùng chung cho toàn đội, cập nhật khi quy định thay đổi, và biến nó thành phần bắt buộc của Definition of Done cho mọi feature chạm dữ liệu nhạy cảm hoặc tiền.
Bài tập thực hành
- Regulatory mapping mini. Chọn một sản phẩm bạn đang làm hoặc quen thuộc (ví dụ một app đặt lịch khám bệnh). Liệt kê ít nhất 4 loại dữ liệu cá nhân mà app thu thập, phân loại chúng thành "cơ bản" hay "nhạy cảm" theo Nghị định 13, và với mỗi loại viết một yêu cầu kiểm thử bảo vệ tương ứng.
- Boundary test cho ngưỡng SBV. Giả sử quy định yêu cầu xác thực sinh trắc học cho giao dịch trên 10 triệu đồng/lần. Hãy viết bộ test case boundary đầy đủ (ít nhất 5 case) phủ dưới ngưỡng, đúng ngưỡng, trên ngưỡng, và trường hợp cộng dồn trong ngày, bao gồm cả case bị từ chối khi sinh trắc học không khớp.
- Săn dữ liệu rò rỉ. Cho một tính năng thanh toán thẻ, hãy liệt kê ít nhất 6 nơi mà dữ liệu thẻ có thể vô tình bị lưu lại (gợi ý: log ứng dụng, log web server, cache...). Với mỗi nơi, mô tả cách bạn sẽ kiểm chứng nó không lưu CVV/PAN không mã hóa.
- Xây audit evidence. Chọn một compliance test bất kỳ ở bài 1, mô tả bạn sẽ thu thập bằng chứng gì và đóng gói ra sao để trình cho auditor.
Tóm tắt
Compliance testing là loại kiểm thử mà cái giá của thất bại không tính bằng bug mà bằng tiền phạt, giấy phép và uy tín. Với QA Lead ở Việt Nam, bốn khung bạn phải nắm là Luật An toàn Thông tin Mạng (ATTT) với phân cấp độ hệ thống, Nghị định 13/2023 về bảo vệ dữ liệu cá nhân với yêu cầu consent và quyền của chủ thể dữ liệu, các quy định SBV về xác thực mạnh và ngưỡng giao dịch, và chuẩn quốc tế PCI-DSS cho dữ liệu thẻ.
Công việc cốt lõi của bạn là dịch ngôn ngữ luật thành test case verify được, ưu tiên theo rủi ro pháp lý, test cả luồng từ chối lẫn tầng dữ liệu ẩn (log, backup, downstream), dùng dữ liệu test ẩn danh, thu thập bằng chứng audit, và biến compliance thành một release gate không thể bỏ qua. Ba tình huống về CVV trong log, ngưỡng xác thực SBV, và quyền xóa dữ liệu cho thấy cùng một chân lý: một tính năng "chạy đúng" về chức năng vẫn có thể là một tính năng fail về tuân thủ. QA chính là tuyến kiểm chứng cuối cùng đứng giữa sản phẩm và cơ quan quản lý — và bằng chứng bạn để lại hôm nay là thứ cứu công ty vào ngày auditor gõ cửa.