Bug hay Improvement?

Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm hoạt động chính xác, đúng và đầy đủ theo yêu cầu của sản phẩm đã đặt ra.

Để đảm bảo chất lượng phần mềm thì việc phát hiện và log bug là công việc hàng ngày của một Test engineer. Tuy nhiên, không phải lúc nào những bug Test engineer tìm ra đều dễ dàng được "công nhận" là bug.

Team của bạn đã bao giờ phân vân hoặc xảy ra tranh luận về việc vấn đề này là Bug hay Improvement chưa? Thông thường tranh luận này sẽ dễ dàng xảy ra đối với các vấn đề chưa được mô tả rõ ràng ở tài liệu đặc tả phần mềm.

Hơn thế nữa, tranh luận này không chỉ xảy ra giữa Developer và Test engineer, mà đôi khi chính trong nội bộ nhóm Test engineer cũng gặp phải vấn đề tương tự.

Để có thể đi sâu và hiểu rõ hơn về vấn đề này, trước tiên chúng ta hãy cùng tìm hiểu khái niệm Bug và Improvement là gì. Khi nào thì một vấn đề sẽ được coi là Bug, khi nào thì sẽ được coi là Improvement.

Phân biệt Bug với Improvement

Theo ISTQB Glossary:

BUG

Một vấn đề gây phá hủy hoặc cản trở các chức năng của sản phẩm.
Một lỗi, khiếm khuyết hoặc sai lầm khiến kết quả không chính xác hoặc không như mong muốn.
Một thiếu sót hoặc nhược điểm làm gián đoạn trải nghiệm người dùng và có thể chỉ xuất hiện trong những điều kiện cụ thể.

IMPROVEMENT

Một sự thay đổi hoặc nâng cao các tính năng hiện có.
Một cải tiến để nâng cao trải nghiệm người dùng hoặc khi mong muốn thay đổi.

Đó là lý thuyết, vậy còn trong thực tế khi đặt dưới góc nhìn của Test engineer và Developer thì sẽ như thế nào?

Bug với Improvement trong dự án

Khi làm các dự án thực tế, chúng ta có thể gặp các tình huống gây tranh luận về Bug và Improvement. Nó có thể xuất phát từ việc tính năng chưa thực sự hoàn thiện, không tối ưu và sự khác biệt trong góc nhìn về các vấn đề liên quan đến UX.

Ví dụ 1: Màn hình hiện tại tự động phóng to khi nhấp đúp vào ảnh đại diện

Tài liệu chỉ đề cập rằng trang cá nhân được mở khi click vào ảnh đại diện.
Không đề cập khi double click vào ảnh đại diện thì điều gì xảy ra.

Test engineer: Đây là Bug vì trang cá nhân không mở, mà trang hiện tại lại tự động phóng to. Chúng ta nên hiển thị trang cá nhân ngay cú click đầu tiên, để tránh issue này.

Developer: Người dùng cũng chỉ click một lần thôi nên đây không phải là bug.

Ví dụ 2: Thông báo thứ nhất hiển thị trong 1 giây và biến mất rồi hiển thị thông báo thứ 2 khi tải ảnh sai kích thước và dung lượng

Tài liệu sẽ thường chỉ mô tả hiển thị thông báo lỗi cho trường hợp upload ảnh sai kích thước hoặc sai dung lượng.

Vậy khi ảnh sai cả kích thước và dung lượng thì sao?

Test engineer: Đây là bug vì thông báo thứ nhất chỉ hiển thị trong 1 giây rồi biến mất.

Developer: Đã hiển thị đầy đủ thông báo lỗi như tài liệu yêu cầu nên đây không phải là bug.

Ví dụ 3: Màn hình bị nhấp nháy 2 giây khi tải lại trang mặc dù dữ liệu nhẹ

Tài liệu mô tả truy cập trang thành công.

Vậy khi trang bị nhấp nháy 2 giây khi tải lại trang thì sao?

Test engineer: Đây là bug vì dữ liệu hiển thị không mượt mà, gây khó chịu cho người dùng.

Developer: Nhấp nhảy nhỏ này không ảnh hưởng đến tính năng, nên đây không phải là bug.

Ví dụ 4: Không giữ vị trí và trạng thái của trang danh sách bản tin sau khi mở chi tiết một bài và back lại

Khi xem trang gồm danh sách các tin tức:

Lướt đến trang thứ N của danh sách bản tin.
Cuộn xuống gần cuối trang.
Mở chi tiết một bài tin tức.
Click nút Back.

Kết quả: Hiển thị trang đầu tiên của danh sách các bản tin (thay vì hiển thị vị trí gần cuối ở trang thứ N)

Qua ví dụ này ta có thể thấy rằng:

Tài liệu mô tả mở chi tiết bài tin tức thành công từ danh sách các bản tin.
Có thể quay trở về danh sách bản tin bằng nút Back.

Vậy khi back lại mà không giữ vị trí và trạng thái của trang danh sách bản tin thì sao?

Test engineer: Đây là bug vì gây bất tiện cho người dùng; Cần phải tìm lại trang thứ N, kéo xuống gần cuối danh sách rồi mới tiếp tục đọc các bài khác được.

Developer: Tài liệu không đề cập đến trường hợp này nên là không hỗ trợ.

