Xác định bug dựa vào “nấc cục”

Bài viết được sự cho phép của vntesters.com

“Bug” một trong những mối bận tâm lớn của kỹ sư kiểm thử. Nó mang lại niềm vui cho kỹ sư kiểm thử khi tìm được bug, nó gieo rắc nỗi sầu cho kỹ sư lập trình, nó cũng là cội nguồn của “cuộc chiến giữa các…kỹ sư kiểm thử và kỹ sư lập trình”. Tìm bug đã khó, để thuyết phục mọi người “đó là bug” lại càng đau đầu hơn. Các bạn cùng xem đoạn hội thoại sau:

– Kỹ sư kiểm thử: “Yeah, chỗ này có bug nè sư huynh”

– Kỹ sư lập trình: “Đâu, chỉ anh bug coi”

– Kỹ sư kiểm thử mô phỏng con bug…

– Kỹ sư lập trình:”Đâu phải bug đâu, tài liệu đặc tả có đề cập cái này đâu”

– (Kỹ sư kiểm thử liền đi lục tài liệu)…“Anh nói đúng, tài liệu không có đề cập nhưng em thấy nó vẫn không ổn lắm.”

– Kỹ sư lập trình (giọng hơi bực rồi): “Không ổn là không ổn làm sao? Tại liệu có đề cập đâu, anh chỉ code theo đặc tả…”.

– Kỹ sư kiểm thử có vẻ đuối lý và bỏ cuộc (dù vẫn còn ấm ức).

Có những tình huống mà rõ ràng kỹ sư kiểm thử biết là “có gì đó không ổn” nhưng vẫn không biết gọi mặt đặt tên nó như thế nào để thuyết phục mọi người đó là bug. Nếu rơi vào tình huống trên thì kỹ sư kiểm thử hãy khoan bỏ cuộc (kỹ sư kiểm thử giỏi không bỏ cuộc dễ vậy), hãy dựa vào những chỉ dẫn về “nấc cục” để tìm thêm lý lẽ để thuyết phục mọi người.

“Nấc cục” mà mình đang nói đến là “HICCUPPS”. HICCUPPS là chữ viết tắt của “History – Image – Comparable products – Claims – User’s expectation – Product itself – Purpose – Statutes“ là một tập hợp của những nguyên tắc/chỉ dẫn (oracle heuristics) được giới thiệu bởi James Bach (sau đó được Michael Bolton giới thiệu trong blog của ông với bài viết “Testing without a map”). Những nguyên tắc/chỉ dẫn này được định ra dựa trên kinh nghiệm thực tế đúc kết cũng như được nhiều người nhìn nhận là có hiệu quả (nhưng vẫn có thể sai). Về cơ bản nếu có một chức năng nào của sản phẩm đi ngược lại những nguyên tắc của HICCUPPS đều có thể được xem là bug. Chúng ta hãy cùng tìm hiểu xem những nguyên tắc này là gì nhé.

Lịch sử – History

Những chức năng của sản phẩm hiện tại nên nhất quán so với quá khứ (giả định rằng chẳng có lí do gì chính đáng để chức năng đó được thay đổi). Chúng ta nên lưu ý đặc điểm này khi kiểm thử trên một phiên bản mới của ứng dụng.

Nếu trong quá trình kiểm thử, chúng ta thấy một chức năng hoạt động bình thường nhưng trí nhớ mách bảo rằng “lúc trước nó đâu có chạy như vậy”. Nếu trong tài liệu không đề cập đến sự thay đổi đó thì rất có thể chức năng đã vô tình bị thay đổi. Dĩ nhiên, sự thay đổi đó có thể tốt hơn hoặc xấu hơn nhưng vấn đề là nó đã thay đổi và nhiệm vụ của kỹ sư kiểm thử là phải cung cấp thông tin đó.

Hình ảnh – Image

Hình ảnh của sản phẩm (giao diện và chức năng) nên nhất quán với hình ảnh mà sản phẩm thực sự muốn đem tới cho người dùng. Sản phẩm trông có vẻ “dỏm” thì rất có thể là nó “dỏm” thiệt.

Chẳng hạn, một website bán hàng trực tuyến tuyên bố hỗ trợ 24/7 cung cấp hỗ trợ qua Yahoo messenger nhưng người dùng chẳng bao giờ thấy người hỗ trợ đó online. Dĩ nhiên đó không phải là thông điệp “hỗ trợ 24/7” mà sản phẩm đang hướng đến.

Sản phẩm cùng loại – Comparable product

Chúng ta cũng có thể dựa vào sản phẩm cùng loại đang có trên thị trường để làm tiêu chuẩn đánh giá về sản phẩm của mình

