Phân biệt QA, QC và Testing

QA là gì? QC là gì? Tester là gì? Đó sẽ là những câu hỏi quen thuộc khi bạn tìm hiểu về kiểm thử phần mềm. Và để phân biệt QA, QC và Tester là việc không hề dễ dàng kể cả những người có kinh nghiệm lâu năm. Nhưng việc phân biệt này cũng không quá quan trọng mà việc thủ sẵn kiến thức nền này cũng cho thấy sự chuyên nghiệp của bạn. Trong bài viết này, mình cũng chỉ nói theo sự hiểu biết và tìm hiểu của mình mong là sẽ giúp được 1 phần nào đó cho bạn đọc. Trước tiên hãy đi tới phần định nghĩa cơ bản của những thuật ngữ này.

• Quality Assurance (viết tắt là QA): Bao gồm các hoạt động đảm bảo việc thực hiện các quy trình, thủ tục và tiêu chuẩn trong ngữ cảnh để xác minh của phần mềm phát triển và yêu cầu dự định.
• Quality Control (viết tắt là QC): Bao gồm các hoạt động đảm bảo việc xác định của 1 phần mềm được phát triển đối với các yêu cầu tài liệu (hoặc không trong 1 số trường hợp).
• Testing: Bao gồm các hoạt động đảm bảo việc xác định các bug/error/defects trong 1 phần mềm.

Tổng quan hơn về sự khác biệt giữa QA, QC và Testing:

Định nghĩa thì là như vậy nhưng để hiểu rõ hơn thì chúng ta phải mổ xẻ vấn đề rõ ràng hơn.

1. QA tạm dịch là đảm bảo chất lượng. Giả sử có một ông chủ sản phẩm gặp đội phát triển phần mềm và nói “tôi muốn làm một sản phẩm phần mềm”. Dĩ nhiên là sẽ không có chuyện đội phát triển cứ thế mà coding rồi 6 tháng sau gặp ông chủ sản phẩm và nói “xong rồi”. Tùy tình hình thực tế và mô hình phát triển phần mềm, nhưng về cơ bản thì để cho ra đời một sản phẩm sẽ đi qua các khâu như sau: Lấy và phân tích yêu cầu > Thiết kế > Coding > QC > Testing> Giao hàng. Trong ví dụ trên, đội QC sẽ đảm nhận trách nhiệm đánh giá xem từng yêu cầu của chủ sản phẩm đã được làm đúng như yêu cầu hay chưa. Nếu mọi thứ đúng yêu cầu, đội Testing sẽ tiến hành kiểm thử và đánh giá chất lượng trước khi giao cho khách hàng. Trong nhiều trường hợp, testing và QC thường là một đội (gọi là QC hay Testing thì tùy công ty) và là chốt chặn cuối cùng trước khi sản phẩm đến tay người dùng. (Mình sẽ nói rõ hơn về QC/Testing bên dưới). Tới đây, bạn thắc mắc “Vậy QA nằm ở đâu trong ví dụ trên”…Hãy bình tĩnh, mình diễn giải thêm: Như mình đã nói ở trên, để làm ra một sản phẩm phần mềm (những sản phẩm khác cũng tương tự) thì sẽ trải qua các khâu như: Lấy và Phân tích yêu cầu > Thiết kế (phần cứng/phần mềm) > Coding > Testing > Triển khai/bảo hành bảo trì. Qui trình chung là vậy, tuy nhiên trên thực tế mỗi khâu thường có bộ phận riêng để đảm nhận và nếu như không được kiểm soát chặc chẽ thì sẽ dễ dẫn đến những rủi ro sau: Một số khâu của qui trình bị bỏ sót

• Các khâu được làm sơ sài
• Không ai đánh giá chất lượng của từng khâu
• Khâu C đổ lỗi cho khâu B, khâu B để lỗi cho khâu A, khâu A đổ lỗi cho…C.

Để tránh những vấn đề trên thì cần đến đội QA (Đảm bảo chất lượng). Đội QA sẽ định ra các qui trình cũng như theo dõi, đánh giá sát sao nhằm đảm bảo các qui trình được thực thi đầy đủ và đạt yêu cầu. Chẳng hạn như đối với giai đoạn lấy yêu cầu thì có qui trình phê chuẩn yêu cầu. Do đó, trước khi yêu cầu được chuyển sang đội thiết kế thì đội QA sẽ đánh giá xem yêu cầu đó đã được duyệt bởi khách hàng hay chưa. Tương tự, nếu khách hàng có thay đổi yêu cầu thì những thay đổi này có được ghi nhận, phê duyệt và cập nhật đầy đủ không v.v Nói cách khác, để ra được sản phẩm A thì phải qua các bước 1, 2, 3…n. Nhiệm vụ của QA là đảm bảo tất cả các bước 1,2,3…n đều phải được làm đầy đủ hay còn gọi làm đúng qui trình. Dĩ nhiên, mặc dù QA nghĩa là Đảm bảo chất lượng tuy nhiên, không có gì đảm bảo nếu bạn làm đầy đủ các bước 1,2,3 bạn sẽ ra được sản phẩm A với chất lượng “đảm bảo”. Trên thực tế, nhiều công ty có đầy đủ qui trình QA này nọ nhưng cho ra đời sản phẩm không được như mong muốn. Vì lẽ đó mà chúng ta cần thêm đội ngũ: 2. QC - Kiểm tra chất lượng Như đã nói ở trên, QA chỉ đảm bảo qui trình được thực thi đầy đủ hay chưa chứ không bao gồm việc kiểm tra xem liệu những yêu cầu của khách hàng đã được đáp ứng hay chưa. Hay nói cách khác chất lượng đã được kiểm tra chưa. Lấy lại ví dụ trên, để ra đời sản phẩm A thì sản phẩm phải đáp ứng được các yêu cầu của khách hàng như:

