Một sinh viên khoa học máy tính viết cho tôi: “Em đã tốt nghiệp được vài tháng và hiện thời đang làm việc như người kiểm thử trong một công ti phần mềm. Em thấy nhiều lỗi trong phần mềm nhưng phần lớn người phát triển bỏ qua báo cáo của em cho nên em không biết phải làm gì. Em có nên tự mình chữa các lỗi đó không? Xin thầy lời khuyên.”

Đáp: Là người kiểm thử mới, khó mà thuyết phục được người lập trình có kinh nghiệm về lỗi của họ mà bạn tìm ra. Cho dù nó là hiển nhiên, người phát triển có thể bỏ qua nó hay có cái cớ là “tôi đang bận” hay “tôi sẽ sửa nó sau” điều có nghĩa là họ có thể không sửa nó. Từ yếu tố tâm lí, khó cho người phát triển chấp nhận sự kiện là mã của họ có nhiều lỗi và người kiểm thử mới tìm ra nó. Tuy nhiên, bạn nên tránh đổ lỗi cho bất kì ai  vì việc của bạn là tìm ra lỗi để được sửa để cho sản phẩm cuối cùng có chất lượng cao. Là người kiểm thử, việc của bạn KHÔNG phải là sửa lỗi, cho dù một số có thể là dễ sửa.

Giải pháp tốt nhất là cố gắng trao đổi phát hiện của bạn với người phát triển mà không đổ lỗi cho họ. Bạn có thể nói: “Tôi tìm thấy lỗi nhỏ này và tôi chắc anh (chị) có thể sửa nó dễ dàng trong vài phút. Mã anh (chị) viết là tuyệt vời và bởi việc kiểm thử nó, tôi học được nhiều từ phong cách của anh (chị).” Hay “Khó mà tìm ra lỗi được, tôi may mắn lắm mới tìm ra nó.” Cách tiếp cận là chỉ ra cho họ lỗi rồi ca ngợi họ về cái gì đó khác để cho nhẹ bớt vấn đề đi. Bởi vì người phát triển làm việc vất vả để xây dựng mã của họ và bằng việc nói với họ rằng họ có nhiều lỗi cũng giống như bảo họ rằng họ không biết điều họ đang làm. Đó là lí do tại sao họ thường bảo vệ công trình của họ hay bỏ qua bạn vì không ai thích phạm sai lầm và để cho chúng bị vạch ra.

Mặc dầu thỉnh thoảng người kiểm thử và người phát triển không hài hoà nhưng bạn phải cố gắng tránh điều đó bằng việc phát triển mối quan hệ tốt hơn với người phát triển. Nhiều người kiểm thử chỉ gặp người phát triển khi họ tìm ra lỗi hay khi có vấn đề. Với người phát triển, mã của họ là công trình của họ, và nhận diện các vấn đề trong công trình của họ có nghĩa là bạn đang phê bình công trình của họ. Tuy nhiên, là người kiểm thử mới bạn có thể tới và tự giới thiệu bản thân mình và khiêm tốn nói: “Tôi là người kiểm thử mới, tôi có nhiều điều cần học hỏi trong việc làm của tôi và tôi cần sự giúp đỡ của anh (chị) để làm cho việc của tôi được tốt hơn.” Ai có thể giận với người nào đó cần sự giúp đỡ? Nếu bạn nói với họ, là bạn của họ và nếu họ chấp nhận bạn như người bạn, thì chả thành vấn đề bạn tìm ra bao nhiêu lỗi họ sẽ không cảm thấy bị xúc phạm. Cách tốt nhất là làm việc cùng nhau như “một tổ” thay vì hai nhóm đối địch.

English version

The new tester

A computer science student wrote to me: “I graduated few months ago and currently working as a tester in a software company. I found many bugs in software but most developers ignored my report so I do not know what to do. Should I fix the bugs myself? Please advice.”

Answer: As a new tester, it is difficult to convince experienced developers about their bugs that you found. Even if it is obvious, developer may ignore it or have excuses such as “I am busy” or “I will fix it later” which means they may not fix it. From the psychological factor, it is difficult for developers to accept the fact that their code has many bugs and a new tester found it. However, you should avoid blaming anyone as your job is to get the bug fixed so the final product is of high quality. As tester, it is NOT your job to fix bugs, even some may be easy to fix.

The best solution is trying to communicate your findings with developers without blaming them. You may say: “I found this small bug and I am sure you could fix it easily in few minutes. You code is excellent and by testing it, I learn a lot from your style.” Or “It is a hard to find bug, I am lucky to find it.” The approach is to show them the bug then praise them on something else so it lighten the issue. Because developers work hard to build their code and by telling them that they have many bugs is like telling them that they do not know what they are doing. That is why they often defend their works or ignore you as nobody likes to make mistake and have them pointed out.

Although sometime testers and developers do not get along but you must try to avoid it by develop a better relationship with developers. Many testers only meet with developers when they find bugs or when there is a problem. For developers, their code is their work, and identify problems in their work means you are criticize their work. However, as a new tester you may come in and introduce yourself to them and be humbled: “I am a new tester, I have a lot to learn in my job and I need your help to do my job better.” Who can be angry with someone who needs help? If you talk to them, be their friends and if they accept you as friends, than no matter how many bugs you found they would not be defensive. The best way is to work together as “one team” rather than two adversarial groups.