Những con bugs vô tình khiến Dev bị tổn thương

Lập trình viên (Dev) và Kiểm thử viên (Tester) dường như là 2 chiến tuyến không hồi kết trong ngành phần mềm. Bản chất công việc của họ khác nhau người tìm được bug thì vui như mở hội, người ngồi nhận bug thì không biết nên vui hay buồn. Mặc dù mục đích của cả 2 chiến tuyến đều là mong muốn sản phẩm tốt hơn, nhưng do 2 cái nhìn khác nhau mà chúng ta hay xảy ra mâu thuẫn. Nhưng dù là thế cả 2 bên đều có chung 1 kẻ thù, đó là Bug.

Bug là gì và tại sao nó lại tồn tại?

Bug hay còn gọi là Defect là vấn đề xảy ra đối với một sản phẩm phần mềm khi developer xử lý một dòng hoặc một đoạn code bị lỗi ,mà kết quả đưa ra khác với yêu cầu của khách hàng hoặc người dùng.

Template của một con bug như thế nào?

Thông thường, trong quá trình Tester thực hiện test sẽ phát hiện ra bug và ghi lại nó trên một ứng dụng nào đó, có thể là trên gitlab, github, excel… để có thể chuyển giao qua team development. Nó thường được gọi là 1 bug report.
1 bug report thường được viết theo 1 template cố định của dự án. Không phải dự án nào cũng có một template giống nhau. Nó sẽ biến tấu dựa trên nhu cầu và mong muốn của team.

Lý do Developer từ chối Bug?

– Đó không phải là bug!
– Tài liệu không mô tả trường hợp này

Xử lý để thống nhất với nhau như thế nào

Trong trường hợp dev không đồng ý đó là bug, và từ chối (reject) thẳng tay (cập nhật con bug đó là invalid) thì tester nên làm gì? Và có phải tester luôn đúng không?

1. Đầu tiên Tester phải làm cẩn thận các bước sau mô tả về bug:
– Ghi steps 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. Nói có sách mách có chứng:
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ụ thể là Requirement document, Detail Design, Test spect, Test case,…

3. Đô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ó.

Tại Geneat Software, chúng tôi luôn tự tin hoàn thành dự án đúng thời hạn, và cho ra sản phẩm đáp ứng đầy đủ các yêu cầu của khách hàng. Bởi Tester và Dev nhà Geneat luôn 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 đến tay khách hàng có chất lượng tốt nhất