Cùng một chức năng nhưng sản phẩm của ta làm không tốt bằng sản phẩm đối thủ. Đó là bug. Chẳng hạn như đa phần những website tin tức ngày nay đều chạy tốt trên cả điện thoại di động và PC nhưng sản phẩm của chúng ta chỉ có có thể chạy tốt trên PC trong khi giao diện trên di động thì bị “hỏng nặng”.

Tuyên bố – Claims

Sản phẩm nên hoạt động giống như những gì đã được tuyên bố hoặc định ra. Những tuyên bố này có thể được định ra trong tài liệu đặc tả, tài liệu hỗ trợ, thông cáo, thư điện tử hay trong một cuộc nói chuyện ở ngoài hành lang bởi những người “có tiếng nói” đối với những tuyên bố đó.

Nếu như bạn thấy sản phẩm chạy giống như đặc tả nhưng bạn nhớ lại rằng trong một cuộc họp với giám đốc sản phẩm trước đó, ông ta muốn sản phẩm chạy khác mà…Hãy viết ngay một email để xác nhận lại vấn đề. Bạn có thể nghe nhầm nhưng cũng rất có thể là người viết tài liệu đã nhầm và không loại trừ khả năng tất cả đều nhầm.

Mong đợi của người dùng – User expectation

Những chức năng của sản phẩm nên hoạt động giống như cách mà người dùng mong đợi nó hoạt động.

Một số con bug thường xuất hiện khi người dùng sử dụng bàn phím thay vì dùng chuột thao tác trên các chức năng. Một số người dùng thích dùng chuột, một số khác thì thích sử dụng bàn phím khi thao tác. Hãy luôn để ý quan sát xem người dùng sẽ dùng sản phẩm của mình như thế nào.

Sản phẩm – The Product itself

Các tính năng giống nhau trên cùng một sản phẩm nên hoạt động nhất quán với nhau trừ khi nó được thiết kế để chạy khác nhau.

VD: Trong cùng một trang tin điện tử, khi người dùng click vào mục trang tin “Xã hội “ thì ứng dụng sẽ hiển thị nội dung ra Tab mới trong khi click vào trang tin “Thể thao” thì nội dung chỉ hiển thị trong cùng một Tab. Đó là bug nếu như không có một yêu cầu nào mô tả ứng dụng phải hoạt động như vậy.

Mục đích – Purpose

Tính năng của sản phẩm nên hoạt động giống với mục đích của tính năng đó bao gồm mục đích tường minh hay hàm ý.

VD: Nhấn nút Add để thêm, Edit để chỉnh sửa, Delete để xóa. Nếu như có tính năng nào của sản phẩm hoạt động không như mục đích mong đợi của nó thì nó có thể là bug.

Qui định về Pháp luật, Tiêu chuẩn – Statutes and Standards

Qui định về pháp luật, tiêu chuẩn khác với Tuyên bố (Claims) được giới thiệu bên trên. Qui định về pháp luật, tiêu chuẩn thường là những quy định không được định nghĩa trong phạm vi của dự án – chẳng hạn như RFC (Request for Comments), FDA (Food and Drug administration), ADA (Americans with Disabilities Act) – nhưng bắt buộc phải tuân theo. Có những sản phẩm đặc thù ngoài việc phải tuân theo đặc tả còn bắt buộc phải tuân theo những quy định về pháp lí. Việc sản phẩm không tuân thủ những quy định pháp lí không chỉ đơn thuần là bug mà nó còn mang đến những rắc rối về pháp lí.

Đó là những nguyên tắc/chỉ dẫn về “HICCUPPS”. Mình cũng xin lưu ý là những nguyên tắc được giới thiệu bên trên là những phát hiện dựa trên kinh nghiệm của cá nhân và được nhiều người đồng tình. Những nguyên tắc này không mang giá trị đúng tuyệt đối. Vì lí do đó, sau này nhiều người đã bổ sung thêm những nguyên tắc khác như: HICCUPPS(F) hay FEW HICCUPPS.

Là kỹ sư kiểm thử, bạn sẽ không muốn và không nên giới hạn mình với những nguyên tắc đã được định ra. Bạn hoàn toàn có thể định ra những nguyên tắc của mình để làm việc vì chỉ có bạn mới biết điều gì là mang lại hiệu quả cho công việc của bạn. Tuy nhiên, nếu bạn rơi vào những tình huống khẩn cấp thì hãy nhớ “nấc cục” (HICCUPPS) nhé.

Lược dịch từ http://www.developsense.com

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

• Liệu AI có thể giúp doanh nghiệp đưa ra các quyết định kinh doanh toàn diện nhất?
• React Bind Pattern: 5 cách chỉ định tham chiếu this
• Cách viết một bug report tốt

Xem thêm Việc làm Developer hấp dẫn trên TopDev