Ví dụ 5: Ứng dụng tạm dừng đột ngột khi tải tệp và xoay màn hình

Tài liệu chỉ đề cập rằng tải tệp thành công ở màn hình thẳng và ngang.

Vậy tải tệp và xoay màn hình thì sao? Chưa có mô tả nào cho trường hợp này ở tài liệu.

Test engineer: Đây là Bug vì ứng dụng đã tạm dừng.

Developer: Đây là Improvement vì tài liệu không đề cập đến trường hợp này và người dùng sẽ không xoay màn hình trong lúc tải tệp lên đâu.

Qua các ví dụ trên, ta có thể thấy sự khác nhau trong quan điểm của Developer và Test engineer, và xung đột có thể xảy ra nếu chúng ta không đi đến thống nhất với nhau.

Test engineer	Developer
Có xu hướng báo cáo Bug: Để vấn đề được sửa chữa nhanh chóng, tránh những trao đổi không cần thiết nếu báo cáo là Improvement. Người dùng có được những trải nghiệm tốt hơn. Cho rằng hành vi của người dùng thì không thể lường trước được.	Có xu hướng thích Improvement vì nghĩ rằng đây là tính năng, không phải là bug hay lỗi của mình khi code. Chỉ sửa nếu là Bug, còn nếu là Improvement thì sửa ở phiên bản sau. Nếu version có nhiều Bug rồi nên chuyển thành Improvement cho những vấn đề không được mô tả ở Tài liệu.

Quan điểm từ phía Test engineer

Nói một cách dễ hiểu thì có thể coi Bug như một lỗi phần mềm khi không hoạt động đúng theo tài liệu đặc tả. Tuy nhiên, còn nhiều phát sinh không được mô tả trong tài liêu và yêu cầu của Product owner, vì vậy từ góc độ mong muốn cải thiện chất lượng sản phẩm và trải nghiệm của người dùng, chúng tôi có đưa ra một vài quan điểm từ phía Test engineer như sau:

Tài liệu không phải lúc nào cũng mô tả hết các trường hợp có thể xảy ra.
Tài liệu thường mô tả những gì Product owner nghĩ rằng nó cần được mô tả. Có những trường hợp mà Product owner nghĩ là đương nhiên và không cần mô tả ở tài liệu.
Sửa hay không nên dựa vào độ ưu tiên để thực hiện, nhiều khi Improvement lại có độ ưu tiên cao và cần được sửa sớm.
Chúng ta cần bảo đảm hệ thống hoạt động bình thường trước các hành vi của người dùng.
Phần mềm chạy mượt trên thiết bị nào thì sẽ giúp người dùng trên loại thiết bị đó gắn bó với phần mềm hơn.
Nhiều bug ở giai đoạn phát triển còn hơn mang lại trải nghiệm không tốt cho người dùng.

Để tránh những tranh luận và tìm được tiếng nói chung giữa quan điểm trên của Test engineer và Developer dễ dàng hơn, mỗi dự án có thể thống nhất từ trước và đưa ra một số quy tắc chung dưới đây để có thể xác định được là Bug hay Improvement:

Một số quy tắc xác định bug hay improvement

	Mô tả ở Tài liệu hay chưa?	Trường hợp
1	Đã mô tả	Tính năng không thực hiện giống như mô tả trong bản đặc tả phần mềm.
2	Đã mô tả	Hành vi bất kỳ làm hệ thống/chức năng trong phạm vi không hoạt động đúng.
3	Chưa mô tả	Làm cản trở thao tác của người dùng.
4		Mang lại trải nghiệm không tốt, gây bất tiện cho người dùng.
5		Giao diện xô lệch, bị đè, mất hoặc tràn khung hình...
6		Nội dung các trang không hiển thị mượt mà, có sự chậm trễ hay nhấp nháy...
7		Mở rộng chức năng hiện tại.
8		Không thuộc phạm vi chức năng hiện tại Nếu thực hiện thêm thì người dùng có thêm trải nghiệm tốt hơn.
9		Tính năng thông dụng không hoạt động như những hệ thống nổi tiếng khác.

Kết luận

"Bug hay Improvement" vẫn luôn là một câu hỏi gây nhiều tranh luận trong mỗi một dự án phát triền phần mềm. Với những góc nhìn và giải pháp nêu trên, hy vọng chúng ta sẽ dễ đạt được sự thống nhất trong dự án hơn, giảm thiểu thời gian tranh luận cho câu hỏi "Bug hay Improvement?"

Dù là tên gọi nào đi chăng nữa, thì chúng đều là những vấn đề đang tồn tại ở hệ thống và phần nào làm gián đoạn trải nghiệm người dùng. Vì vậy để nâng cao chất lượng sản phẩm và sự hài lòng của người sử dụng, trước tiên chúng ta nên trả lời các câu hỏi, ví dụ như:

Đây có phải là issue ưu tiên xử lý không hay sẽ để xử lý sau được?
Việc xử lý issue này có làm người dùng có trải nghiệm tốt hơn không?
Mức độ ảnh hưởng khi xử lý issue này như thế nào? schedule có cho phép không?

Và sau đó chúng ta nên trao đổi cởi mở để cùng nhau đưa ra quyết định thay vì bỏ qua không xử lý.