Người kiểm thử và người lập trình
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.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
