Chất lượng không bắt đầu ở bước kiểm thử
Khi nói đến chất lượng phần mềm, nhiều người thường nghĩ đến việc tìm và sửa lỗi trước khi bàn giao. Đây là công việc cần thiết, nhưng chưa phản ánh toàn bộ quá trình.
Một chức năng có thể chạy đúng theo thiết kế nhưng vẫn chưa phù hợp với nghiệp vụ. Một giao diện có thể đầy đủ thành phần nhưng khiến người dùng khó hoàn thành công việc. Những vấn đề như vậy không thể chỉ giải quyết bằng việc tăng số lượng test case ở cuối dự án.
Vì thế, chất lượng cần được xây dựng từ cách hiểu yêu cầu, cách thiết kế giải pháp và cách phối hợp giữa những người tham gia.
Hiểu đúng yêu cầu là nền tảng đầu tiên
Trước khi kiểm tra phần mềm có được xây dựng đúng hay không, đội ngũ cần xác nhận điều đang xây dựng có đúng với nhu cầu hay không.
Một yêu cầu ngắn gọn có thể chứa nhiều cách hiểu. Chẳng hạn, với yêu cầu giả định ‘cho phép xuất báo cáo’, vẫn cần làm rõ ai được phép xuất, dữ liệu nào được đưa vào, bộ lọc cần thiết và định dạng đầu ra.
Nếu những điểm này chưa được xác nhận, đội ngũ có thể hoàn thành chức năng nhưng vẫn phải điều chỉnh đáng kể khi khách hàng sử dụng.
Việc trao đổi, ghi nhận Q&A và xác nhận các quyết định giúp hạn chế khoảng cách giữa mong muốn của khách hàng với cách hiểu của đội ngũ phát triển.
Review thiết kế trước khi đi sâu vào triển khai
Thiết kế là bước chuyển từ yêu cầu nghiệp vụ sang cách hệ thống hoạt động.
Ở giai đoạn này, việc rà soát tài liệu và giao diện giúp kiểm tra:
- Luồng sử dụng có phù hợp với công việc thực tế không?
- Thông tin cần thiết đã được thể hiện đầy đủ chưa?
- Những điểm chưa rõ đã được xác nhận chưa?
- Các thành phần và cách xử lý có nhất quán không?
Phát hiện một khác biệt trong cách hiểu khi còn ở tài liệu hoặc bản thiết kế thường giúp hạn chế lượng công việc phải điều chỉnh về sau.
Review thiết kế vì vậy không chỉ là kiểm tra hình thức, mà còn là cơ hội để xác nhận giải pháp trước khi đầu tư sâu hơn vào phát triển.
Sử dụng tiêu chuẩn code và checklist review
Trong giai đoạn lập trình, chất lượng cần được hỗ trợ bằng những tiêu chí kiểm tra rõ ràng.
Tiêu chuẩn code giúp đội ngũ duy trì cách viết nhất quán. Checklist review giúp người kiểm tra có cơ sở rà soát, thay vì phụ thuộc hoàn toàn vào kinh nghiệm hoặc trí nhớ của từng cá nhân.
Nội dung checklist cần phù hợp với đặc điểm dự án và được điều chỉnh khi phát hiện vấn đề mới. Mục tiêu không phải là tạo một danh sách càng dài càng tốt, mà là tập trung vào những yếu tố thực sự có ý nghĩa đối với sản phẩm.
Review cũng là dịp để các thành viên chia sẻ cách hiểu và phát hiện sớm những điểm cần làm rõ.
Kiểm thử có kế hoạch và có cơ sở đối chiếu
Kiểm thử cần gắn với yêu cầu đã thống nhất, thay vì chỉ kiểm tra phần mềm theo những thao tác thuận tiện.
Kế hoạch kiểm thử giúp xác định phạm vi và cách tổ chức công việc. Test case cụ thể hóa tình huống cần kiểm tra cùng kết quả mong đợi.
Khi yêu cầu được làm rõ và thiết kế được rà soát từ trước, hoạt động kiểm thử có cơ sở tốt hơn để đánh giá kết quả. Ngược lại, nếu yêu cầu còn mơ hồ, việc kết luận một chức năng ‘đạt’ hay ‘chưa đạt’ cũng dễ dẫn đến khác biệt giữa các bên.
Kiểm thử là một lớp kiểm soát quan trọng, nhưng không thay thế cho việc làm rõ yêu cầu hay review trong những giai đoạn trước đó.
Duy trì trao đổi khi có thay đổi
Trong quá trình triển khai, yêu cầu có thể được bổ sung hoặc điều chỉnh khi khách hàng có thêm thông tin.
Điều quan trọng là thay đổi cần được ghi nhận và truyền đạt đến những người liên quan. Khi cách xử lý thay đổi nhưng tài liệu, thiết kế hoặc test case chưa được cập nhật tương ứng, sự thiếu nhất quán có thể xuất hiện.
Trao đổi liên tục ở đây không có nghĩa là tổ chức thật nhiều cuộc họp. Điều cần thiết là thông tin đúng được chuyển đến đúng người, vào thời điểm phù hợp và có thể tra cứu lại.
Chất lượng là kết quả của nhiều bước làm đúng
Không có một checklist hay một vòng kiểm thử nào có thể thay thế toàn bộ quá trình quản lý chất lượng.
Yêu cầu rõ ràng, thiết kế được review, code được kiểm tra và kiểm thử có kế hoạch cần hỗ trợ lẫn nhau. Khi phát hiện vấn đề, bài học cũng cần được phản ánh trở lại cách làm để hạn chế lặp lại.
Đó là hướng tiếp cận Genki đề cao: quan tâm đến chất lượng trong từng giai đoạn, thay vì chờ đến lúc bàn giao mới bắt đầu đánh giá.