🍀 Nhìn qua tiêu đề, có thể bạn cho rằng mối quan hệ giữa Tester [QA hay QC nói chung] và lập trình viên [Developer – hay gọi tắt là Dev] thường sẽ rất tệ, hiếm khi “cơm lành, canh ngọt” trong công việc. Nhiều người cho rằng mối quan hệ giữa Dev và Tester là “phức tạp”, “khó hòa hợp”, hay thậm chí “kẻ thù hai bên chiến tuyến”, v.v… Có nhiều nguyên nhân dẫn đến những suy nghĩ này làm cho nhiều quản lý dự án hay Team Lead [nhóm trưởng] phải đau đầu khi xử lý những xung đột không đáng có này. Vậy, làm cách nào để Tester [nhất là fresher tester] có thể “sống hòa thuận” với Dev? Bài viết này giúp bạn tránh những xung đột thường gặp và Tester có thể phối hợp nhịp nhàng với Dev trong công việc giúp tăng chất lượng phần mềm làm hài lòng khách hàng.
Công việc thường ngày của Tester và Developer
Trước tiên, phải lật lại vấn đề một chút. Trách nhiệm, nhiệm vụ, và mục tiêu công việc của hai bên khác nhau dẫn đến cách tư duy và hành động cũng khác nhau, cụ thể khi nhận yêu cầu từ khách hàng thì Dev, vì là người xây dựng và phát triển sản phẩm, nên họ sẽ tập trung suy nghĩ giải pháp, cách thức để xây dựng [lập trình] yêu cầu này một cách nhanh nhất và hiệu quả nhất. Trong khi đó, Tester, là người kiểm tra và tìm kiếm lỗi ở sản phẩm do Dev lập trình nên, và giúp phát hiện sớm các rủi ro nhằm ngăn ngừa và giảm thiểu lỗi xảy ra trong quá trình sử dụng thực tế, hoặc giúp nâng cao trải nghiệm người dùng cho sản phẩm.
Vì thế, trong quá trình làm việc, Dev là người “khó nhọc” và “khổ tâm” để phát triển ra sản phẩm, họ xem nó như đứa con tinh thần, và đôi khi chỉ tập trung vào giải pháp và quên mất đi rằng giải pháp này sẽ “không hoạt động” trong tình huống nào. Hay nói cách khác, Dev thường không nghĩ đến những trường hợp mà giải pháp của họ không chạy. Ngược lại, với Tester thì việc tìm lỗi sai của sản phẩm và thường “suy nghĩ tiêu cực” về các giải pháp của Dev, nên Tester luôn giống như là kẻ “vạch lá tìm sâu.” Bạn có thể thấy Tester đang “đóng vai ác”
Chính vì mối bận tâm và mục tiêu công việc có phần ngược nhau, đôi khi nếu hai cái đầu nóng không tìm thấy tiếng nói chung, không hiểu tính chất công việc của nhau nên thường dẫn đến sự mâu thuẫn, thậm chí trở nên khó dung hoà.
3 nguyên nhân chính dẫn đến mâu thuẫn này
Khi hỏi “tại sao Tester và Dev thường không hợp nhau?” bạn sẽ nhận được nhiều câu trả lời khác nhau, và rất khó để có một câu trả lời chính xác và đầy đủ. Trong nhiều nguyên nhân ấy, tựu trung trong 3 nhóm chính là vấn đề trong giao tiếp, thiếu sự tôn trọng, và không thấu hiểu lẫn nhau.
Cách giao tiếp giữa Tester và Developer
Đầu tiên, mâu thuẫn có thể đến từ cả hai phía, nhưng có thể nói nguồn cơn thường gặp là do Tester. Thử đặt bạn vào vị trí của một lập trình viên [Dev], người đã dành cả 2 ngày cuối tuần để cố gắng lập trình cho xong một user story khó nhằn. Họ đang thấy yêu đời, và chưa kịp hào hứng để “khoe” với PM hay khách hàng về thành quả này, thì bạn đã “dội gáo nước lạnh” bằng vài “con bug” và một bình luận rất vô tư như “nghe nói kinh nghiệm đầy mình mà sao để lọt những lỗi cơ bản như vậy!” Trước tiên, chưa cần kiểm tra xem lỗi này là đúng hay sai thì Dev đã có thể phản ứng tiêu cực ngay với thông tin bạn cung cấp. Và vì Dev đang có niềm tin rằng chương trình của họ chạy đúng nên rất khó để họ chấp nhận rằng “code của họ sai.” Chính vì các vấn đề trong giao tiếp này đã góp phần tạo ra sự căng thẳng giữa Tester và Dev.
Thiếu sự tin tưởng và tôn trọng lẫn nhau giữa Dev và Tester
Nguyên nhân thứ hai là thiếu sự tin tưởng lẫn nhau trong công việc. Ví dụ như khi báo cáo lỗi, thay vì tập trung vào sự việc – bản thân lỗi phần mềm – và các bước tái hiện lỗi cũng như thông tin liên quan như môi trường kiểm thử và điều kiện tiên quyết [precondition] tương ứng, bạn trình bày vấn đề theo cách phê phán và chê bai “Dev dỏm” này kia. Dev sẽ không phản ứng mạnh mẽ nếu đó là lỗi của họ – Có thể mấy hôm trước đã tăng ca liên tục, lần đầu tiếp xúc công nghệ mới như blockchain/AI, hoặc do yêu cầu nghiệp vụ phức tạp dẫn đến sai sót trong quá trình lập trình. Tuy nhiên, nếu điều này [bị chỉ trích vì bug] xảy ra thường xuyên thì Dev cảm thấy họ không được tôn trọng, nói cách khác thì họ đang bị chỉ trích và bị coi thường.
Trong một số buổi thảo luận sau này, dù bạn có nói đúng, đưa ra ý kiến hay giải pháp hiệu quả cũng rất khó được Dev này chấp nhận. Và họ thường sẽ không tiếp thu những ý kiến đóng góp của bạn. Hoặc chờ có cơ hội thì Dev sẽ “trả đũa” có lẽ đủ cả vốn lẫn lời luôn. Lúc này thì khó lòng mà làm việc chung với nhau trong dự án một cách êm đẹp. Góc nhìn sai lệch về công việc của nhóm kiểm thử phần mềm của PM hay các sếp cũng góp phần làm cho Dev coi thường công việc của Tester. Mình nghe nhiều anh chị kể rằng “PM nhóm mình chỉ nghe lời Dev” hoặc thậm chí “lúc em báo lỗi thì PM không phản ứng gì, nhưng cuối dự án thì hỏi: tại sao lại còn quá nhiều bug chưa sửa?”
Sự thấu hiểu công việc của nhau
Là một Tester, bạn có thật sự hiểu rõ công việc thường ngày của Dev không? Ví dụ như, khi nhận yêu cầu thay đổi cách xử lý của một màn hình, có thể bạn nghĩ “cái này dễ mà” nhưng nếu bạn hiểu cách hoạt động bên dưới của chương trình và nền tảng mã nguồn hiện tại [codebase] thì có thể không hề đơn giản. Vì thế, đừng nhìn vào “thay đổi một thứ trên màn hình” mà nghĩ rằng Dev vẽ vời chứ gì mà phải mất 2 ngày để làm. Hay là “code có một xíu mà cũng tạo ra một nùi bug!”
Ở chiều ngược lại, Dev đôi khi cũng không hiểu rõ công việc của Tester nên vô tình tạo ra áp lực với họ dẫn đến xung đột hoặc những tranh cãi không đáng có. Nhiều người cho rằng Tester không cần biết gì, cứ ngồi phá phá là phát hiện ra bug. Họ không hiểu rằng, để tìm ra lỗi thì Tester cần phải hiểu rõ yêu cầu, nắm vững lĩnh vực của hệ thống đang được kiểm thử như nghiệp vụ ngân hàng, thương mại trực tuyến, hay chương trình quản lý bệnh viện thì mới có thể làm tốt công việc của mình là bảo đảm mọi yêu cầu của khách đã được đáp ứng [bởi hệ thống phần mềm] và giúp phát hiện sớm các rủi ro khác có thể xảy ra trong quá trình sử dụng thực tế, thông qua quá trình phân tích yêu cầu hệ thống, viết test case và thực hiện việc kiểm thử.
Tại sao chúng ta cần sống hòa thuận với nhau?
Qua các nguyên nhân trên bạn có thể nhận ra rằng nếu không thấu hiểu công việc của nhau sẽ dẫn đến người này luôn khó chịu về công việc của người kia. Không phối hợp tốt trong công việc dẫn đến Tester không có đủ thông tin cần thiết để phân tích khu vực có khả năng bị ảnh hưởng làm cho kiểm thử hồi quy [regression testing] không đầy đủ, dễ bị sót bug. Lúc này phải sửa lại, và kiểm thử lại – cả Dev và Tester không ai vui vẻ gì.
Không thể phủ nhận rằng “nếu không có Dev sẽ không có phần mềm” nhưng bạn cũng cần phải hiểu “các hoạt động kiểm thử giúp nhóm phát triển đúng phần mềm mà khách hàng cần” – Mà Tester là một trong những vai trò chính đảm nhận các công việc liên quan đến kiểm thử.
Nói một cách đơn giản và ngắn gọn, Tester và Dev [và các vai trò khác trong nhóm phát triển phần mềm như PM, UX Designer, BA, DevOps, v.v…] phối hợp với nhau trong các giai đoạn phát triển phần mềm từ lúc lấy yêu cầu, phân tích và thiết kế, cho đến lúc nghiệm thu [acceptance testing] và đưa ra thị trường.
Khi trả lời câu hỏi “tại sao bạn nghỉ việc ở công ty cũ?” thì đa phần sẽ trả lời rằng “do môi trường làm việc nhàm chán – và muốn tìm môi trường năng động và có nhiều thử thách để phát triển bản thân” nhưng khi gặp chuyện thì lại cho rằng “tôi không thể làm việc với Dev này hoặc Dev kia.”
Mâu thuẫn hay cạnh tranh lành mạnh là điều quan trọng cho cả Tester, Dev, và công ty, nó giúp thúc đẩy sự nỗ lực của mỗi thành viên trong nhóm. Nhưng nếu mâu thuẫn lâu ngày không được hoá giải sẽ dẫn đến nhiều tiêu cực và thậm chí là khách hàng đôi khi cũng bị vạ lây. Hãy thử tưởng tượng, nếu trong một dự án mà team Tester và team Dev luôn luôn trong trạng thái căng thẳng, đụng việc gì cũng có thể “xù lông nhím” lên với nhau, thì không khí làm việc trong dự án sẽ thế nào? Vui vẻ nhẹ nhàng hay nặng nề? Áp lực không phải đến từ “công việc” mà là “con người” – Kiểu như khi bắt được bug cũng lo mà bỏ sót bug cũng bị chửi.
Một điểm có lợi cho Dev khi hợp tác tốt với Tester là kỹ năng kiểm thử của họ sẽ tăng theo tỷ lệ thuận với việc ghi nhận và để ý sau mỗi lần sửa lỗi [fix bug] do bản thân hoặc Tester phát hiện được trong quá trình kiểm thử. Giúp họ tăng kỹ năng lập trình và ngày càng làm việc tốt hơn.
Nói thì dễ, làm mới khó! Để cải thiện mối quan hệ của hai bên Tester và Dev, trước tiên chúng ta cần thay đổi tư duy của cả hai bên.
Trước tiên là thay đổi tư duy của lãnh đạo [Engineer Manager/các sếp và Project Manager] và khách hàng. Không nên xem công việc kiểm thử, đặc biệt là manual Tester là “công việc hậu kỳ.”
Bản thân Tester không nên xem mình là “người canh cổng chất lượng” mà hãy là “camera giám sát chất lượng” có thể đi sâu sát các hành vi công việc ở mọi công đoạn phát triển phần mềm, từ lúc tham gia các buổi họp với khách hàng, PM hay BA để truyền tải yêu cầu, giúp nâng cao chất lượng yêu cầu thông qua việc phát hiện sớm những lỗi thường gặp như mô tả không rõ ràng, mô tả sai hoặc bị thiếu thông tin, hoặc mô tả yêu cầu không nhất quán nhau giữa các màn hình/phân hệ trong cùng một hệ thống.
Tiếp theo là cải thiện sự phối hợp giữa các vai trò trong nhóm phát triển phần mềm, đặc biệt là developer và Tester. Đối với Tester và Test Lead, khi báo cáo lỗi, không nên phán xét, chỉ trích Dev là người tạo ra lỗi mà nên tập trung vào việc cung cấp đủ thông tin để Dev có thể tái hiện và sửa lỗi nhanh nhất có thể.
Ban đầu, Dev có thể không biết phải làm thế nào để nâng cao chất lượng cho màn hình hay API mình vừa lập trình xong, lúc này Tester có thể giúp bằng cách cung cấp cho Dev một danh sách ngắn các trường hợp quan trọng, thiết yếu để giúp Dev tự đánh giá xem chất lượng công việc của mình. Thường gọi đây là tập “smoke tests” [các test case – trường hợp kiểm thử chính để đánh giá chất lượng cơ bản tối thiểu của một đối tượng – thường là các trường hợp dựa vào tài liệu mô tả yêu cầu – trên thực tế mọi người hay gọi là happy case]. Khách hàng và PM cũng nên hỗ trợ bằng cách dành đủ thời gian trong dự án cho Dev thực hiện việc tự kiểm thử này.
Sau một thời gian, Dev sẽ dần có thói quen và sẽ là tư duy [mindset] tự kiểm thử trước khi đưa cho người khác [ví dụ Tester], giúp chất lượng công việc của họ luôn tốt hơn trước đây. Tester vẫn làm công việc hằng ngày của mình là thực hiện kiểm thử kỹ hơn và chi tiết hơn bao gồm cả edge case. Qua quá trình làm việc cùng nhau, Tester nhận ra những khuyết điểm và sai sót thường gặp của Dev, họ sẽ giúp Dev khắc phục những điểm yếu này bằng cách kết hợp với Dev để cùng kiểm thử một chức năng hay màn hình nào đó [pair testing].
Khi Dev đã tự tin hơn trong việc tự kiểm thử các ticket của mình, thì Tester sẽ có thời gian để tập trung vào kiểm thử các luồng nghiệp vụ chính và chủ yếu là thực hiện e2e testing và regression testing – Tìm kiếm những lỗi có thể xảy ra do quá trình thay đổi code gây ra. Cùng nhau xem ví dụ dưới đây:
Giả sử như yêu cầu là “riêng Admin User thì không được hiển thị trong danh sách người dùng.”
- Trong lúc phân tích yêu cầu, tìm hiểu code và theo thiết kế hiện tại, trong table ‘tblUsers’ chỉ có 2 loại người dùng là Admin User và User, nên Dev lập trình chỉ lọc lấy những người dùng nào thuộc nhóm User để hiển thị lên màn hình. Dev có tự kiểm thử một số trường hợp chính trước khi đưa sang nhóm kiểm thử phần mềm.
- Tester thì tạo khoảng 20 người dùng, trong đó có Admin và User, khi kiểm tra trên UI thì chỉ có những User được hiển thị và không có Admin User nào trong đó, mọi thứ ổn.
Bạn thấy có gì đó sai ở đây không?
Mọi thứ vẫn ổn cho đến một ngày đẹp trời, khách hàng thêm một loại user nữa là ‘Super User’ thì trong màn hình hiển thị danh sách người dùng vẫn chỉ hiển thị MỘT LOẠI người dùng là User. Khách đã tạo một con BUG to kiểu critical và đòi fix gấp!
Lúc này, Dev [đã có niềm tin vào Tester – vì thấy được giá trị mà họ mang lại cho họ và nhóm] nên sẽ chủ động thảo luận và trao đổi các vấn đề kỹ thuật với Tester khi tìm cách fix [sửa] lỗi như thế này, và không ai đổ lỗi cho ai. Có thể trong quá trình trao đổi, Tester sẽ đưa ra câu hỏi kiểu What if, how, where,… giúp cho Dev nhận ra lỗi sai của họ. Với ví dụ trên, thay vì hard-code chỉ lọc lấy User, lập trình đúng là phải “lấy mọi nhóm người dùng trừ Admin User” – Lúc này có thể Dev sẽ chia sẻ với Tester cách họ sẽ làm như dùng thư việc nào đó để “exclude” Admin User ra khỏi danh sách người dùng sẽ trả về cho phía Front End. Và Tester có thể sẽ hỏi what if nữa: Nếu như sau này khách hàng muốn loại thêm 1 loại người dùng khác thì sao? Dev có thể sẽ sửa lại code của mình để hỗ trợ việc đó trong tương lai.
Từ thời điểm này, các bạn có thể thấy Tester và Dev sẽ luôn phối hợp, hỗ trợ nhau trong công việc thường này, ai cũng thấy vui mỗi sáng đến công ty.
🍀 Mình vẫn rất tâm đắc với câu này “United we stand, divided we fall” để nói lên rằng trong một tập thể chúng ta nên hỗ trợ và phối hợp với nhau để hoàn thành tốt công việc.