I.Test escape hay Leaked bug trong Kiểm thử phần mềm :
- Có một thực tế hết sức phủ phàng mà hầu hết các kỷ sư kiểm thử phần mềm đều gặp phải đó là gần như chắc chắn là bạn không bao giờ tìm hết tất cả các lỗi của sản phẩm phần mềm . Bạn đã nắm được rất kỹ- rất có kinh nghiệm trong kiểm thử chức năng (Functional Testing) hay Kiểm thử tự động (Automaiton testing) , đã test rất kỹ càng trước khi bàn giao nhưng vẫn bị khách hàng tìm thấy trong quá trình sử dụng và nó được gọi là test escape hay leaked bug .
 |
| Gì chứ hả, bug nữa á |
- Một vấn đề mà tester thường xuyên gặp phải như sau:
+ Sau khi kiểm thử một Website / Application cho khách hàng - Chỉ yêu cầu test những chức năng của Website đó. Tôi dùng cả 2 kỷ thuật function testing và Automation testing, kiểm thử tự động cover được những test case chính và đã passed tất cả . Những case khác, tôi đã thử tất cả các trường họp có thể xảy ra và tìm được rất nhiều bug. Khi tất cả các bug này được Fixed - và thực hiện kiểm thử chấp nhận (Acceptance Test) cũng đã Passed. Sản phẩm được bàn giao cho khách hàng và nhận được feedback, tôi mới ngạc nhiên vì có rất nhiều bug từ người dùng.
+ Nghiên cứu, đọc và thực hiện lại các mô tả lỗi của khách hàng để tìm kiếm nguyên nhân (root cause) tại sao tôi lại để sót những bug này và nguyên lý sinh ra bug - tôi mới thấy rằng , cách suy nghĩ, sử dụng và tương tác với sản phẩm phần mềm của người dùng cuối khác khá nhiều so với cách suy nghĩ và tinh thần của người phát triển phần mềm - ngay cả với testcase của Kiểm thử viên phần mềm -
Vì sự chủ quan đảm bảo tất cả các chức năng hoạt động đúng như thiết kế mà vô tình quên đi những thói quen người dùng, những tương tác khác ( không có trong thiết kế) vô tình tạo ra lỗi hoặc Có thể tại thời điểm này, các chức năng của phần mềm hoạt động hoàn toàn đúng và chính xác nhưng ở một số trạng thái(states), luồng dữ liệu và điều khiển(control) vấn có một số đụng độ với webserver hay hệ điều hành hay trình duyệt....gây ra những lỗi không đáng có .
Vậy đó, với tư duy " Biết quá nhiều " những công nghệ, những thủ thuật cao xa và những thao tác phức tạp đã khiến cho các nhà thiết kế phần mềm, các nhà phát triển phần mềm và cả các kiểm thử viên phần mềm quên đi mục đích tạo ra sự tương tác thân thiện, dễ hiểu, dễ thực hiện cho người dùng- những khách hàng của bạn. Qúa chú trọng vào những bug " bự" mà vô tình bỏ qua những điều nhỏ nhặt nhưng lại vô cùng quan trọng trong việc đánh giá chất lượng sản phẩm phần mềm của bạn.
Qua đây, tôi chỉ muốn lưu ý các bạn tester (có cả tôi ) phải chú ý những điểm quan trọng sau:
1) Kiểm thử phần mềm phải luôn đứng và suy nghĩ như một người dùng thực sự, để mindset của bạn giải phóng khỏi những ràng buộc cũng như lối tư duy " Biết quá nhiều" của những nhà phát triển sản phẩm
2) Kiểm thử phần mềm phải luôn làm giàu (enrich ) bộ testcase của bạn - từ những case đơn giản, trưc quan nhất đên các case dự đoán là sẽ tìm ẩn nhiều bug nhất , từ tình huống đến dữ liệu kiểm thử phải có tính hệ thống và hướng đến người dùng
3) Kiểm thử viên phải luôn note lại cho mình những trường họp mà người dùng gặp phải, những case lạ , những phát hiện mới mẻ trong quá trình tìm bug sẽ giúp bạn có kinh nghiệm hơn, testcase phong phú và chất lượng hơn , đó như là sự tích góp, năng nhặt chặt bị để vào vai người sử dụng một cách tròn trĩnh và xuất thần
Có thể đây chỉ là những chú ý đơn giản nhưng để thực hiện nó vào dự án thực tế không hề đơn giản, bạn cần bĩnh tĩnh, tự tin , lạc quan và có sự tưởng tượng phong phú , nghiền ngẫm các spec , tài liệu thiết kế, thi thoảng phải chậm lại chút và quan trọng hơn cả là phải luôn để ý đến điều này sẽ giúp bạn hài lòng với những gì mình đã làm được .
Một vài chia sẻ nho nhỏ hy vọng sẽ giúp ích cho bạn đọc
Chúc các bạn thành công
-------------------------------------------
Face: https://www.facebook.com/KiemThuPhanMemVvn
G+: https://plus.google.com/u/0/b/117542284818070877723/117542284818070877723/about
