Làm gì khi dev cãi không phải là bug??
Bài đăng này đã không được cập nhật trong 3 năm
Đây là problem phổ biến nhất mà bất cứ Tester nào cũng phải đối đầu ít nhất 1 lần trong nghề. Nó có thể xảy ra ở bất cứ dự án nào. Đây cũng là câu hỏi mà bạn thường gặp khi tham gia một cuộc phỏng vấn apply cho vị trí Tester
Ai cũng hiểu Dev team và Test team đều là một phần của dự án và cùng góp sức hoàn thành nó với chất lượng tốt nhất, tuy nhiên Dev ko bao giờ muốn công nhận bug của mình Thế nên vấn đề này là hiển nhiên xảy ra và ko có gì làm ngạc nhiên cả khi Tester không tìm được sự cộng tác của Dev => Tester luôn luôn chuẩn bị tâm lý, trạng thái cho trường hợp này nhé, không nên tỏ ra hả hê khi tìm đc bug
Vậy làm gì khi cả 2 bên đều đang muốn thuyết phục đối phương đồng ý theo cách của mình? Với kinh nghiệm mấy năm trong nghề, mình xin được chia sẻ kinh nghiệm bản thân xử lý vần đề này như sau:
A. Một số Cách xử lý khi Dev không công nhận Bug
1.Đầu tiên Tester phải làm cẩn thận các bước sau mô tả về bug:
• Ghi step chi tiết rõ rạng về bug
• Môi trường xảy ra bug
• Số lần xuất hiện bug/ Total số lần thực hiện
• Ver soft dùng để test (nếu trong trường hợp test mobile, app..)
• Check ở Các môi trường khác có xuất hiện bug không? Số lần xuất hiện/ tổng số lần thực hiện.
• Data dùng để test
• Lấy log or chụp evidence , quay video lại làm bằng chứng
2.Thứ hai, "nói có sách mách có chứng".
Tester muốn vạch ra lỗi của Dev trong quá trình xây dựng phần mềm thì phải có chứng cứ rõ ràng. Ai cũng biết định nghĩa bug là lỗi mà phần mềm hoạt động không như mong đợi của khách hàng.
Thế nên nếu Dev không công nhận bug thì bạn cứ đưa ra các tài liệu liên quan để chứng thực được cái mình nói có cơ sở. Cụ thể là Requirement document, Detail Design, Test spect, Test case,...
3.Đặc biệt cho trường hợp Dev đá bóng sang chân khác, nghĩa là đổ lỗi cho framework, OS, computer,... thì bạn buộc phải nhờ đến nhân vật thứ 3. Partner trung gian này có thể là 1 tester khác (có OS, computer... tương đương để diễn tả lại bug).
Hoặc cũng có thể là Test Leader hay PM để phân giải xem đây có thực sự là bug hay ko, và nên giải quyết thế nào với nó (Dev phải fix hay sẽ clarify/on hold / limitation...)
4.Trong trường hợp Dev luôn có status không được tốt trong quá trình làm việc. Tester có thể giải thích & nhắc nhở Dev đó rằng Tester ko phải là người tạo ra bug, Tester chỉ là người tìm ra bug để improve sản phẩm trước khi giao cho khách hàng
5.Đôi khi Bug bị dev reject vì lý do requirement không mô tả. Đây chính là trường hợp requirement bị thiếu. Nếu bug của bạn có liên quan tới chức năng business nó có thể được chấp nhận hoặc reject bởi 1 BA. Thì bạn nên đồng tình với nó.
6.Trường hợp tester đứng theo quan điểm người dùng để bắt bug, thường thì spec không mô tả chi tiết đến những trường hợp đó. Vậy tester không có cơ sở nào để base vào cả, mà bạn dev cũng không chịu nhận là bug thì tốt nhất nhờ Team Leader hoặc PM hoặc scrum master hay ai đó chịu trách nhiệm về dự án đó giải quyết, nếu PM nói không là bug thì sau này có vấn đề gì PM phải chịu trách nhiệm
Nhưng cái quan trọng phải nhớ là: thảo luận với tinh thần đóng góp, xây dựng với mục tiêu chung là cho ra sản phẩm, ứng dụng tốt nhất cho khách hàng chứ không phải tranh cãi vì cái tôi của mình (nhiều người luôn bực mình vì người khác đúng và ý kiến của mình thì sai, đừng để cái tôi vào công việc nhiều quá nha mọi người).
Mọi người cứ luôn suy nghĩ rằng, mình đang làm việc và mong muốn của mình là kết quả tốt nhất cho ứng dụng, mục tiêu của mình là test và tìm bug để sản phẩm đến tay khách hàng có chất lượng tốt nhất. Có như vậy thì mình sẽ không bị tình cảm, suy nghĩ cá nhân, cái tôi,… nó làm ảnh hưởng đến thái độ làm việc của mình.
B. Kỹ năng để hoàn thiện bản thân:
Với ánh mắt nhiều người, có khi Tester chả cần kĩ năng gì, cứ theo REQ kiểm tra giống y là được. Nhưng từ kinh nghiệm một số năm làm tester của mình tôi nghĩ cần khá nhiều những kỹ năng dưới đây để hoàn thiện bản thân.
• Hiểu biết các kỹ thuật test, kỹ thuật tạo test design : bạn có thể test ko áp dụng kỹ thuật, nhưng nó sẽ là chìa khóa để bạn làm tốt nhất và tự tin với công việc của mình
• Có khả năng R&D cho công nghệ mới : công nghệ thì luôn thay đổi, ko chỉ Developer mà bạn làm Tester cũng phải biết về nó
• Kỹ năng giao tiếp : communication với Dev, với PM, thậm chí cả với khách hàng nếu bạn làm Outsource, làm thế nào để làm hài hòa mọi thứ nhưng vẫn không quên nhiệm vụ tìm bug của mình
• Khả năng chịu áp lực : Tester thường hay bị hiểu lầm. Đôi khi bạn tìm ra bug và đang cực kỳ sung sướng với việc đó, bỗng dưng gặp ánh mắt chếch chếch nhìn sang từ các bạn DEV Không biết có bao giờ các bạn ấy hiểu cho tìm ra bug là output công việc của tester, tester vui khi tìm ra bug cũng giống như Dev vui khi tạo ra sản phẩm vậy chứ ko phải chúng tôi vui vì tìm ra lỗi lầm của các bạn Developer.
• Tôi thấy hiện nay ở các nước phát triển , bản thân làm với người Nhật nhiều năm họ đã hiểu được vai trò và vị trí của Tester trong đội dự án. Tuy nhiên ở Việt Nam nhiều nơi, nhiều người vẫn chưa hiểu được điều này, là điều khá đáng buồn cho các bạn Tester ở Việt Nam.
• Tính kiên nhẫn : cái này chắc cực kỳ cần thiết. Tôi đã từng phát chán ko tìm ra điểm gì hứng thú khi test ròng nhiều năm cho một dự án. Ngày nào cũng vẫn màn hình đấy, cũng vẫn cách xử lý đấy, đôi khi khách hàng chỉ thay đổi 1 yếu cầu rất nhỏ → viết Testcase phần change đó, và cả các chức năng liên quan khác → test lại, khách hàng tìm ra bug → test lại, thay đổi môi trường → test lại, vòng luẩn quẩn ko dứt. Thử hỏi ko có độ kiên nhẫn cao ai làm được thế.
C. Một số kim chỉ nam cần có:
Ngoài các kỹ năng cần thiết như trên, tôi cũng muốn list ra một số kinh nghiệm cần thiết luôn luôn nhắc nhở bản thân khi làm việc
• Không quá bảo thủ nhưng cũng không ba phải
• Hãy quyết đoán
• Hãy biết lắng nghe nhiều phía
• Luôn luôn nghĩ đến khách hàng nhưng cũng hãy biết thương lượng với họ ( nếu bạn là ở vị trí quản lý )
• Luôn nghĩ về sản phẩm : không chỉ là công việc tìm và post bug, hãy để cho mình tiến xa hơn thế
• Luôn nâng cao skill của bản thân khi có thể
D.Kết luận:
Trên đây chỉ là suy nghĩ và kinh nhiệm của bản thân có thể không đúng với nhiều bạn. Tuy nhiên, điều băn khoăn nhất của tôi cho đến lúc này là 10 năm nữa mình có còn tiếp tục với nghề này khi kỹ năng nhanh tay, nhanh mắt cũng bị hạn chế bởi tuổi tác?
Có lẽ hiện tại tôi chưa có thể nhìn thấy trước được tương lai đó, nhưng tôi tạm giữ vững niềm tin là sẽ có nhiều cách, cơ hội ,vị trí để dù già mình cũng vẫn bám trụ được với nghề
Các link tham khảo: http://stackoverflow.com/questions/3657267/what-a-tester-need-to-do-when-he-found-a-bug-and-the-dev-does-not-want-to-fix-it
All rights reserved
