🐞 Trong kiểm thử phần mềm, khi bạn dựa vào tài liệu mô tả yêu cầu để thiết kế, nghĩ ra những trường hợp cần kiểm thử, thì đa phần những trường hợp: đó là positive case (còn gọi là happy case) – là những trường hợp nhập các giá trị đúng thì mong đợi phần mềm thực hiện đúng theo mô tả yêu cầu; Và các trường hợp negative case (nhập những giá trị sai và phần mềm sẽ báo lỗi tương ứng). Vậy còn edge case là gì? Nó cũng là một dạng negative case nhưng các thao tác thường phức tạp và lắc léo hơn.
Theo định nghĩa trên trang Cambridge
Edge case is a problem or situation, especially in computer programming, that only happens at the highest or lowest end of a range of possible values or in extreme situations.
Theo từ điển American English thì
Edge case is an unusual or unforeseen situation where something may fail to work properly or as expected.
Qua những định nghĩa trên cùng với kinh nghiệm kiểm thử phần mềm của mình thì
Edge case là những trường hợp lắc léo, hóc búa mà khi chỉ dựa vào mô tả trong tài liệu yêu cầu bạn không xác định được nó. Thường những trường hợp này xảy ra khi môi trường và các tham số đầu vào không như mong đợi của ứng dụng hoặc tìm cách can thiệp làm thay đổi phá vỡ logic của quy trình nghiệp vụ bình thường. Corner case là một thuật ngữ tương tự với edge case.
Ví dụ một edge case: Trả lời một bình luận đã bị xoá trên facebook.
Dựa vào đâu để nghĩ ra edge case?
Để nghĩ ra được edge case thì chủ yếu là dựa vào kinh nghiệm bản thân, dựa vào kiến thức về những điểm yếu, lỗ hổng của công nghệ đang được sử dụng để thiết kế ra phần mềm mà bạn đang kiểm thử. Bên cạnh đó còn dựa vào nghiệp vụ và lĩnh vực mà phần mềm đó phục vụ.
Thường thì tài liệu yêu cầu chỉ mô tả những trường hợp “happy case.” Rất khó để có thể liệt kê các trường hợp mà mình không biết hoặc chưa biết. Nói cách khác, tài liệu thường mô tả các trường hợp mình muốn phần mềm thực hiện chứ không mô tả các trường hợp mình không muốn phần mềm thực hiện.
Xem thêm lớp Kiểm thử phần mềm dành cho người mới
Khi nào thì nên nghĩ về edge case?
Nói về thời điểm thì những trường hợp này nên được xác định (nghĩ ra) càng sớm càng tốt. Vì đa phần những trường hợp này rất khó hoặc rất tốn kém để sửa (fix). Trong thời gian làm tester, mình đã gặp những trường hợp edge case mà phải thiết kế lại workflow của nghiệp vụ để tránh xảy ra những lỗi đó chứ không đơn giản là chỉ cần fix là được.
Nhưng thường thì khi phân tích tài liệu yêu cầu bạn không nghĩ ra được nhiều edge case. Những trường hợp này thường chỉ xuất hiện trong đầu khi bạn đang thực hiện kiểm thử, đang sử dụng sản phẩm, và nhất là trong lúc bạn thực hiện exploratory testing (kiểm thử khám phá) hay ad hoc testing (kiểm thử ngẫu nhiên).
Trong lớp ISTQB CTFL mình có dạy thêm về Exploratory Testing và edge case.
Đây là những cái lỗi mà người ta hay nói vui rằng là:
Một trong những lý do tôi rất thích làm tester đó là chỉ mất 5 phút để tìm ra 1 lỗi nhưng developer phải mất 5 ngày để sửa.
Một số ví dụ về edge case
Dưới đây là một số trường hợp edge thường gặp trong kiểm thử ứng dụng web và mobile app.
- Nhập số lượng sản phẩm cần mua = 0
- Chuyển tiền với số tiền là âm
- Đồng thời cùng thay đổi nội dung của 1 đối tượng (như bài post hoặc user)
- Cập nhật thông tin của một user không tồn tại
- Truy cập một nội dung không tồn tại từ hộp thông báo
- Tìm cách tạo ra lỗi 414 (too long request) khi test api (get hoặc post) với giá trị của tham số được gắn vào url như /v2/getTicket?Id=12,13,14,…
- Khi kiểm thử trên mobile thì thử đồng thời thực hiện thao tác và xoay điện thoại
- Chuyển mạng giữa 4G và wifi trong lúc thực hiện giao dịch (chuyển khoản, thanh toán online, upload/download, v.v…)
Sử dụng non-printing character cũng là một cách tạo ra Edge case.
Kiểm thử chức năng giao hàng
Giả sử bạn đang kiểm thử chức năng đặt hàng và giao hàng trong một trang thương mại điện tử. Bây giờ bạn đang kiểm thử chức năng thay đổi địa chỉ giao hàng. Và bạn bám sát tài liệu mô tả yêu cầu và có các trường hợp sau:
- Khách hàng muốn thay đổi địa chỉ giao hàng trong lúc thanh toán
- Khách hàng muốn thay đổi địa chỉ giao hàng sau khi đã thanh toán (online) thành công
- Khách hàng mua hàng muốn thay đổi địa chỉ giao hàng cho đơn hàng hôm qua
- …
Trên đây là một số test case cơ bản nhằm để kiểm tra rằng chức năng này đã đáp ứng mô tả yêu cầu. Tuy nhiên, edge case có thể nghĩ đến là:
- Chuyện gì sẽ xảy ra nếu khách hàng đổi địa chỉ sau khi Shipper đã lấy hàng và đang trên đường giao hàng?
- Nếu cho phép thay đổi địa chỉ, thì khi mua hàng tôi chọn địa điểm gần (TP.HCM) để phí ship thấp, thanh toán xong tôi đổi địa điểm thực tế cần nhận hàng – ở khá xa địa chỉ cũ (HN)
- Việc đổi địa chỉ giao hàng này, có cần kiểm tra lại phí giao hàng không? Nếu có, thì trong giỏ hàng có sản phẩm không giao được đến địa chỉ đó thì sao? Tách bill hay sẽ xử lý thế nào?
Đó là một số edge đơn giản có thể nghĩ ra nhanh được. Tuy nhiên để có thể nghĩ ra nhiều trường hợp nữa thì tester phải hiểu rõ nghiệp vụ giao hàng, đổi trả hàng,… Tài liệu mô tả yêu cầu thường chỉ mô tả “happy case” (những hướng dẫn mà phần mềm phải làm theo) chứ không mô tả chi tiết các trường hợp phần mềm sẽ không làm (should not do). Khi senior tester có kinh nghiệm thì sẽ đặt ra những câu hỏi (dựa vào các edge case mà họ nghĩ ra) thì PM, BA có thể giúp mô tả rõ hơn yêu cầu thông qua trả lời các câu hỏi này. Giúp tiết kiệm thời gian đi sửa lại nếu phát hiện trễ (thậm chí là sau khi chạy thiệt).
Ví dụ một kịch bản về hệ thống hỏi đáp
Dưới đây là các bước tái hiện một lỗi được tester báo cáo. Tester cho rằng đây là lỗi nghiêm trọng vì có thể làm thay đổi bản chất vấn đề, và việc thay đổi nội dung câu hỏi sau khi đã được trả lời là không thể chấp nhận được. Nhưng DEV thì cho rằng đây không phải là bug, vì trong tài liệu không mô tả cách xử lý cho trường hợp này. Và nếu đây là một đề xuất cải tiết (improvement hoặc enhancement ticket) thì được, nhưng nên xác nhận với PM hoặc khách hàng.
- Bên A: Đưa ra câu hỏi, trạng thái câu hỏi là “chờ trả lời”
- Bên B: Trả lời câu hỏi, trạng thái câu hỏi là “đã trả lời”
- Bên A: Vẫn được phép thay đổi/cập nhật nội dung câu hỏi
Bạn nghĩ gì về trường hợp này? Bạn thích cách xử lý nào trong những cách sau:
Khi câu hỏi đang ở trạng thái “đã trả lời” thì sẽ:
- KHÔNG cho phép thay đổi nội dung
- Vẫn cho phép thay đổi nhưng sau khi cập nhật nội dung câu hỏi, thì trạng thái câu hỏi sẽ tự động chuyển sang “chờ trả lời”
Một trong những edge case cho trường hợp này là:
Các thao tác bên dưới được liệt kê theo thứ tự thời gian thực hiện.
Bước | Thao tác được thực hiện | Trạng thái câu hỏi |
1 | Bên A đặt một câu hỏi mới | Chờ trả lời |
2 | Bên B đang soạn thảo nội dung trả lời | Chờ trả lời |
3 | Bên A cập nhật nội dung câu hỏi | Chờ trả lời |
4 | Bên B trả lời câu hỏi (submit) | Đã trả lời |
Hoặc Bên B nhanh tay hơn thì.
Bước | Thao tác được thực hiện | Trạng thái câu hỏi |
1 | Bên A đặt một câu hỏi mới | Chờ trả lời |
2 | Bên B đang soạn thảo nội dung trả lời | Chờ trả lời |
3 | Bên B trả lời câu hỏi (submit) | Đã trả lời |
4 | Bên A submit nội dung câu hỏi mới | Kết quả: Chưa xác định được |
Tóm lại
Để có thể nghĩ ra được những trường hợp lắc léo và hóc búa này thì bạn cần phải hiểu rõ về cơ chế hoạt động của chức năng mà bạn đang kiểm thử. Bên cạnh đó bạn phải nắm vững nghiệp vụ của nó thì mới có thể nghĩ ra trường hợp tương ứng mà thường trong tài liệu yêu cầu không mô tả.
Những lỗi do edge case phát hiện được thường khó để sửa. Đôi khi phải thay đổi luồng nghiệp vụ để ngăn ngừa nó xảy ra. Tuy nhiên cũng chính vì không được mô tả trong yêu cầu nên nhiều lập trình viên cũng sẽ từ chối fix lỗi này, và họ không đồng ý đó là bug bởi vì 1) trong tài liệu không mô tả phải xử lý trường hợp đó và 2) không người dùng (user) nào lại đi làm cái trò điên khùng như vậy. Trong trường hợp đó, bạn phải chứng minh trường hợp tương tự có thể xảy ra trong thực tế.
Những câu hỏi thường gặp liên quan đến Edge case
Thường thì chúng ta nên bắt đầu từ những trường hợp happy case (positive case) trước, rồi mới đến những trường hợp unhappy case (negative case) bao gồm edge case. Nên có thể nói, edge case nên được thực hiện sau khi chạy xong các trường hợp positive case.
Tuỳ vào hệ thống, chức năng bạn đang kiểm thử mà sẽ có nhiều hoặc ít edge case. Cũng ít trường hợp không thể nghĩ ra edge case nào. Khi nghĩ và thực hiện các edge case sẽ giúp bạn đánh giá được khả năng chịu đựng, độ tin cậy của chức năng/hệ thống đang được kiểm thử.
Thường thì mình sẽ dựa vào kinh nghiệm, hiểu biết về cách hệ thống hoạt động, cách nó được vận hành, và công nghệ đằng sau nó, v.v… Từ đó mình sẽ nghĩ ra được những trường hợp lắc léo để “phá” hoặc tìm cách làm cho hệ thống không hoạt động, đó là edge case.
One comment
Leave a reply →