Skip to content

Người kiểm thử và người phát triển

Một người kiểm thử viết cho tôi: “Em đã làm việc rất chăm chỉ để kiểm thử mọi thứ, nhưng phần mềm vẫn không làm việc như được mong đợi. Em thấy rằng người phát triển đã thay đổi thiết kế và mã mà không nói cho em cho nên kịch đoạn kiểm thử của em không làm việc. Điều này thường xảy ra trong công ti của em và phần lớn người kiểm thử đều thất vọng. Chúng em có thể làm gì? Xin thầy lời khuyên.”

 

Đáp: Phần mềm thay đổi khi người phát triển đổi mã của họ để đáp ứng cho những thay đổi yêu cầu của khách hàng. Vấn đề là người phát triển thường không trao đổi điều đó với người kiểm thử. Khi họ đưa mã của họ cho nhóm kiểm thử, họ thường không nghĩ về cách nó sẽ được kiểm thử, bao nhiêu thay đổi đã xảy ra và giải thích những điều đó cho người kiểm thử. Mặc dầu người quản lí có khuyến khích trao đổi giữa hai nhóm nhưng công việc phần mềm thường bận rộn cho nên những người phát triển và người kiểm thử không nói chuyện với nhau cho đủ, đặc biệt nếu người phát triển không bao giờ làm việc như người kiểm thử trước đây.

Có cách nhìn sai rằng khi một người là người phát triển, người đó sẽ vẫn còn là người phát triển và người kiểm thử vẫn còn là người kiểm thử không có thay đổi vai trò. Một số người phát triển nhìn xuống người kiểm thử và nghĩ rằng họ là giỏi hơn. Cho phép kiểu thái độ này sẽ phá huỷ dự án nhanh chóng. Khi tôi quản lí dự án phần mềm, tôi bao giờ cũng yêu cầu mọi người phát triển nhận cùng đào tạo như người kiểm thử phải nhận để cho họ biết người kiểm thử làm gì. Tôi cũng thường phân công và phân công lại các thành viên tổ vào các vai trò khác nhau để cho họ học toàn thể qui trình phát triển thay vì chỉ duy trì ở trong một khu vực. Từ kinh nghiệm, tôi biết rằng người phát triển có đào tạo cùng người kiểm thử hay làm việc như người kiểm thử thì cẩn thận hơn nhiều và không thay đổi mà không nói cho người kiểm thử về điều họ làm. Nếu người phát triển không trao đổi rất rõ với người kiểm thử thì tôi sẽ phân công lại họ để làm việc như người kiểm thử trong vài tuần để cho họ hiểu qui trình kiểm thử, tác động của những thay đổi trong môi trường kiểm thử, và tầm quan trọng của trao đổi tốt. Khi người phát triển biết cách họ có thể làm cho việc làm của người kiểm thử thành khó khăn hơn, họ thường thay đổi và toàn thể tổ dự án được hài hoà hơn.

Khi người kiểm thử và người phát triển làm việc như một tổ, chất lượng và năng suất có thể cải thiện lớn. Tôi cũng khuyến cáo rằng người quản lí dự án KHÔNG phân công vai trò nào thường hằng mà thường phân công lại mọi người vào các vai trò và trách nhiệm khác nhau để có tổ dự án có thể làm được mọi thứ.

 

—English version—

 

Testers and developers

A tester wrote to me: “I have worked very hard to test everything but the software did not work as expected. I found out that developers have changed the design and the code without telling me so my test scripts did not work. This happens quite often in my company and most testers are frustrated. What can we do? Please advice.”

 

Answer: Software changes when developers change their code to meet customers’ requirements changes. The problem is developers often do not communicate it to testers. When they give their code to testing group, they often do not think about how it will be tested, how much changes have taken place and explain them to testers. Although project managers do encourage communication between two groups but software works are often busy so developers and testers do not talk to each other often enough, especially if developers never work as testers before.

There is a wrong view that when a person is a developer, he will stay as developer and tester stays as tester without changing role. Some developers look down on testers and think that they are better. Allowing this type of attitude will destroy the project quickly. When I manage software projects, I always require all developers to take the same training that testers must take so they know what testers do. I also frequently assign and reassign team members into different roles so they learn the entire development process rather than just stay in one area. From experience, I know that developers who take training with testers or work as testers are much more careful and do not change without telling testers about what they do. If developers do not communicate very well with testers than I would reassign them to work as testers for few weeks so they understand the testing process, the impact of changes in testing environment, and the important of good communication. When developers know how they could make testers’ job more difficult, they often change and entire project team is more harmonious.

When testers and developers are working as a team, the quality and productivity can improve significantly. I also recommend that project manager do NOT assign any roles permanently but frequently reassign people into different roles and responsibilities to have a project team that can do everything.