• Yêu cầu 1: Sản phẩm phải có giao diện giống Facebook
• Yều câu 2: Sản phẩm phải chạy được trên Android, và iOS
• Yều cầu 3: Sản phẩm phải có chức năng đăng ký user
• Yêu cầu n:….

Khi đội phát triển hoàn tất công việc “ảo diệu” của mình (hay còn gọi là “coding”) thì đội QC sẽ có nhiệm vụ kiểm tra xem những yêu cầu của khách hàng đã được đáp ứng đầy đủ hay chưa. QC sẽ kiểm tra xem liệu:

• Yêu cầu 1 có được thực hiện đúng không. Nếu đúng “Passed”, nếu sai “Failed”
• Yêu cầu 2 có được thực hiện đúng không. Nếu đúng “Passed”, nếu sai “Failed”
• Yêu cầu 3 có được thực hiện đúng không. Nếu đúng “Passed”, nếu sai “Failed”

Nếu “Passed” thì đóng gói chuyển cho khách hàng. Nếu “Failed”, báo lỗi và trả hàng về. Nếu bạn để ý thì trên một số sản phẩm trên thị trường có dán nhãn “QC Passed” là vậy. Theo ví dụ bên trên của mình về QA và QC thì dường như QC có vai trò quan trọng vì là chốt chặn cuối cùng và là đội đánh giá xem liệu những yêu cầu đã được hoành thành hay chưa – những yêu cầu cấu thành nên chất lượng của sản phẩm. Do đó, câu hỏi đặt ra là nếu không có QA nhưng có QC thì sao? Nghĩa là qui trình không được kiểm soát nhưng có đội QC để kiểm tra lỗi ở khâu cuối cùng. Về lí thuyết thì sản phẩm vẫn có thể được hoàn thành. Tuy nhiên, vì qui trình không có hoặc không được được kiểm soát, số lượng lỗi có thể tăng lên nhiều lần và việc lỗi phát hiện nhiều ở giai đoạn QC sẽ đội chi phí lên gấp nhiều lần…một điều tối kỵ trong phát triển sản phẩm. Vậy có QA mà không có QC thì sao? Lý thuyết thì bạn vẫn có thể cho ra được sản phẩm nhưng để có được cái gọi là chất lượng sản phẩm thì

1. hy vọng bạn đang sở hữu một đội phát triển siêu giỏi
2. bạn phải cầu trời phù hộ thật nhiều. Nói cách khác, làm sản phẩm mà không kiểm soát chất lượng thì tốt nhất khỏi làm cho rồi. Vậy còn vai trò của Testing (Kiểm thử) thì sao? Nó đóng vai trò gì khi mọi thứ dường như quá ổn khi đã có QA và QC. 3. Testing - Kiểm thử Cũng theo ví dụ trên, giả sử khách hàng có 100 yêu cầu và các yêu cầu này đã được kiểm tra đầy đủ bởi đội QC. Vậy thì còn vấn đề gì? Theo mình thì vẫn còn những lỗ hổng mà có thể ảnh hưởng đến chất lượng sau cùng của sản phẩm. Nên nhớ, hoạt động chính của QC chỉ là kiểm tra xem yêu cầu của khách hàng đã được đáp ứng hay chưa. Kiểu như xác nhận “yes” hoặc “no”. Rõ ràng, việc QC kiểm tra tốt tới đâu còn tùy thuộc rất nhiều vào:

1. Độ chi tiết của yêu cầu khách hàng. Các yêu cầu có được chia nhỏ hay là một cục to tướng.
2. Độ tường minh và testable của yêu cầu. Yêu cầu có thể kiểm tra được hay không hay chung chung kiểu như: “Sản phẩm phải chạy nhanh” (Nhanh là như thế nào, bao nhiêu là nhanh v.v)
3. Độ phức tạp của hệ thống. Sản phẩm càng phức tạp thì lỗi càng nhiều.

Trong thực tế thì việc QC có kiểm tra tốt tới đâu hay qui trình QA chặc chẽ như thế nào thì lỗi vẫn còn đâu đó trong sản phẩm (Bạn tìm hiểu thêm về nguồn gốc lỗi). Nhiệm vụ của Testing là tìm xem sản phẩm còn lỗi nào hay không, những lỗi mà phạm vi QC không bao phủ hết. Theo một cách dí dỏm thì công việc chính của “Kiểm thử” là lục tung hết các ngóc ngách để tìm càng nhiều lỗi càng tốt, hay còn gọi là test kiểu khám phá (exploratory testing/ad-hoc testing). Trong testing, tester thường đóng vai trò người dùng cuối để dùng sản phẩm và tìm lỗi trên sản phẩm, đánh giá những rủi ro tiềm ẩn có thể ảnh hưởng đến chất lượng sản phẩm mà các bên liên quan có thể không lường trước được hay không được nêu ra trong yêu cầu sản phẩm.

Testing vẫn hao hao giống QC nhưng vẫn có sự khác biệt. QC nhìn chung có khuynh hướng “confirm” (nghĩa là sản phẩm có làm đúng theo yêu cầu hay không, chấm hết, trong khi Testing nhìn chung có khuynh hướng khám phá để “break” , để tìm lỗi (nghĩa là tìm xem sản phẩm chạy sai như thế nào).

Cơ bản, Testing là một hoạt động thuộc QC do đó nhiều nơi kết hợp QC và Testing thành một và gọi chung là QC hay Testing team.