Tôi nhận được một email hỏi: “Ai chịu trách nhiệm về chất lượng phần mềm? Điều đó phải thuộc về người đảm bảo chất lượng phần mềm bởi vì đó là việc của họ hay thuộc về người kiểm thử, người phải kiểm tra chất lượng? Làm sao tôi đo được chất lượng của sản phẩm phần mềm?”

Câu trả lời của tôi: “Lỗi là một cách đo chất lượng của sản phẩm nhưng còn có nhiều cách đo hơn. Về căn bản, yêu cầu phần mềm là nền tảng từ đó chất lượng được đo. Nếu sản phẩm cuối không đáp ứng yêu cầu thì nó không phải là sản phẩm có chất lượng. Mọi dự án đều phải tuân theo một qui trình được xác định hay một tập các tiêu chí hướng dẫn các hoạt động phần mềm. Nếu qui trình này không được tuân thủ, việc phát triển cũng không có chất lượng cao. Cũng có một tập các yêu cầu ‘không tường minh” thường không được nhắc tới (như tính bảo trì được, hiệu năng, tính dùng được, tính đổi qui mô được v.v.). Nếu phần mềm chỉ tuân theo yêu cầu “tường minh” của nó mà không đáp ứng yêu cầu “không tường minh” thì chất lượng phần mềm cũng không rất tốt.

Vấn đề về chất lượng phần mềm vẫn còn với việc ai là người chịu trách nhiệm cho chất phần mềm? Ai chịu trách nhiệm lập mục đích chất lượng? Không có câu trả lời đúng, chất lượng phần mềm có thể bị thoả hiệp.

Đảm bảo chất lượng phần mềm (SQA) chỉ có thể kiểm điểm dự án để đảm bảo qui trình phát triển là được tuân theo và những kiểm thử nào đó là được tiến hành đúng nhưng họ không thể chịu trách nhiệm cho chất lượng phần mềm được. Người kiểm thử phần mềm chịu trách nhiệm cho kiểm thử phần mềm để đảm bảo rằng nó đáp ứng yêu cầu và chạy tương ứng nhưng họ không chịu trách nhiệm cho chất lượng phần mềm. Thực tế người quản lí dự án và tổ phát triển, người thực hiện phần mềm chịu trách nhiệm cho chất lượng phần mềm. Người quản lí dự án phải lập ra mục đích chất lượng cho cả các yêu cầu “tường minh” như phải đáp ứng yêu cầu và ít khiếm khuyết và yêu cầu “không tường minh” như hiệu năng, tính sử dụng được và tính đổi qui mô được v.v. Để đảm bảo rằng phần mềm sẽ được thực hiện đúng, người quản lí dự án phải nhận diện một số các kiểm điểm trong toàn thể dự án và làm tài liệu chúng trong kế hoạch dự án.

Các thành viên SQA sẽ kiểm điểm dự án bằng việc tuân theo bản kế hoạch dự án do người quản lí dự án xác định. SQA sẽ gặp người quản lí dự án xấp xỉ một tuần trước phiên kiểm điểm theo lịch để thảo luận về ngày tháng thực tế, vật phẩm cần được kiểm điểm, các thành viên tổ dự án mà SQA có thể tiếp xúc để nêu câu hỏi. SQA phải chuẩn bị danh sách kiểm và kiểm điểm các vật phẩm trước ngày kiểm điểm.

Trong khi kiểm điểm, SQA phải kiểm điểm hoạt động của tổ dự án bằng việc kiểm tra vật phẩm công việc kết quả theo qui trình liên kết được xác định trong bản kế hoạch dự án và danh sách kiểm. Kết quả sẽ được ghi lại để xác định sự tuân thủ và được báo cáo cho người quản lí dự án. Người quản lí dự án phải giải quyết bất kì vấn đề không tuân thủ nào theo cách đúng hạn (trong một hay hai tuần). Vấn đề không tuân thủ không được giải quyết mau lẹ sẽ được đưa lên người quản lí SQA và người quản lí phần mềm để giải quyết tình huống này cùng người quản lí dự án. Nếu họ không thể giải quyết được vấn đề thì nó phải đưa lên giám đốc phần mềm hay người quản lí sản phẩm, người phải giải quyết tối hậu cho vấn đề để đảm bảo sản phẩm có chất lượng.

—-English version—-

Software quality

I received an email asking: “Who is responsible for the quality of the software? Should it be Software Quality Assurance because it is their job or the tester who should test for quality? How do I measure the quality of a software product?

My answer: “Defect is one way to measure the quality of the product but there are more. Basically, Software requirements are the foundation from which quality is measured. If the final product does not meet the requirements then it is not a quality product. Every project must follow a defined process or a set of criteria that guide the software activities. If the process is not followed, the development is also not a high quality. There is also a set of “implicit” requirements that often goes unmentioned (e.g. maintainability, performance, usability, scalability etc.). If software only conforms to its “explicit” requirements but fails to meet its “implicit” requirements then software quality is also not very good.

The question on software quality rests with who is responsible for the quality of software? Who is responsible for setting quality goals? Without the proper answers, the software quality could be compromised.

Software Quality Assurance (SQA) can only review the project to ensure that the development process are being followed and certain tests are being conducted properly but they can not be responsible for the quality of the software. Software testers are responsible for testing the software to ensure that it meets the requirements and runs accordingly but they are not responsible for the quality of software. Actually the project manager and the development team who implement the software are responsible for the quality of the software. The project manager must set the quality goals both for the “Explicit” requirements such as meeting requirements and less defects and “Implicit” requirements such as performance, usability and scalability etc. To ensure that the software will be implemented correctly, the project manager should identify a number of reviews throughout the project and document them in the project plan.

The SQA member will review the project by following the project plan defined by the project manager. The SQA will meet with the Project manager approximately one week prior to a scheduled review to discuss the actual date, the artifacts to be reviewed, the project team members whom SQA can contact should questions arise. SQA must prepare the checklists and review the artifacts prior to the review date.

During the review, SQA must review the project teamwork activities by checking the resulting work artifacts against the associated process defined in the project plan and the checklists. The results will be recorded to determine compliances and reported to the project manager. The project manager must resolve any noncompliant issues in a timely fashion (Within one to two weeks). Noncompliant issues that are not resolved promptly shall be escalated to the SQA manager and the Software manager to address the situation with the project manager. If they cannot solve the issue then it must be escalated to the Software Director or Product Manager who ultimately must solve the problem to ensure quality product.