Việc loại bỏ đội QA có thể thực sự là một quyết định tồi
- Phần chậm nhất của việc triển khai phần mềm là kiểm thử. Lý do tồn tại của triển khai liên tục chính là vì kiểm thử, nên việc đây trở thành điểm nghẽn được xem là trạng thái đã được tối ưu hóa.
- Thói quen và hành vi tối ưu hóa đã dẫn đến xu hướng trong ngành xem đội QA là điểm nghẽn và tìm cách loại bỏ nó. Điều này làm giảm sự tôn trọng đối với vai trò QA và dẫn đến vấn đề không thể tạo ra phần mềm chất lượng tốt.
- Các lập trình viên chưa thực sự nắm rõ việc quản lý chất lượng phần mềm. Nhiều tổ chức không biết trách nhiệm về chất lượng phần mềm thuộc về ai, và ngay cả những nơi vẫn duy trì chức năng QA cũng gặp khó khăn trong việc xác định vị trí cho vai trò này.
Cần làm gì để quản lý chất lượng trong thực hành phần mềm
- Theo dõi lỗi: Cần có cách để người dùng cung cấp thông tin về bug và để lập trình viên ghi nhận bug.
- Phân loại: Triage bug là quá trình quản lý việc phân công, ưu tiên, sắp xếp, phân loại, loại bỏ trùng lặp, v.v.
- Điều tra lỗi: Tái hiện bug là một phần quan trọng của việc quản lý bug, đòi hỏi nỗ lực kỹ thuật để xác định và giải quyết vấn đề thực tế.
- Tập trung: Công ty cần có những người tập trung vào chất lượng, và cần có người bảo vệ chất lượng để cân bằng giữa chất lượng và tốc độ.
- Kiểm thử end-to-end: Vấn đề về quyền sở hữu hệ thống phát sinh do kiến trúc phức tạp, và điều này dẫn đến sự thiếu vắng kiểm thử sử dụng thực tế trước khi phát hành sản phẩm.
Ý kiến của GN⁺
- Việc loại bỏ đội QA là một sai lầm trong quản lý, về lâu dài có thể ảnh hưởng nghiêm trọng đến chất lượng phần mềm.
- Trong quá trình phát triển phần mềm, đảm bảo chất lượng là công việc quan trọng, và thái độ phớt lờ hoặc xem nhẹ điều này cuối cùng có thể dẫn đến thất bại.
- Bài viết này gợi mở một góc nhìn thú vị khi tái nhấn mạnh tầm quan trọng của QA trong ngành phần mềm, cũng như nhu cầu về nhận thức đúng đắn đối với quản lý chất lượng và sự phân chia vai trò phù hợp trong tổ chức.
1 bình luận
Ý kiến trên Hacker News
Vào cuối những năm 1970 tại IBM, có người phụ trách công việc đảm bảo sản phẩm và đã viết mã kiểm thử cũng như lắp dựng phần cứng cho sản phẩm mình phụ trách (hệ thống xử lý văn bản). Họ không công khai chi tiết các test case cho đội phát triển mà chỉ chuyển các vấn đề chung để thúc đẩy việc sửa lỗi. Bằng cách này, có thể tính toán thống kê ước lượng số lỗi còn lại thông qua sự không khớp giữa các lỗi được phát hiện và các lỗi mà đội phát triển đã sửa.
Ở những tổ chức không có đội QA, người ta áp dụng khái niệm gọi là "sniff test". Đây là một phiên mà mọi người trong công ty cùng tập trung kiểm thử tính năng mới trong thời gian ngắn, thường là 1 giờ, và kết quả là tạo ra rất nhiều ticket lỗi. Những bài kiểm tra đơn giản thường gây ra vấn đề, nhưng giờ điều đó không còn đáng ngạc nhiên nữa.
Hai công ty tôi từng làm việc cách đây 15-20 năm đều đầu tư vào các đội QA hàng đầu, và họ thể hiện khả năng xuất sắc trong việc tìm ra những lỗi mà lập trình viên không nghĩ tới. Đội QA có quyền quyết định cuối cùng về việc sản phẩm có được phát hành hay không. Hiện nay nhiều công ty cho rằng để lập trình viên viết automated test và dành nhiều thời gian cho code coverage là cách tốt hơn, nhưng tôi đã thấy rất nhiều sản phẩm thực tế không hoạt động. Không phải automated test là tệ, mà vấn đề ở đây là việc loại bỏ tester QA con người.
Những nhân viên có lương tâm nhất trong tổ chức thường cũng là những người bất mãn nhất. Họ nhận ra các vấn đề về chất lượng và cố gắng giải quyết nhưng không được ghi nhận, và khi lên tiếng về chất lượng thì bị xem là người muốn làm mọi thứ chậm lại. Trong khi những người "di chuyển nhanh và phá vỡ mọi thứ" vẫn liên tục được tưởng thưởng, họ tức giận vì phải dọn dẹp hậu quả và cảm thấy rằng việc thực sự quan tâm trong tổ chức có thể gây hại cho sự nghiệp của mình.
QA có xu hướng bị bộ phận kinh doanh và lãnh đạo cấp cao xem là một "cost center". Có giả thuyết cho rằng nên tránh làm việc ở những bộ phận bị coi là "cost center", vì phần thưởng và sự công nhận luôn thuộc về những người tạo ra doanh thu. QA phải làm nhiều việc hơn với ít người hơn, bị đổ lỗi cho thất bại, và có thể là nơi bị sa thải đầu tiên khi doanh nghiệp cần tinh gọn.
Các kỹ sư QA có năng lực debug rất xuất sắc. Họ làm việc trên mọi khía cạnh của ứng dụng, từ pipeline, source code đến thư mục kiểm thử, trong khi các kỹ sư phần mềm thường dành cả ngày để không đọc thông báo lỗi của pipeline, bỏ qua vấn đề gốc và đoán mò cách giải quyết. Sự xem thường dành cho kỹ sư QA không hề bị bài viết phóng đại, và vì tổ chức QA không trải qua quy trình phỏng vấn nghiêm ngặt như tổ chức kỹ thuật, các kỹ sư QA bị xem là kém hơn.
Theo kinh nghiệm cá nhân, tôi chưa từng gặp một đội QA nào thực sự viết test cho engineering. Phần lớn các đội QA chỉ thực thi "test plan" một cách thủ công, hoặc hiếm hơn là thông qua kiểm thử trình duyệt/thiết bị được tự động hóa. Những kiểu kiểm thử này có giá trị, nhưng không bằng "unit test" hay "integration test". Trong mô hình này, chính đội engineering mới thực sự làm vai trò QA hơn là đội QA thực thụ, còn đội QA thì thường làm giảm giá trị của mình khi báo những thứ không phải lỗi thành lỗi.
Sau khi loại bỏ đội QA, Microsoft đã chứng kiến nhiều lỗi hơn xuất hiện trong Windows và các sản phẩm cloud.