Có lẽ việc giải thể đội ngũ QA là một quyết định sai lầm
(davidkcaudill.medium.com)- Sau khi giảm các điểm nghẽn trong phát hành, triển khai, quản lý image và rollback bằng tối ưu hóa kiểu DevOps, điểm chậm nhất còn lại trong việc phân phối phần mềm là kiểm thử
- Ngành bắt đầu xem đội ngũ QA chứ không phải bản thân hoạt động kiểm thử là điểm nghẽn; kỳ vọng với vai trò này tăng lên nhưng đi kèm là đãi ngộ xấu đi, chuyển sang hợp đồng, offshore và cắt giảm tuyển dụng
- Việc giải thể tổ chức QA đã làm suy giảm tinh thần của những nhân sự QA giàu kinh nghiệm, và khi các lập trình viên không thể tự nhiên gánh vác công việc chất lượng thì vấn đề phần mềm chất lượng thấp càng nghiêm trọng hơn
- Quản lý chất lượng là công việc thực sự cần được đặt tên và phân công, như theo dõi lỗi, phân loại, điều tra, bảo vệ chất lượng và kiểm thử end-to-end
- Nếu không tổ chức công việc chất lượng, những người phát hiện và xử lý vấn đề sẽ không được tưởng thưởng, còn phía làm nhanh rồi làm hỏng lại liên tục được thưởng
Điểm nghẽn còn lại sau tối ưu hóa DevOps
- Những người làm DevOps đã áp dụng Theory Of Constraints để tối ưu hóa mạnh mẽ pipeline và thực hành phân phối phần mềm
- Quản lý phát hành thủ công, triển khai, quản lý image và rollback production đều trở thành đối tượng tự động hóa
- Trong quá trình từ product backlog đến lúc code tới tay khách hàng, các hoạt động giá trị thấp bị loại bỏ hoặc bị xem là điểm nghẽn cần tối ưu
- Kết quả là phần chậm nhất trong việc phân phối phần mềm còn lại là kiểm thử
- Đây cũng là lý do continuous delivery tồn tại
- Có thể làm cho kiểm thử nhanh hơn, tự động hóa và chạy song song
- Nếu hoạt động có giá trị nhất trong một thực hành lại chính là điểm nghẽn, thì có nghĩa trạng thái đó đã gần mức tối ưu
Ngành xem đội ngũ QA là điểm nghẽn
- Thói quen tối ưu hóa không chỉ áp dụng cho bản thân kiểm thử mà còn áp dụng cho cả vai trò QA
- Đã từng có xu hướng cố giảm kiểm thử tích hợp và kiểm thử end-to-end xuống thành unit test để dễ chạy song song
- Ở cấp độ nhân sự, cũng xảy ra việc đẩy những người bị cho là không biết code ra các chức năng riêng lẻ
- Ngành bắt đầu cho rằng điểm nghẽn có thể không phải kiểm thử mà là đội ngũ QA
- Kỳ vọng dành cho vai trò QA tăng lên
- Lương giảm xuống hoặc không tăng tương xứng với các vai trò khác
- Vai trò bị chuyển sang hợp đồng và offshore
- Các quyết định cắt giảm tuyển dụng QA engineer liên tiếp diễn ra
Vòng luẩn quẩn do thu hẹp vai trò QA tạo ra
- Những người ở lại trong QA ngày càng rơi vào một cấu trúc bất lợi hơn
- Những người code đủ tốt hoặc đã mệt mỏi với đãi ngộ rời khỏi QA
- Những người khác nhìn nhân sự còn ở lại QA như “những người chưa đủ để thoát ra khỏi lĩnh vực đó”
- Cũng ngày càng ít người khuyên sinh viên mới ra trường theo mảng QA
- Các công ty chia tay QA theo kiểu “chúng tôi sẽ không còn giữ chức năng này nữa, tự xử đi”
- Quá trình này là việc thô lỗ và làm nản lòng với những người đã xây dựng sự nghiệp QA
- Việc giải thể QA làm trầm trọng thêm vấn đề phần mềm chất lượng thấp, và nhiều tổ chức rơi vào tình trạng không biết ai phải làm gì cho chất lượng phần mềm
- Ngay cả những tổ chức vẫn giữ chức năng QA cũng gặp khó trong việc xác định chỗ đứng của vai trò đó trong một lĩnh vực đã bị tổn hại
“Sa thải tester” không phải lời giải
- “Một bí quyết lạ lùng” để phân phối phần mềm nhanh hơn không phải là sa thải tester
- Việc phá hỏng lĩnh vực QA gần như là một trong những sai lầm quản lý tệ nhất
- Đó là lựa chọn phá hủy thứ đã phát triển suốt nhiều thập kỷ
- Tác động có thể không được cảm nhận trong nhiều năm
- Khi tổ chức cảm nhận rõ vấn đề, có thể lại mất thêm nhiều năm nữa mới phục hồi có ý nghĩa
- Những phần vốn đã hỏng trong vai trò QA vẫn còn đó và chưa được giải quyết
- Việc phân chia công việc đã không xảy ra, và các lập trình viên không sẵn sàng tự nguyện nhận việc QA nếu không có thêm lương, sự ghi nhận hay cơ chế tưởng thưởng
- Một số người từng làm việc với các đội QA năng lực cao có thể bắt chước được một phần hành vi đó, nhưng các kỹ sư và quản lý mới hơn thì khó biết điều gì đang thiếu
- Nguyên tắc cốt lõi là đảm bảo chất lượng là công việc
- Cũng như mọi công việc khác, nếu chỉ giả định rằng “ai đó” sẽ làm thì sẽ thất bại
- Cách để nó thành công việc vô hình rồi mặc kệ cũng dẫn đến thất bại
Những công việc cần có để quản lý chất lượng phần mềm
-
Theo dõi lỗi
- Cần có cách để người dùng gửi thông tin bug và để lập trình viên ghi nhận bug
- Bug là ticket riêng lẻ mô tả điều gì sai và mức độ nghiêm trọng ra sao
- Nó không phải là mô tả chính công việc sửa lỗi
- Cần chứa lỗi, cách tái hiện và mức độ ảnh hưởng
- Phần lớn các đội phát triển mà tác giả làm việc cùng gần đây đều không theo dõi các lỗi như vậy
- Những lý do như “đằng nào cũng không sửa”, “không phải việc của tôi”, “tôi được thưởng vì tính năng mới” không thể biện minh cho kết quả chất lượng thấp
- Quản lý danh sách bug bản thân nó đã là công việc
-
Phân loại và ưu tiên
- Phân loại bug là quá trình gán bug mới vào, ưu tiên, sắp xếp, phân loại và loại bỏ trùng lặp
- Việc có tiêu chuẩn nhất quán cho mức độ nghiêm trọng cao, trung bình, thấp sẽ giúp ích cho tổ chức
- Trước đây người ta gọi việc này là “bug hygiene”
- Việc xác định đội nào nên nhận bug đó cũng là công việc
- Những tổ chức vận hành tốt có thể phản ứng tốt hơn trước áp lực bên ngoài hoặc tái cấu trúc
- Ngay cả khi có sa thải, họ vẫn quản lý sự suy giảm chất lượng theo cách dần dần
- Khi tái cơ cấu tổ chức, họ chuyển các nhóm bug nhất định cho đội mới
- Họ loại bỏ hàng loạt bug thuộc các tính năng đã ngừng
- Nói rằng có thể bỏ qua quá trình phân loại nếu đội không hề chịu áp lực bên ngoài hay tái cấu trúc nào thì gần như là một câu đùa
-
Điều tra lỗi
- Tái hiện là phần quan trọng trong quản lý bug
- Ai đó cần biến một báo cáo kiểu “tôi định mua vé xem phim nhưng không được” thành dạng “lỗi mã hóa ký tự trong luồng mua hàng đã làm hỏng quy trình với khách hàng có ký tự không phải tiếng Anh trong tên”
- Những câu hỏi như “vấn đề này đã xảy ra bao nhiêu lần” hay “ảnh hưởng tới người dùng là gì” cần người thật bỏ thời gian để trả lời
- Điều tra lỗi là việc áp dụng tính chặt chẽ kỹ thuật vào backlog bug
-
Vai trò tập trung vào chất lượng
- Việc có người trong công ty tập trung vào chất lượng của sản phẩm cuối cùng mang lại giá trị thực tế
- Chất lượng có thể là việc của mọi người, nhưng đồng thời cũng phải là việc của một ai đó
- Trong căng thẳng giữa chất lượng và tốc độ, cần có người bảo vệ chất lượng
- Với công cụ kiểm thử, chất lượng kiểm thử và kế hoạch kiểm thử, cần có một bên liên quan có quan điểm rõ ràng và muốn làm tốt nhất có thể
-
Kiểm thử end-to-end
- Một trong những vấn đề lớn và phổ biến nhất ở nhiều tổ chức kỹ thuật là quyền sở hữu hệ thống
- Sự gia tăng độ phức tạp kiến trúc diễn ra với mục tiêu giữ cho đội và ứng dụng nhỏ gọn, và đó có thể là chiến lược hợp lý
- Nhưng kết quả là tạo ra khoảng trống ở những phần quan trọng nhất của ứng dụng
- Một đội ngũ trung bình không còn thực sự sử dụng và kiểm chứng sản phẩm ở cấp độ end-to-end nữa, vì việc đó quá khó
- Cần xác nhận rằng có người trong tổ chức thực sự sử dụng sản phẩm trước khi nó được phát hành
Vấn đề tổ chức phát sinh khi phớt lờ công việc chất lượng
- Có thể sẽ có phản ứng kiểu “chúng tôi agile, lean và năng động nên không cần làm những việc này”
- Nhưng nhìn kỹ thì rất có thể các công việc đó đã diễn ra trong tổ chức, chỉ là đang được thực hiện rất tệ
- Trong các lĩnh vực khác như ô tô, ngân hàng hay bác sĩ, nghe câu “chúng tôi không làm đảm bảo chất lượng” không phải là một trải nghiệm dễ chịu
- Nếu không nhận diện và tổ chức các hoạt động chất lượng, tình hình sẽ trở nên rất tệ
- Những nhân viên có lương tâm nhất sẽ trở nên cay đắng nhất
- Họ nhìn thấy vấn đề chất lượng và thường xuyên giải quyết chúng
- Họ không nhận được sự ghi nhận tương xứng
- Khi nêu ra lo ngại về chất lượng, họ bị xem như người đang làm chậm tốc độ
- Họ thấy những người “di chuyển nhanh và phá vỡ mọi thứ” liên tục được thưởng
- Họ cảm thấy mình ở thế phải giận dữ dọn dẹp đống hỗn độn của người khác
- Trong những tổ chức như vậy, việc biết quan tâm bản thân nó trở thành bất lợi cho sự nghiệp
1 bình luận
Ý kiến trên Hacker News
Vào cuối thập niên 1970, khi mới bắt đầu sự nghiệp, tôi làm việc trong bộ phận Product Assurance, tức tổ chức QA, tại IBM Hursley Park. Tôi đã viết code và chế tạo phần cứng để kiểm thử hệ thống xử lý văn bản là sản phẩm mình phụ trách, rồi chạy các test case trên hệ thống cần kiểm thử
Những vấn đề phát hiện được chỉ được chuyển cho đội phát triển dưới dạng mô tả chung, với mục đích khiến đội phát triển sửa bug thay vì chỉ làm sao cho khớp với test case. Kết quả là nếu chúng tôi tìm thấy 3 bug ở phần xuống dòng từ có gạch nối và xóa bằng phím backspace, đội phát triển sẽ sửa 4 bug trong khu vực đó, nhưng thực tế chỉ có 2 bug là những bug chúng tôi đã tìm ra; nhờ vậy có thể ước tính thống kê số bug thực sự còn lại
Ở các tổ chức không có đội QA, chúng tôi đưa vào khái niệm sniff test. Thường đó là một phiên khoảng 1 giờ, nơi bất kỳ ai trong công ty hoặc phòng ban cũng có thể thử đập phá tính năng mới; dù tính năng được coi là đã hoàn tất, các điều kiện biên hầu như luôn bị vỡ. Chỉ cần thử các điều kiện đơn giản như nhập
""vào mọi trường rồi submit, điều hướng UI chỉ bằng bàn phím, dùng cỡ chữ lớn hoặc phóng to trình duyệt 110% là vấn đề thường lộ ra, và giờ tôi cũng chẳng còn ngạc nhiên nữaTrong quá trình phát triển các tính năng nhỏ, thường chỉ các lập trình viên tự kiểm thử, nhưng cách đó có thể khác với cách người dùng cuối thực sự sử dụng, nên việc này đặc biệt hữu ích
15–20 năm trước, tôi từng làm ở hai công ty đầu tư vào các đội QA hàng đầu, và các đội đó thật sự xứng đáng với chi phí bỏ ra. QA rất giỏi tìm ra những bug mà lập trình viên không nghĩ tới vì họ ở quá gần vấn đề, và sản phẩm cũng đạt tầm đẳng cấp thế giới
Điểm mấu chốt là ở cả hai công ty, cấp trên đều quy định rằng đội QA có quyền cuối cùng đối với việc có phát hành hay không
Các công ty ngày nay nghĩ rằng để lập trình viên dùng test tự động và quá chú ý đến code coverage thì tốt hơn, nhưng tôi đã thấy quá nhiều sản phẩm có 100% code coverage mà khách quan là không hoạt động. Điều đó không có nghĩa test tự động là xấu, mà vấn đề là loại bỏ tester QA con người
Đội QE ở công ty gần đây tôi làm đã viết một lượng code khổng lồ để thực hiện kiểm thử, số dòng code còn nhiều hơn cả module được kiểm thử/chứng nhận
Dù vậy, tôi từng nghe một quản lý kiểm thử ở một công ty phần mềm lớn ai cũng biết tuyên bố rằng vì đã đạt 100% coverage nên đội test coi như xong việc
Ngay cả khi có quyền đó, ở những công ty mà phần lớn QA là hợp đồng lương thấp và chỉ làm những gì được giao, mọi thứ vẫn hỗn loạn
assertTrue(true). Lúc nào cũng xanh và coverage là 100%Cũng chính những người đó thường hỏi vì sao phải viết test trong khi họ có thể làm tính năng mới, rồi sau đó một senior QA xuất hiện và phá vỡ tất cả. Có lần người đó phát hiện rằng nếu bấm F5 50 lần trong 1 phút, backend sẽ quay vòng các request tới cơ sở dữ liệu rồi chết vì
outOfMemoryHọ tự hào khi tìm ra các điều kiện biên vượt xa spec, và giá trị đó là quá đủ. Giống như một hệ thống kiểu tốt đem lại sự tự tin khi thay đổi, QA giỏi cũng đem lại sự tự tin cho lập trình viên. Đặc biệt với các ứng dụng có nhiều tương tác như game, chỉ unit test và integration test khó có thể bao phủ hết không gian tham số
Câu nói rằng những nhân viên có lương tâm nhất trong tổ chức lại là những người cay đắng nhất là một sự thật nhức nhối. Họ nhìn thấy vấn đề chất lượng, thường tự tay giải quyết, nhưng không được ghi nhận; khi nêu lo ngại về chất lượng thì bị xem như người muốn làm chậm tiến độ
Phe “move fast and break things” thì liên tục được thưởng, còn những người quan tâm phải dọn dẹp hậu quả phía sau và tích tụ bực tức. Với họ, bản thân việc quan tâm giống như một thiệt hại lớn cho sự nghiệp, vì thực tế đúng là như vậy
Các tổ chức DBA và hạ tầng cũng ở cùng hoàn cảnh với QA, và tôi hy vọng chẳng bao lâu nữa con lắc sẽ quay lại
Phép tính của họ là: nếu người dùng có thể báo bug và nhận bản cập nhật qua Internet thì chẳng cần tốn nhiều tiền và thời gian. Kể từ khi game và phần mềm chuyển từ phương tiện vật lý sang chủ yếu tải xuống, việc vá lỗi có vẻ rẻ hơn. Tất nhiên điều đó dẫn tới các vấn đề bảo mật khủng khiếp và trải nghiệm người dùng tệ, nhưng miễn là người ở trên tối đa hóa lợi nhuận thì họ không mấy bận tâm
Nếu bạn đang xây dựng một sản phẩm POC SaaS, bạn không cần chất lượng ở mức vi điều khiển hàng không điện tử. Mọi đánh đổi đều có rủi ro và chi phí, và kỹ sư giỏi phải biết sự khác biệt đó
Vấn đề cốt lõi của đội QA cũng giống như đội IT hay bộ phận quản lý. Nếu làm tốt, họ trông như chẳng làm gì cả
Vì vậy họ thường rơi vào tình huống phải “biện minh” cho công việc của mình, và điều này thường đến từ việc phụ thuộc quá mức vào các chỉ số. Như định luật Goodhart, họ không hiểu chỉ số đó là đại diện cho điều gì, và mục đích thực sự của công việc là gì
Đội QA tệ thì soi mói quá mức để có vẻ như có chuyện để nói, còn đội QA tốt thì vừa xác nhận chất lượng vừa huấn luyện nhân viên tạo ra chất lượng cao hơn
Tôi cảm thấy nhìn chung nhân sự đang thiếu đào tạo. Bài “phân vị 95 cũng không ghê gớm đến thế” từng lên trang nhất gần đây (https://news.ycombinator.com/item?id=38560345) cũng nói rằng vì phần lớn người thực hành không chủ động luyện tập hay nhận phản hồi, nên trong bất kỳ lĩnh vực nào, việc lọt vào top 5% là khá dễ
Tôi nghĩ doanh nghiệp nên liên tục luyện tập như đội chuyên nghiệp, chứ không phải đội thể thao nghiệp dư. Tuyển dụng cũng nên nhìn vào “liệu có thể biến người này thành người đạt thành tích cao nhất không” hơn là “người này đã là người đạt thành tích cao nhất chưa”. Việc từng thành công trong môi trường trước đó có thể kém ý nghĩa hơn ta tưởng nếu môi trường mới khác biệt lớn
Trong mỗi bài viết về chất lượng phần mềm đều có nhiều bình luận mặc nhiên xem sự thờ ơ rộng khắp của kỹ sư là bình thường. Tùy từng tình huống, nhưng mọi người có vẻ khá ổn với việc cứ thuận theo điểm tối ưu cục bộ của tổ chức mình và từ bỏ quyền chủ động. Không hoàn toàn là lỗi của họ, nhưng cũng không phải vô can
Nếu loại bỏ các tác vụ lặp lại bằng tự động hóa thì vị trí của người đó sẽ biến mất, nhưng nếu làm đúng, quản lý lại nghĩ họ ngồi cả ngày chẳng làm gì, nên động lực để làm đúng rất nhỏ
Vì không bị đánh giá theo số lượng bug tìm được, cũng không có áp lực phải cố moi ra những bug ngớ ngẩn để tăng con số
Đào tạo tốt cần có đủ người giỏi và có tầm rộng trong nhóm kỹ thuật. Không cần biết hết mọi công nghệ mới nhất, nhưng phải có khả năng phát hiện và chỉ ra những điều nhảm nhí. FAANG cũng không ngoại lệ
Như bài này cũng nói, cốt lõi thật sự là QA hầu như luôn bị các đơn vị kinh doanh và quản lý cấp cao nhìn như bộ phận chi phí
Tôi có giả thuyết rằng tốt nhất là không nên làm việc trong những tổ chức bị nhìn như bộ phận chi phí. Thưởng, sự công nhận và tôn trọng luôn đi về phía kiếm ra tiền; bộ phận chi phí thì phải gánh nhiều việc hơn với ít người hơn, bị đổ lỗi khi thất bại, và bị cắt đầu tiên khi công ty thu hẹp. IT cũng vậy
Vì vòng luẩn quẩn này, sự nghiệp QA chắc chắn luôn khó hơn so với việc trở thành developer với kỹ năng tương tự. Người xuất sắc sẽ kiệt sức và thoát ra càng sớm càng tốt, rồi cấu trúc đó tự củng cố chính nó
Khả năng tiếp cận, khả năng quan sát, logging tốt, cải thiện hạ tầng test, điều chỉnh CI/CD, độ ổn định, linting tốt hơn và các vấn đề từ analyzer đều quan trọng, nhưng bạn được thưởng khi phát hành tính năng nhanh
Năm nay tôi đã dành quá nhiều thời gian cho những việc đó vì nghĩ rằng đội và app cần, và giờ lo về đánh giá hiệu suất cuối năm. Giờ tôi hiểu vì sao những người khác tránh các việc này, và năm sau tôi định tập trung vào việc phát hành những tính năng dễ thấy hơn. Xin lỗi vì bug của app, nhưng tôi cần công việc để trả khoản vay mua nhà
Một số tổ chức thật sự coi trọng giá trị mà QA/QC mang lại. Tôi thấy điều này rõ hơn trong sản xuất so với phần mềm, có lẽ vì phần mềm vốn trừu tượng hơn và khó theo dõi lãng phí hơn
QA thật sự giỏi không phải là người tìm đường dễ, mà là người tin vào sứ mệnh của QA. Rốt cuộc, việc tổ chức và cá nhân có thật lòng tiếp nhận tinh thần QA hay không mới tạo ra giá trị, và có nhiều nơi chỉ làm cho có hình thức
Nhưng tôi không bận tâm. Tôi thích việc làm cho mọi thứ tốt hơn, vững chắc hơn, và thấy thanh thản. Việc phá hỏng thì để cho những người cay nghiệt làm
Thưởng và những thứ tương tự đi về nhóm khác cũng không sao. Làm nghề kỹ thuật tôi đã được trả đủ tốt, và khá nhiều vai trò kiếm tiền đó có lẽ sẽ khiến tôi thật sự khổ sở, dù tôi có thực sự làm tốt đi nữa
Chất lượng phần mềm, khả năng bảo trì mã và thiết kế tốt chỉ quan trọng khi bạn có kế hoạch làm lâu dài ở công ty đó
Nếu định ở vài năm rồi chuyển sang công ty tiếp theo, con đường tối ưu là làm những việc dễ thấy để thăng tiến nhanh, rồi dùng hồ sơ đó để chuyển sang việc lương cao hơn. Vài năm sau dự án đó hỏng hoặc không thể bảo trì nữa thì cũng không sao, vì lúc đó bạn đã không còn ở đó
Startup cũng vận hành theo cách tương tự. Growth mindset được khắc khắp nơi chính là mô hình này. Dù sản phẩm 5 năm sau không thể bảo trì, lúc đó họ có thể đã exit và chốt tiền rồi
Tôi không hẳn phê phán chính xác những người như vậy. Chính các công ty sử dụng các thông lệ đó, và mọi người chỉ chơi theo luật ấy. Tôi không thích và thật sự ghét, nhưng tôi hiểu
Phần thú vị là cảnh các quản lý và lãnh đạo than phiền về tỷ lệ nghỉ việc, thiếu gắn bó với công ty, và quiet quitting. Giống như họ tự nếm thứ thuốc độc do chính mình tạo ra
Nếu 5 năm sau họ vẫn sống sót cùng nợ kỹ thuật, thì với nhiều startup đó lại là một vấn đề tốt. Dù sao cũng có nghĩa là họ đã trụ được 5 năm
Các kỹ sư QA thường cũng debug rất giỏi. Họ đụng đến pipeline, source, thư mục test, và xử lý gần như mọi khía cạnh của phát triển và triển khai ứng dụng
Khi còn là QA lead, tôi thường thấy các kỹ sư phần mềm ngày nào cũng than phiền trên Slack trong khi không chịu đọc thông báo lỗi của pipeline. Khi tối ưu pipeline cũng vậy, họ phớt lờ vấn đề gốc rễ, rồi coi các triệu chứng xuất phát từ vấn đề đó như những thứ không thể hiểu nổi, như có phép thuật, và mất nhiều ngày đoán mò để xử lý
Sự coi thường kỹ sư QA trong bài viết này không phải là phóng đại. Ngay cả những công ty có tổ chức QA cũng thường không có quy trình phỏng vấn nghiêm ngặt như tổ chức engineering, nên kỹ sư QA bị đánh giá thấp
Những SWE tôn trọng QA chỉ là những người từng làm QA. Sự coi thường lan rộng đến mức cuối cùng tôi quay lại tổ chức engineering, và đã cố thay đổi bằng thâm niên ở vai trò principal engineer hoặc bằng vai trò quản lý, nhưng thất bại. Engineering không nhìn vượt qua được sự kiêu ngạo của chính mình, còn leadership cũng không giúp
CTO mới của công ty tôi làm trước khi bị sa thải nói rằng có thể loại bỏ nhu cầu QA bằng tự động hóa, nhưng không đưa ra nổi một ví dụ nào về ý đó nghĩa là gì. Mức độ tôn trọng từ cấp trên dành cho việc tạo ra phần mềm tốt chỉ đến vậy
Microsoft có vẻ là ví dụ nổi bật nhất của vấn đề này. Sau khi bỏ đội QA, số bug trong các bản cập nhật Windows và sản phẩm cloud tăng lên rõ rệt
Tôi dùng rất nhiều phần mềm và dịch vụ của Microsoft trong công việc, và mong rằng họ phải trả giá theo cách nào đó cho sự suy giảm chất lượng này
Có thể chỉ là trải nghiệm cá nhân, nhưng tôi chưa từng thấy đội QA nào thực sự viết test cho engineering
Các đội QA tôi từng gặp thì viết test plan rồi chạy thủ công, hoặc hiếm hơn là chạy bằng test trình duyệt/thiết bị tự động. Những test này cũng có giá trị, nhưng tôi cho là kém hơn unit test hoặc integration test
Trong mô hình này, trên thực tế chính đội engineering trở thành đội QA, còn đội QA riêng biệt thường tạo ra tiếng ồn bằng cách tìm những thứ không phải bug như thể chúng là bug, gây ra chi phí lớn hơn giá trị họ cung cấp
Tôi muốn học mô hình đội QA vận hành tốt. Manual test rất tuyệt, nhưng theo trải nghiệm của tôi thì có giới hạn. Tôi không có ý hạ thấp người làm QA, chỉ đang chia sẻ trải nghiệm của mình
Họ hiểu toàn diện hệ thống mà người dùng nhìn thấy hơn cả PM, sales, và phần lớn đội dev, và có thể nói chính xác điều gì sẽ xảy ra khi bấm một nút nào đó. QA tệ đúng là nguồn gây nhiễu, nhưng dev tệ, sysadmin tệ, support tuyến 1/2 tệ cũng vậy
Khi đang bị như vậy thì thật sự rất bực, nhưng chất lượng kết quả tốt hơn nhiều
QA ngày trước thường không viết test mà test code thủ công, thử đủ mọi hành vi kỳ quặc mà ta mong người dùng đừng làm. Họ tìm ra các vấn đề và bug khó bắt được một cách phổ quát bằng test
Giờ thì chúng ta đẩy QA sang cho người dùng. Khi làm việc với các developer trẻ, tôi cảm thấy chính khái niệm QA ngày càng trở nên xa lạ. Khi bug lọt ra production và tôi hỏi “lúc thử trên local thì nó thế nào?”, tôi thường nhận được ánh mắt kỳ lạ. Kiểu như type checker đã pass rồi thì sao lại không release
Hiệu suất lập trình viên ngày nay được đo bằng số PR mỗi phút, nên việc đưa bug vào không phải là vấn đề mà còn là điều tốt. Nếu ai đó phát hiện trong production, vài ngày sau ta lại có thể mở thêm một PR để sửa. Nếu có QA thì dòng chảy này đã bị phá hỏng
Mỗi công ty triển khai chức năng QA theo một cách khác nhau. Có nơi giao cho khách hàng, có nơi giao cho developer, customer support, manual QA, hoặc SDET. Cuối cùng phụ thuộc vào việc leadership coi trọng chất lượng đến đâu và nhìn nhận QA như thế nào
Nếu có đội QA, tôi cho rằng khả năng thành công cao nhất là khi họ tham gia từ giai đoạn đầu của quy trình. Một đội QA tốt phải tìm bug trước khi code được viết. Tham gia càng muộn thì bug càng được phát hiện muộn, và họ càng bị squeezed nặng hơn giữa “code complete” và release. Đội QA cần có năng lực tự động hóa để dành thời gian cho các test case mới thay vì lặp lại manual test
Bài viết này chạm khá đau. QA đôi khi bị đối xử như công dân hạng hai, bị loại khỏi các cuộc thảo luận nơi họ có thể có được ngữ cảnh để làm việc đúng cách. Khi những người giỏi rời sang development hoặc product management thì tình hình càng tệ hơn, và vòng xoáy đi xuống là có thật
Điều đang được mô tả ở đây là vấn đề leadership, không phải vấn đề QA có hữu ích hay không
QA dành thời gian tạo hạ tầng test và test plan mà không được lồng ghép từ sớm, rồi đến cuối nhận một cục code cùng lịch phê duyệt 48 giờ và phải sign-off dưới áp lực cực lớn
Nhưng đôi khi cũng có thể gặp những tổ chức QA hiểu sâu problem domain và thực sự dẫn dắt development. Họ đi song song với development từ đầu đến cuối, không chỉ nâng chất lượng mà còn tiết kiệm thời gian cho tất cả mọi người
Khi xây dựng FoundationDB, họ tập trung vào chất lượng và kiểm thử đến mức gần như ám ảnh. Vì vậy, họ thậm chí đã tạo ra một ngôn ngữ tên là Flow, cho phép mô phỏng một cụm FDB ở quy mô tùy ý một cách tất định, áp các điều kiện cực đoan, rồi đánh dấu các vi phạm thuộc tính của hệ thống và tái hiện hoàn hảo lần chạy kiểm thử đã gây ra vi phạm đó
Mỗi đêm có hàng chục nghìn lần chạy kiểm thử, đến mức nếu không có mã mới thì về cơ bản tất cả đều bật đèn xanh. Những bài test báo đỏ hầu như luôn là do phần mã vừa được thêm gần đây, nên có thể dễ dàng xác định và sửa
Nhờ vậy, đội ngũ có thể phát triển với sự tin tưởng rằng các bug mới đưa vào sẽ được phát hiện nhanh chóng; điều đó dẫn tới tốc độ cho phép họ tự tin đảm nhận những dự án táo bạo như viết lại hệ thống xử lý giao dịch sau khi đã phát hành. Kết quả là họ cũng đạt được mức tăng tốc 10 lần
Rốt cuộc, sự tập trung vào chất lượng đã dẫn đến tốc độ, và hai điều này hoàn toàn không mâu thuẫn với nhau. Tôi không nghĩ đây là một hiện tượng cá biệt, và vì thế nó đã dẫn tới một dự án mới, nhưng đó là câu chuyện cho lần sau