Quản trị chất lượng phần mềm (QA/QC) trong dự án quy mô lớn

Quản trị chất lượng phần mềm trong dự án quy mô lớn dựa trên hai trụ cột: QA (Quality Assurance, đảm bảo chất lượng) tập trung vào quy trình để ngăn lỗi phát sinh, còn QC (Quality Control, kiểm soát chất lượng) tập trung vào sản phẩm để phát hiện lỗi trước khi tới tay người dùng. Ở dự án lớn với nhiều đội, nhiều hệ thống tích hợp, chất lượng không thể dựa vào một nhóm kiểm thử cuối dây chuyền; nó phải được thiết kế vào từng bước của quy trình.

QA và QC khác nhau thế nào

Hai hoạt động bổ trợ nhau: QC phát hiện lỗi cung cấp dữ liệu để QA cải tiến quy trình, ví dụ nhiều lỗi do hiểu sai yêu cầu thì cần cải thiện cách viết và rà soát yêu cầu.

Thách thức riêng của dự án lớn

• Nhiều đội, nhiều nhịp: thay đổi của đội này có thể phá chức năng của đội khác.
• Tích hợp phức tạp: hệ thống kết nối với ERP, cổng thanh toán, hệ thống cũ, đối tác bên ngoài.
• Môi trường khan hiếm: nhiều đội tranh nhau môi trường kiểm thử chung.
• Dữ liệu kiểm thử: cần dữ liệu đủ thực tế nhưng không vi phạm quyền riêng tư.
• Kiểm thử hồi quy phình to: mỗi bản phát hành cần kiểm tra lại khối lượng chức năng ngày càng lớn.

Chiến lược kiểm thử nhiều tầng

Mô hình kim tự tháp kiểm thử vẫn là định hướng hữu ích: nhiều kiểm thử nhanh, rẻ ở tầng dưới; ít kiểm thử chậm, đắt ở tầng trên.

1. Kiểm thử đơn vị: kiểm tra từng hàm, lớp; chạy trong vài giây; lập trình viên viết cùng mã nguồn.
2. Kiểm thử tích hợp và hợp đồng API: kiểm tra các thành phần làm việc với nhau, đặc biệt quan trọng với kiến trúc microservices, nơi mỗi dịch vụ phải giữ đúng cam kết giao diện với dịch vụ khác.
3. Kiểm thử đầu cuối (end-to-end): mô phỏng hành trình người dùng quan trọng nhất qua giao diện. Giữ số lượng vừa phải vì chậm và dễ chập chờn.
4. Kiểm thử khám phá: kiểm thử viên chủ động tìm lỗi theo kinh nghiệm, không theo kịch bản cố định.

Bên cạnh kiểm thử chức năng, dự án lớn cần kiểm thử phi chức năng: hiệu năng và chịu tải trước các mốc phát hành lớn, bảo mật (quét mã nguồn, kiểm tra thư viện có lỗ hổng, kiểm thử xâm nhập định kỳ như phân tích trong bài pentest có nên thuê ngoài), khả năng truy cập và tương thích thiết bị.

Tự động hóa trong CI/CD

Ở quy mô lớn, kiểm thử thủ công cho mọi bản phát hành là không khả thi. Pipeline CI/CD nên có các cổng chất lượng:

• Mỗi pull request: biên dịch, phân tích mã tĩnh, kiểm thử đơn vị, quét bảo mật cơ bản, code review bắt buộc.
• Sau khi gộp nhánh: kiểm thử tích hợp, triển khai tự động lên môi trường kiểm thử.
• Trước khi phát hành: bộ kiểm thử hồi quy tự động, kiểm thử đầu cuối cho hành trình chính.
• Sau khi phát hành: kiểm tra nhanh (smoke test) trên môi trường thật, giám sát lỗi và hiệu năng.

Kiểm thử chập chờn (lúc đạt lúc không) là kẻ thù của tự động hóa: đội ngũ sẽ mất niềm tin và bỏ qua kết quả. Cần theo dõi và sửa hoặc loại bỏ chúng nhanh.

Quản lý môi trường và dữ liệu kiểm thử

Hạ tầng dưới dạng mã và container cho phép tạo môi trường kiểm thử tạm thời cho từng nhánh, giảm tranh chấp môi trường chung. Dữ liệu kiểm thử nên được tạo tự động hoặc lấy từ dữ liệu thật đã được ẩn danh hóa. Tuyệt đối không sao chép nguyên dữ liệu khách hàng thật sang môi trường kiểm thử; đây là yêu cầu cả về bảo mật lẫn tuân thủ quy định bảo vệ dữ liệu cá nhân.

Chất lượng bắt đầu từ yêu cầu

Rất nhiều lỗi không nằm ở mã nguồn mà ở yêu cầu mơ hồ. Các thực hành giúp giảm loại lỗi này:

• Mỗi user story có tiêu chí nghiệm thu cụ thể, có thể kiểm thử được.
• Kiểm thử viên tham gia buổi làm rõ yêu cầu ngay từ đầu.
• Dùng ví dụ cụ thể (Given/When/Then) để thống nhất cách hiểu giữa nghiệp vụ, lập trình và kiểm thử.
• Định nghĩa "hoàn thành" (Definition of Done) chung cho mọi đội, gồm cả kiểm thử và tài liệu.

Những thực hành này gắn chặt với quy trình Agile/Scrum mà nhiều dự án lớn đang áp dụng.

Đo lường chất lượng

• Lỗi lọt ra môi trường thật: số lượng và mức độ nghiêm trọng, phân tích theo nguồn gốc.
• Tỷ lệ thay đổi gây lỗi và thời gian khôi phục khi có sự cố.
• Thời gian chạy pipeline: quá chậm khiến lập trình viên né tránh kiểm thử.
• Tỷ lệ kiểm thử chập chờn.
• Nợ kỹ thuật: theo dõi qua công cụ phân tích mã và cảm nhận của đội.

Tránh dùng số lỗi tìm được để đánh giá cá nhân kiểm thử viên hay lập trình viên; điều đó tạo ra hành vi đối phó và làm hỏng tinh thần hợp tác.

Tổ chức đội ngũ chất lượng

Ở dự án lớn, mô hình hiệu quả thường là kiểm thử viên nằm trong từng đội phát triển, cộng thêm một nhóm nhỏ xây dựng nền tảng tự động hóa, công cụ, chuẩn chung và điều phối kiểm thử tích hợp liên đội. Kiểm thử viên chuyển vai trò từ "người bắt lỗi cuối cùng" sang "người huấn luyện chất lượng" cho cả đội.

Chất lượng phần mềm không phải là giai đoạn cuối dự án mà là thuộc tính được xây dựng mỗi ngày. Đầu tư vào quy trình và tự động hóa ngay từ đầu giúp dự án lớn giữ được tốc độ phát hành mà không đánh đổi sự ổn định.