Thỉnh thoảng, mọi người lẫn lộn SQA với Kiểm thử và coi SQA như tổ chức kiểm thử, điều này là KHÔNG đúng. Chuẩn IEEE 12207-2008 nói rằng “Mục đích của Đảm bào chất lượng phần mềm (SQA) là cung cấp đảm bảo rằng sản phẩm công việc và qui trình tuân thủ theo kế hoạch đã xác định trước.” Chuẩn này cũng nói rằng qui trình SQA phải được phối hợp với các hoạt động dự án có liên quan như qui trình trắc nghiệm, kiểm nghiệm, kiểm điểm và kiểm định để nhận diện việc không tuân thủ. Nó ngụ ý rằng SQA đảm bảo rằng sản phẩm và qui trình tuân thủ theo kế hoạch dự án và chuẩn của tổ chức. Chuẩn này yêu cầu SQA đảm bảo rằng những qui trình này được làm tài liệu, được tuân theo và nhất quán với chính sách của công ti. Sản phẩm hoàn toàn thoả mãn các yêu cầu và được chấp nhận cho người dùng. Chẳng hạn: SQA kiểm điểm yêu cầu, kiến trúc và thiết kế dự án để đảm bảo rằng chúng được làm tài liệu tương ứng và các thành viên tổ dự án tuân theo qui trình của tổ chức để phát triển phần mềm. SQC và Kiểm thử thực hiện chương trình phần mềm để chắc rằng nó làm việc và đáp ứng yêu cầu.
Qui trình SQA có thể được mô tả như sau:
Xác định kế hoạch đảm bảo chất lượng để nhận diện điều cần làm đảm bảo chất lượng.
Hỗ trợ người quản lí dự án xác định các chuẩn, hướng dẫn và các kĩ thuật khác cho dự án
Đảm bảo kiểm soát chất lượng một cách hệ thống cho các qui trình và sản phẩm như kiểm điểm, giám định, kiểm định cũng như quản lí/kiểm soát cấu hình, đưa ra sản xuất, kiểm soát dự án, hợp đồng và quản lí nhà cung cấp, kiểm soát tài liệu, bảo trì, sao lưu và phục hồi, và an ninh.
Duy trì bản ghi chất lượng để theo dõi vấn đề.
Phân tích và báo cáo về vấn đề chất lượng cho cấp quản lí.
Duy trì và cải tiến chất lượng sản phẩm.
Bởi vì SQA bao giờ cũng kiểm tra về bất kì sự không tuân thủ nào và một số người phát triển không thích bị giám sát, thường có xung đột giữa họ. Một số người phát triển coi SQA giống như “cảnh sát” và không bày tỏ mấy kính trọng với công việc của họ. Điều này hầu hết là do thiếu đào tạo về chất lượng cho người phát triển và sự kiện là nhiều SQA KHÔNG được đào tạo tốt và KHÔNG có đủ kinh nghiệm đáng đòi hỏi kính trọng. Tôi đã thấy nhiều người làm việc như SQA chỉ có kinh nghiệm phần mềm hạn chế. Nhiều người quản lí KHÔNG coi SQA là quan trọng và thường phân công người mới, người không có nhiều kinh nghiệm vào việc này. Một số người quản lí thậm chí còn bảo tôi: “Nếu họ KHÔNG thể phát triển phần mềm tốt, chúng tôi xếp họ làm việc như SQA”. Đây là sai lầm rất lớn và đó là lí do tại sao nhiều SQA không thành công mấy trong việc của họ. Đó là lí do tại sao nhiều phần mềm có khiếm khuyết.
SQA thành công nhất thường bắt nguồn từ nhóm lãnh đạo kĩ thuật, chính là người phát triển có kinh nghiệm. Những người này thường lãnh đạo các dự án, giải quyết các vấn đề kĩ thuật, và cung cấp đào tạo cho người phát triển mới. Họ biết rõ về phát triển phần mềm, biết rõ qui trình phát triển, và họ được người phát triển kính trọng. Những người này rất có tính dự ứng trong hướng dẫn, đào tạo và xác định qui trình cho nên đề bạt họ vào SQA là tiến bộ tự nhiên trong nghề nghiệp của họ. Nhiều người quản lí biện minh rằng vì họ là chủ yếu kĩ thuật, họ được cần để làm việc trong dự án nhưng luận cứ của tôi là mọi dự án đều cần ai đó để đảm bảo chất lượng và đầu tư vào SQA là bản chất cho thành công của dự án.
Theo kinh nghiệm của tôi, thay vì kiểm tra sự không tuân thủ và đòi hỏi hành động sửa chữa, người SQA dự ứng phải thiết lập môi trường thúc đẩy chất lượng và bao quát vòng đời đầy đủ của việc phát triển từ quan niệm tới hoàn thành. SQA phải trao đổi tầm quan trọng của tuân thủ qui trình để tạo ra sản phẩm chất lượng và đào tạo người phát triển tuân theo qui trình tương ứng. Thay vì đơn thuần xác nhận tuân thủ theo kế hoạch, QA phải đảm bảo rằng người phát triển hiểu mọi bước cần thiết để tạo ra sản phẩm chính xác, đầy đủ và chất lượng cao. Về cơ bản người SQA dự ứng là người thầy, người thầy kèm, huấn luyện viên, và người hướng dẫn để giúp cho người phát triển chuyển giao chất lượng sản phẩm và liên tục cải tiến cách họ phát triển phần mềm.
Some of you ask me about the difference between Software Quality Assurance (SQA), Software Quality Control (SQC) and Software Testing. Basically, SQA focuses on issues related to the process that create the software product. SQC focuses on the issues related to the software products. Testing is the method of SQC to make sure that the product works as expected.
Sometime, people confuse SQA with Test and consider SQA as a testing organization which is NOT correct. The IEEE Standard. 12207-2008 stated that “The purpose of the Software Quality Assurance (SQA) is to provide assurance that work products and processes are complying with predefined plans.” The standard also stated that the SQA process should be coordinated with the related project activities such as verification, validation, review and audit processes to identify non-conformances. It means that SQA assures that products and processes comply with the project plans and organization’s standard. The standard requires SQA to assures that these processes are documented, followed and consistent with the company’s policies. The products are fully satisfy the requirements and are acceptable to the users. For example: SQA reviews project requirements, architect and designs to ensure that they are documented accordingly and project team members are following the organization’s process to develop software. SQC and Testing executes the software programs to make sure that it works and meets requirements.
The SQA process can be described as follows:
Because SQA always checks for any non-compliance and some developers do not like to be monitored, there are often conflicts between them. Some developers consider SQA is like a “police” and do not show much respect to their works. This is mostly caused by lack of quality training for developers and the fact that many SQA are also NOT well trained and do NOT have enough experiences to demand respect. I have seen many people who work as SQA only have limited software experiences. Many managers do NOT consider SQA as important and often assigned new people, who do not have a lot of experience into this jobs. Some managers even told me: “If they can NOT develop software well, we put them to work as SQA”. This is a very big mistake and that is why many SQA are not so successful in their jobs. That is why so many software have defects.
The most successful SQA usually come from Technical Lead group, who are experienced developers. These people often lead projects, solve technical problems, and provide training to new developers. They know software development well, know development process well, and they are respected by developers. These people are very proactive in guiding, training, and defining the process so by promoting them into SQA is a natural progressing in their career. Many managers argue that since they are very technical, they are needed to work in project but my argument is every project need someone to ensure quality and investment in SQA is essential for the successful of the project.
In my experience, instead of checking for non-compliance and demand corrective actions, the proactive SQA must establish an environment that promotes quality and covers the full life cycle of development from conception through completion. The SQA must communicate the important of process compliance to create quality products and train developers to follow the process accordingly. Rather than merely confirming compliance to plans, QA must ensure that developers understand all necessary steps to create an accurate, complete, and high quality products. Basically a proactive SQA is a teacher, a mentor, a coach, and a guide to help developers to deliver quality products and continually improve the way they develop software.
