Vấn đề giao tiếp giữa developers và testers

Đây có lẽ là vấn đề muôn thuở mà các đội dự án luôn ưu tiên giải quyết hàng đầu bởi vì việc qiao tiếp giữa dev và tester rất quan trọng, nó quyết định hướng đi của dự án, giao tiếp kém có thể dẫn đến hiểu sai và tác động tới năng suất làm việc để khắc phục sự cố.

Cá nhân tôi nhận thấy rằng, để dự án chạy smooth thì giữa dev và tester đều phải giao tiếp thường xuyên và mâu thuẫn cũng từ đó xuất phát.

1. Quan điểm người xây dựng và kẻ phá hoại

Developers thường có xu hướng suy nghĩ để giải quyết vấn đề nhưng tester thì lại có xu hướng suy nghĩ tạo ra vấn đề.

Ví dụ như trong giai đoạn development: - Quan điểm của dev là tập trung vào việc xây dựng các chức năng - cách giải quyết các yêu cầu mà khách hàng đã đưa ra. - Nhưng đối với tester, họ lại áp dụng tất cả sự sáng tạo của bản thân mình vào việc kiểm tra các chức năng bằng các kịch bản và trường hợp làm cho ứng dụng phát sinh ra lỗi.

Qua đó, Developer là 1 nhân vật “thiện”, khổ nhọc, vất vả lắm mới làm ra được sản phẩm. Còn Tester lại đóng vai “ác” chỉ ngồi và nhăm nhe bắt lỗi của Developer rồi nhảy lên cười sung sướng khi tìm thấy lỗi. Phải chăng đây chính là nguyên nhân của câu nói: "Kẻ thù số 1 của Developer là Tester".

Trong quá trình làm việc, có những khi Developer và Tester tranh cãi nhau về những vấn đề xảy ra trên ứng dụng với các lí do: hiểu sai chức năng, báo sai bug, ...Những lúc như thế rất là gây mất đoàn kết nội bộ, làm ảnh hưởng đến bầu không khí làm việc và mối quan hệ của developer với tester không được tốt như lần đầu nhìn thấy nhau nữa. Và khi 2 bên không đưa ra được tiếng nói chung, chất lượng sản phẩm sẽ giảm dần, số lượng Bug cũng sẽ ít đi, mối quan hệ ngày càng căng thẳng hơn.

2. Giao tiếp chính là chìa khóa

Suy cho cùng thì sau những mâu thuẫn đó là mong muốn chất lượng sản phẩm. Testers và Developers mỗi người một vai trò, một chức năng, nhưng có cùng một mục đích là hoàn thành sản phẩm trong thời gian ngắn nhất với chất lượng cao nhất và hiệu suất tốt nhất. Developer code tốt thì Tester sẽ tốn ít thời gian và công sức để tìm lỗi. Tester tìm ra càng nhiều lỗi và càng sớm thì Developer càng tốn ít thời gian, công sức để sửa (chắc chắn là phải sửa khi khách hàng tự kiểm tra) về sau. Chất lượng sản phẩm, hiệu suất làm việc theo đó cũng tăng lên, rủi ro và độ căng thẳng và thời gian làm việc giảm.

Vì vậy để có thể cải thiện vẫn đề communication giữa các thành viên trong đội dự án, đối với vài trò là một tester tôi xin phép được trình bày một vài ý kiến như sau:

#1. Rời bỏ công việc liên quan đến cái tôi: Cố ý hoặc vô tình, chúng ta mang theo cái tôi đến nơi làm việc. Chúng ta nghĩ chúng ta đang làm việc tốt nhất (mà không nghi ngờ gì về điều đó) nhưng điều đó không có nghĩa là những người khác làm không tốt. Bằng việc thể hiện và hành động theo cái tôi, chúng ta đang tự tước đi sự phát triển của chính chúng ta và quá trình làm việc của những người khác.

Vậy, nếu có thể, đừng nghĩ rằng bạn đang là một tester, trước tiên hãy nghĩ bạn là một thành viên nhóm, những người đang làm việc chăm chỉ để làm mọi thứ đúng. Đừng bị tổn thương khi bugs bị bác bỏ, nhưng hãy cố gắng tìm hiểu nguyên nhân đằng sau đó. Đừng tự dừng lại khi biết thời gian dự tính cho việc kiểm thử đã hết. Đừng tự đánh giá quá thấp bản thân bằng việc chấp nhận rằng sự phát triển là một công việc tuyệt vời và cuối cùng đừng tự tin thái quá bằng việc giả định rằng bạn vượt trội hơn hẳn vì bạn đang tìm kiếm những vấn đề từ công việc của người khác.

#2. Hãy thực tế Là một tester, thời gian khó khăn nhất phải đối mặt là khi bugs mà bạn báo cáo bị bác bỏ. Hãy thực tế, cố gắng tìm hiểu nguyên nhân đằng sau sự bác bỏ, cố gắng tìm hiểu những gì bạn đã hiểu lầm hoặc đã giả định, cố gắng thuyết phục dev hoặc quản lí dự án nếu bạn nghĩ rằng trường hợp bạn trình bày là đúng và cố gắng tiếp tục.

#3. Đặt ưu tiên dự án Luôn luôn nhìn bức tranh lớn hơn và đặt ưu tiên mọi thứ một cách phù hợp. Dự án quan trọng hơn một bug hoặc một cá nhân. Để cái tôi của bạn ra sau và đi tới bàn dev, thảo luận, chia sẻ, tìm hiểu và làm việc một cách phù hợp.

#4. Kiên trì Mọi thứ không thay đổi hàng đêm, vì vậy hãy kiên nhẫn và làm tốt công việc. Đừng mất đi động lực, sự thúc đẩy khi thỉnh thoảng một ai đó nhận xét tiêu cực hoặc một dev làm ngơ bug/ gợi ý của bạn.

#6. Chấp nhận rằng con người có thể nhầm lẫn: Sau khi tìm ra một bug nghiêm trọng, đừng làm nó thành một trò cười trước mặt dev. Hãy hiểu rằng cách mà một tester làm việc dưới sự khủng hoảng về thời gian và ngân sách, tình trạng tương tự cũng được áp dụng với dev. Không ai có thể xây dựng được một phần mềm không có bugs, đồng nghĩa với việc kiểm thử sẽ không tồn tại. Vì vậy, hãy hiểu vai trò của bạn và hỗ trợ trong việc chấn chỉnh những vấn đề hơn là làm chúng thành trò cười.

#7. Hiểu nhiều nhóm luôn làm việc tốt hơn một nhóm đơn lẻ: Một nhóm kiểm thử cô lập với tất cả đội phát triển không thể năng suất. Khi một tester điều chỉnh được chính anh ấy/ cô ấy giữa các devs và phát triển một mối quan hệ tương hỗ, một môi trường nhóm tốt được tạo lên và khi tất cả các devs và testers làm việc cùng nhau, cả hai bên cùng có lợi.

** Kết luận: **

Developer là người tạo ra và phát triển sản phẩm. Tester là người kiểm tra sản phẩm. Do đó, cả hai đều là cần thiết cho việc hoàn thành dự án và cũng như để làm cho sản phẩm theo định hướng chất lượng và đáng tin cậy.