Vai trò của QA trong dự án: Cảnh sát, thám tử hay là nhà tư vấn?
6 năm làm QA trong ngành IT, mình đã có cơ hội tiếp xúc với rất nhiều mô hình phát triển phần mềm: outsource, enterprise product base, startup product. Tất cả đều cho mình những trải nghiệm tuyệt vời và rất riêng về công việc làm QA. Cho đến bây giờ, khi mình nghe 1 bạn nào đó nói về công việc làm QA ở công ty họ mình thường quy nó về 1 trong 3 hình ảnh sau đây: Cảnh sát, thám tử, và nhà tư vấn ^^! Mỗi hình ảnh là 1 cách rất riêng để mo tả về người QA và công việc của họ.
1/ Cảnh sát
Khi bạn nhận công việc này, bạn và mọi người hy vọng bạn sẽ là người hết lòng phục vụ nhân dân (ở đây chủ yếu là developers), là người mà nhân dân tin tưởng để giữ gìn trật tự xã hội (đảm bảo quality của sản phẩm). Bạn có luật pháp (process) như là công cụ đắc lực đê giúp bạn hoàn thành tốt công việc.
Nhưng mà, cho dù bạn có thành tâm trở thành 1 người “cảnh sát” tốt, bạn vẫn gặp rất nhiều sự hiểu lầm và kỳ thị. Developer sợ bạn và ghét bạn, đơn giản là vì bạn bắt lỗi của họ, bạn nói rằng cái code mà họ đổ mồ hôi công sức ra làm trong nhiều ngày là thứ không đạt yêu câu, thậm chí là vứt đi. Và rồi vì sợ và ghét bạn, họ tìm cách tránh né bạn, họ tìm cách giấu những lỗi lầm họ làm ra khỏi mắt bạn. Nếu bạn tìm ra nó, họ tìm mọi cách để kỳ kèo, nói rằng nó là lỗi không đáng và thuyết phục bạn cho qua.
Nhưng bạn nhân danh công lý và pháp luật phải làm sao để không có sai phạm nào diễn ra! Quality phải được đảm bảo! Bạn tuyệt vọng cố gắng hoàn thành nhiệm vụ đó mà chẳng ai giúp đỡ! Ai cũng nghĩ rằng bạn có thể làm chuyện đó một mình, giống như tất cả sai phạm của xã hội này đều phải được cảnh sát tìm thấy và giải quyết ^^. Tệ hơn nữa, Bug xảy ra! Và người ta luôn tìm đến QA để trách móc cho chuyện này.
Lâu dần, bạn trở nên cáu gắt, nghi kỵ với tất cả mọi người. Bạn xử lý problem của dự án với tâm trạng căng thẳng vì sợ mình bị quy chụp trách nhiệm. Bạn máy móc khi xử lý và tìm lỗi, tất cả gói gọn trong “trách nhiệm”! Bạn ghét Developer! Bạn không còn bao dung với họ khi tìm ra lỗi mà bạn biết họ không cố ý nữa. Bạn luôn test với nỗinghi ngờ là họ đang giấu mình điều gì đó, và bạn luôn cố gắng “Núp lùm” để canh bắt cho được lỗi, để vạch mặt những con người cố giấu lỗi lầm của họ mà gây hại cho bạn!
2/ Thám tử
Đây từng là mẫu QA mà mình thích ^^. Bạn cũng là người phục vụ cho công lý nhưng bạn có suy luận sáng tạo, tư duy logic . Bạn có kỹ năng suy luận và tìm ra những ngóc ngách vấn đề bằng cách thu thập những chứng cứ ở hiện trường, bằng những câu hỏi thông minh với nghi phạm. Nhân chứng cũng đối xử thân thiện và cởi mở với bạn hơn là với cảnh sát …. Khi bạn phá án xong ai cũng trầm trồ thán phục! Mình từng nghĩ rằng 1 QA như vậy thì đúng là tuyệt vời!
Nhưng nếu bạn để ý kỹ, ngay cả 1 “thám tử” QA cũng mất quá nhiều thời gian để tìm hiểu một chức năng hay 1 vấn đề của dự án. Trước mắt bạn là kết quả của 1 team làm việc trong 2 tuần, đầu tắt mặt tối mỗi ngày để kịp giao cho bạn. Bạn nghĩ bạn sẽ mất bao lâu để tìm hiểu được hệ thống đó, chỉ bằng cách nhìn bề ngoài, nhìn cái kết quả? Bạn sẽ mất bao lâu để tìm thấy những bug nguy hiểm ẩn dấu bên trong?Cũng như thám tử, bạn sẽ phải đi hỏi từng nhân chứng để tái hiện lại trong đầu toàn cảnh vấn đề từ đầu đến cuối, để có thể tìm ra nguyên nhân và hung thủ. Cũng như thám tử, cũng có lúc bạn sẽ ân hận vì lúc bạn tìm ra được vấn đề thì mọi chuyện đã không cứu vãn được nữa, đã có thêm vài người nữa chết rồi!
3/ Nhà tư vấn
Thực lòng mà nói, cái title này nghe ít “ngầu” nhất. Không giống như công an, bạn không có “quyền”. Không giống như thám tử, trong mắt mọi người bạn không có “tài” hay ít ra là nếu người bạn tư vấn làm điều tốt, thường thì công chẳng thuộc về bạn.
Nhưng mà khác với 2 hình mẫu phía trước, lần đầu tiên, bạn có thể thực sự ngăn cản bug xảy ra! Bằng kiến thức và lòng kiên nhẫn của mình, bạn và developer cùng tìm hiểu về hệ thống, bạn giúp developer nhận ra những vấn đề mà họ có thể gặp phải trong thời gian sớm nhất. Developer sẽ không bao giờ buồn bực về việc họ mất 2 phút để hiểu và làm cái bạn yêu cầu, thay vì mất 2 tuần để làm ra 1 thứ gì đó rồi phải mất gần bằng ấy thời gian để đập đi làm lại, vì bạn nói rằng “Nó sai rồi!”
Sự chia sẻ trách nhiệm cũng thể hiện ở đây rõ hơn. Dù có những trường hợp developer đổ lỗi cho “nhà tư vấn”, nhưng về mặt tổng thể, họ hiểu rằng mình là người cuối cùng quyết định đoạn code này làm thế nào, nên họ cũng phải chịu trách nhiệm. Thông thường thì, nếu bạn không chỉ ra được risk, lỗi của bạn là phần lớn. Nếu họ đã biết risk mà vẫn làm sai, là lỗi của Developer phần lớn. Nhưng có gì quan trong? Dù sao thì, chúng ta lại học hỏi va tiếp tục fix bug này bằng cách dối thoại đúng không? ^^
Mix role
Cả 3 role vừa rồi đều có những điểm mạnh và điểm yếu của họ, và trong dự án không phải lúc nào 1 role cũng có hiệu quả. Nhưng việc bạn thiên về hình mẫu nào sẽ quyết định cách suy nghĩ và hành động của bạn cũng như cách mà member chia sẻ thông tin với bạn.
Vậy câu hỏi của mình là, bạn muốn bạn là ai: Cảnh sát, thám tử, hay là nhà tư vấn?
Tác Giả: Nguyễn Dương Hải