Một độc giả gửi cho một email: “Tôi thích bài viết của thầy về “Người kiểm thử trong dự án Agile” nhưng đấy là dễ cho thầy nói về làm việc tổ thôi. Là người kiểm thử, tôi thường thấy khó làm việc với người lập trình. Tôi càng tìm ra khiếm khuyết và báo cáo cho người quản lí, họ càng ghét tôi hơn nhưng tôi chỉ làm việc của mình. Người lập trình không thích người kiểm thử và chúng tôi không thích họ. Làm sao chúng tôi có thể xây dựng được cách làm việc tổ trong tình huống này?”
Trả lời: Không ai muốn nghe về sai lầm của mình cho nên tôi không ngạc nhiên rằng người lập trình KHÔNG thích nhóm kiểm thử của bạn. Tất nhiên, bạn (người kiểm thử) đang làm việc của mình và mục đích chung cuộc là chuyển giao sản phẩm chất lượng cho người dùng. Tôi nghĩ vấn đề ở đây là mối quan hệ đối nghịch giữa hai VAI TRÒ, và KHÔNG phải là với bạn như một cá nhân. Giải pháp tốt nhất là có đào tạo làm việc tổ để xây dựng mối quan hệ tốt hơn giữa hai nhóm.
Người quản lí của bạn cần can thiệp ngay lập tức bằng việc để cả hai nhóm tham dự đào tạo làm việc tổ. Trong đào tạo này, người quản lí phải giải thích rõ ràng vai trò, trách nhiệm của từng nhóm nhưng nhấn mạnh rằng cả hai (người kiểm thử và người lập trình) đều là một phần của MỘT tổ, không tách rời. Mọi thành viên tổ phải chia sẻ mục đích chung như chuyển giao sản phẩm chất lượng đúng thời gian, trong chi phí, và đạt tới sự thoả mãn của khách hàng.
Là người kiểm thử, bạn nên hội tụ vào việc cải tiến mối quan hệ với người lập trình. Bạn muốn là bạn của họ, thay vì là ai đó kiểm tra công việc của họ để tìm lỗi và báo cáo cho người quản lí. Tất nhiên, công việc của bạn là tìm lỗi nhưng bạn KHÔNG nên hành động như “cảnh sát viết biên lai phạt” khi tìm lỗi. Điều quan trọng là giải thích vai trò của bạn cho họ và yêu cầu họ làm việc với bạn thay vì chống lại bạn. Đó là trách nhiệm cho cả hai để đảm bảo rằng phần mềm làm việc đúng và có chất lượng cao. Trong khi người lập trình phải chắc chắn rằng không có lỗi về phần mã của họ, việc của bạn là đảm bảo rằng nếu có lỗi, chúng sẽ được sửa đúng đắn trong thời gian hợp lí trước khi phần mềm được đưa ra cho người dùng.
ĐỪNG chờ đợi cho tới khi người lập trình hoàn thành công việc của họ rồi bắt đầu kiểm tra. Nếu bạn tìm thấy nhiều lỗi, người lập trình sẽ bị tràn ngập, không thể sửa được chúng và họ sẽ thất vọng. Tất nhiên, từ thất vọng, họ sẽ oán trách người kiểm thử phát hiện ra lỗi của họ. Giải pháp tốt hơn cho bạn là tham gia vào trong dự án sớm nhất có thể được. Bạn có thể chia sẻ với người lập trình về kĩ thuật có thể làm cho họ nhận biết hơn về các vấn đề khác nhau và cách cải tiến chất lượng của họ. Bạn nên chia sẻ chiến lược kiểm thử của mình với người lập trình để cho họ có thể cảm thấy thoải mái chia sẻ mọi thứ với bạn. Điều tốt là chia sẻ kĩ thuật về cách kiểm thử phần mềm để người lập trình có thể kiểm thử công việc của họ trước khi chuyển giao sản phẩm cho nhóm của bạn. Tuy nhiên, điều đó có tác dụng nếu mọi người làm việc cùng nhau hướng tới mục đích chung: Tạo ra phần mềm chất lượng. Nếu bạn phải báo cáo lỗi cho người quản lí, giữ thái độ tích cực mà không làm tổn thương tới tình cảm của ai đó.
Khi bạn làm việc với người lập trình trong thời gian lâu, mối quan hệ có thể tốt hơn và thân thiện hơn. Là một tổ, bạn có thể làm việc cùng nhau để khử bỏ lỗi bằng chất lượng có sẵn thay vì kiểm tra chất lượng, điều bao giờ cũng tốt hơn.
A reader sent me an email: “I like your writing about “Tester in Agile project” but it is easy for you to talk about teamwork. As a tester, I often find it difficult to work with programmers. The more I find defects and report to manager, the more they hate me but I only do my job. Programmers do not like testers and we do not like them. How can we build teamwork in this situation?”
Answer: Nobody want to hear about their mistakes so I am not surprised that programmers do NOT like your testing group. Of course, you (tester) are doing your job and the ultimate goal is to deliver quality product to users. I think the issue here is the adversarial relationship between the two ROLES, and NOT with you as an individual. The best solution is to have more teamwork trainings to build better relationship between two groups.
Your managers need to intervene immediately by having both groups to attend teamwork training. In this training, managers must clearly explain roles, responsibilities of each group but emphasize that both (testers and programmers) are part of ONE team, not separate. All team members must share common goals such as deliver quality product on time, within costs, and achieve users’ satisfaction.
As individual tester, you should focus on improving the relationship with programmers. You want to be their friend, instead of someone checking their works to find faults and report to managers. Of course, your job is to find defects but you should NOT act like a “Police writing ticket” when finding defects. It is important to explain your role to them and ask them to work with you instead of against you. It is the responsibility of both to ensure that the software is working properly and of high quality. While the programmers must make sure that there are no defects on their codes, it is your jobs to ensure that if there are defects, they will be fixed correctly within reasonable time before the software is released to users.
Do NOT wait until programmers complete their works then start checking. If you find a lot of defects, programmers will be overwhelmed, cannot fix them and they will get frustrated. Of course, out of frustration, they will blame on testers who discover their defects. A better solution is for you to participate in the project as early as possible. You may share with programmers about techniques that can make them more aware of different issues and ways to improve their quality. You should share your testing strategy with programmers so they can feel comfortable to share things with you. It is good to share techniques on how to test software so programmers can test their works before deliver the product to your group. However, it only works if everyone is working together toward a common goal: Produce a quality software. If you have to report defects to manager, keep it positive without hurting someone’s feelings.
When you work with programmers for long time, the relationship could becomes better and friendlier. As a team, you can work together to eliminating defects by build-in quality instead of checking-quality, which is always better.
