QA còn cần thiết nữa không?

 

Tester Kiểm thử, tìm lỗi Cuối quá trình

QC Đảm bảo chất lượng đầu ra Cuối quá trình

QA Đảm bảo chất lượng tổng thể từ đầu đến cuối Xuyên suốt quy trình

 

Chào cả nhà, chúc mọi người một tuần mới thật nhiều năng lượng!

Dạo gần đây, mình thấy một topic cứ liên tục xuất hiện trên các diễn đàn công nghệ và mạng xã hội:
“QA sắp tuyệt chủng rồi à?”

“Ngành test sắp hết thời.”
“AI sẽ làm hết testing trong tương lai gần.”

Nghe quen không? Mấy câu này thật ra không mới. Chủ đề này đã xoay vòng cả chục năm nay, kể cả trước khi AI trở thành "vật tế thần quốc dân".

Theo mình, câu hỏi thật sự không phải là "AI có thay thế được tester không?", mà là:
"Chúng ta đã từng thực sự hiểu ‘kiểm thử tốt’ là như thế nào chưa?"

QA vs QC – Vì sao cuộc tranh cãi này vẫn tồn tại?

Cốt lõi là cách ngành tech đối xử với nghề testing trong 10 năm qua.
Testing từng được quảng bá như một "cửa ngõ dễ dàng" để bước chân vào IT:

“Chỉ cần biết click, không cần code! Quá phù hợp cho ai muốn chuyển ngành!”

Kết quả là sinh ra cả một thế hệ "tester click chuột" – chỉ làm theo checklist, test các flow y chang nhau, nhưng không thực sự hiểu hệ thống hoặc logic nghiệp vụ đằng sau.

Và khi dev, đặc biệt là backend dev, phải làm việc với các tester như vậy, họ dễ dàng đi đến kết luận:
“Testing đơn giản mà, để tôi tự test còn nhanh hơn.”

Khi dev bị feedback bug…

Có một khía cạnh tâm lý rất hay: khi ai đó nói code mình có bug, mình cảm giác như bị chê bai. Phản ứng tự nhiên? Phòng thủ ngay!

“Người này biết gì mà chê? Mình là người viết cái code đó mà.”

Chúng ta thường xem bug như một đòn đánh vào lòng tự tôn.

Dev test cái họ hiểu – không phải cái nên test

Dev, đặc biệt bên backend, sống trong một thế giới logic sạch sẽ: input rõ ràng, output kiểm soát được. Unit test chạy ầm ầm. Tưởng thế là xong.

Nhưng mình từng thấy dự án có 100% code coverage, test case đầy đủ – mà vẫn dính bug to đùng khi user bắt đầu dùng thật sự: lỗi UX, logic sai, hoặc hệ thống không khớp khi tích hợp.

✅ All tests passed
❌ Product vẫn dở tệ

Ảo tưởng về automation

Automation đúng là tuyệt vời – nhưng chỉ khi dùng đúng cách. Nó giúp kiểm tra các trường hợp đã biết. Nhưng:

  • Không phát hiện được bug mới

  • Không hiểu người dùng nghĩ gì

  • Không tự đặt câu hỏi về requirement

  • Chỉ test đúng cái bạn bảo nó test

Và nếu assumption của dev sai, thì test case cũng sai – và AI sẽ rất vui vẻ… pass hết.

QA không chỉ là test

Sai lầm lớn nhất của ngành là nghĩ QA = testing. Trong khi QA đúng nghĩa nên bắt đầu từ giai đoạn thiết kế, đi xuyên suốt quá trình dev, cho đến tận khi release và sau đó.

QA không chỉ test, mà còn:

  • Kiểm tra trải nghiệm người dùng

  • Đảm bảo flow hợp lý

  • Đặt câu hỏi: "nếu A xảy ra thì sao?"

  • Nghĩ ra edge case mà dev có thể bỏ sót

Là QA, mình từng được tham gia các buổi planning ngay từ ngày đầu tiên. Và mình thấy rõ: chỉ cần đóng góp vài ý nhỏ ở phase thiết kế, có thể tránh được hàng tuần sửa bug sau này.

Fix bug khi còn là bản vẽ: dễ.
Fix khi đã code xong: tốn công, delay release.

Không phải ai cũng làm được mọi thứ

Đúng là dev nên quan tâm đến chất lượng. Nhưng… có phải ai cũng làm QA tốt được không?

Mình thấy giống như chuyện fullstack: lý thuyết thì dev nào cũng nên làm cả backend và frontend. Nhưng thực tế, rất ít người giỏi đều cả hai.

Chuyên môn vẫn cần thiết. Và QA cũng thế.

QA nên là một phần của team, không phải “bên ngoài”

Team hiệu quả nhất mình từng thấy là team mà QA được xem như một thành viên thực thụ:

  • Tham gia standup, review, kiến trúc, retro

  • Góp ý ngay từ requirement

  • Là người giúp cả team nghĩ tới “chất lượng”

QA không chỉ là người “kiểm tra xem đúng chưa” – mà là người định hình cách team nghĩ về chất lượng.

Không ai giỏi tất cả

Bạn không bắt dev cũng phải là designer, PM, hay chuyên gia hạ tầng đúng không?

Vậy thì cũng đừng mong dev phải là QA hoàn chỉnh.

Testing thực sự là một kỹ năng:
Hiểu hành vi người dùng, thiết kế test case tốt, phát hiện lỗ hổng trong logic – tất cả đều cần thời gian và kinh nghiệm để phát triển.

Và “click chuột kiểm tra màn hình” khác hoàn toàn với việc thiết kế chiến lược kiểm thử bài bản.

Đừng tách QA ra team – hãy tích hợp

Mô hình QA nằm ở một team ngang toàn công ty? Theo mình là công thức thất bại.

QA nên nằm trong team sản phẩm, cùng xây dựng feature, cùng chịu trách nhiệm, cùng grow.

Tương lai?

Giải pháp không phải là loại bỏ QA – mà là ngừng tuyển QA không đủ năng lực và đối xử với QA như một ngành kỹ thuật chuyên sâu.

Hãy làm việc với QA có thể:

  • Biết code

  • Hiểu kiến trúc

  • Biết tự động hoá

  • Biết tập trung vào những vấn đề chỉ con người mới thấy

Và quan trọng nhất: tham gia từ ngày đầu tiên.

Khi QA đồng hành từ lúc lên requirement, góc nhìn chất lượng được đưa vào mọi quyết định. Khi đó, chúng ta ngăn bug xảy ra từ đầu, chứ không phải phát hiện khi đã muộn.

Dev cũng cần học cách tiếp nhận feedback – vì feedback không phải để chỉ trích, mà là để sản phẩm tốt hơn.

Thị trường cho những người “click chuột” đang dần biến mất – và đó là điều tốt.
Nhưng thị trường cho những kỹ sư QA giỏi, có tư duy hệ thống, biết nhìn toàn cục?
Chắc chắn vẫn còn – kể cả khi có AI.

Sản phẩm ngày càng phức tạp, user càng khó tính. Việc có một người chuyên nghĩ đến "mọi chuyện có thể sai ở đâu" – từ ngày đầu tiên – không phải là xa xỉ. Mà là điều tối thiểu.

Biết rằng ngành mình không vận hành bằng lý trí, mà bằng trend và buzzword. Nhưng nếu CEO nào đó lấy GenAI làm cớ để bỏ vai trò QA Engineer, thì sản phẩm của họ… xác định.

Cheers!

 

Link bài viết gốc:
🔗 https://www.architecture-weekly.com/p/do-we-still-need-the-qa-role