Làm thế nào để tái hiện được 1 lỗi khó tái hiện và làm cho nỗ lực kiểm thử của bạn là hiệu quả

Trong thế giới testing, một bug/defect được tìm thấy nên được tái hiện một cách nhất quán, như vậy, tester có thể báo cáo bug đó với sự tin tưởng, dev có thể fix bug với sự rõ ràng và Team QA có thể tự tin đóng bug đó lại.

Tuy nhiên, quá trình này đôi khi đi kèm với những khó khăn của riêng nó. Bài viết này cố gắng làm sáng tỏ những vùng tối của việc tái hiện bug.

Đầu tiên, "Tái hiện bug là gì?"

Nếu 1 trình tự các bước bất kì đưa tester đến 1 sự sai lệch so với sự mong đợi - các bước để tái hiện chính là 1 bản ghi chính xác trình tự những bước này. Nếu chúng ta gặp phải 1 vấn đề tương tự, bất cứ khi nào, chúng ta hãy làm theo những bước đó, đây đc gọi là tái hiện bug.

Thêm vào đó, để từng bước tái hiện, nhiều bằng chứng hơn như dữ liệu được sử dụng, ảnh chụp màn hình hoặc videos được ghi lại có thể cũng đc cung cấp. Trong trường hợp những những thông tin này được tìm thấy không thống nhất hoặc không đúng, những bugs đó có thể được bỏ qua và được đánh dấu là invalid mà không cần bất cứ sự phân tích nào nữa. Vì vậy, các bước để tái hiện rất quan trọng và dưới đây là một số điểm cần lưu ý khi viết phần này của báo cáo bug:

** Làm thế nào để viết lại các bước tái hiện bug:**

• Hãy cẩn thận bao gồm chính xác những những dữ liệu đã sử dụng trong khi kiểm thử để dễ dàng tham khảo. Các bước phải được thực hiện theo thứ tự chính xác.

• Việc đề cập đến những điều kiện tiên quyết khi áp dụng

• Không viết những bước ghép. Ví dụ: Nếu một trường hợp yêu cầu người dùng lưu 1 tài liệu từ Microsoft word, nó nên được viết như sau: "Open the File menu and click on save option"

• Luôn luôn kiểm tra lại các bước của bạn để tái hiện trên 1 hệ thống mới, xóa tất cả cookies và bộ nhớ cache.

• Hãy chắc chắn rằng các câu ngắn gọn và rõ ràng.

• Một cách viết sai các bước để tái hiện có thể không chỉ làm mất đi giá trị của bug mà còn làm tốn rất nhiều thời gian vào việc tìm ra sự sáng tỏ và câu trả lời về những thứ không được đề cập 1 cách rõ ràng.

** Vì sao việc tái hiện bug là rất quan trọng? **

Ngay bây giờ, hãy để chúng tôi tìm ra tại sao việc tái hiện bug lại quan trọng?

Nói 1 cách nghiêm túc, nếu bạn không thể tái hiện 1 bug, bạn có thể không bao giờ fix nó.

Dưới đây là một số nhân tố xác định liệu 1 sai sót đã được fix:

• Những thông tin chi tiết và đầy đủ trong báo cáo lỗi

• Liệu 1 dev có thể hiểu được sự xảy ra thực tế của lỗi dưới những điều kiện nhất định?

• Liệu môi trường, công cụ và version chính xác của ứng dụng có sẵn với dev cho lỗi mà được báo cáo bởi testers?

** Bugs/Defects không thể tái hiện là gì? **

Mỗi tester phải có kinh nghiệm trong những trường hợp này: Theo dõi một vấn đề cả ngày trời và đến cuối ngày khi bạn báo cáo bug đó, bạn tìm ra nó không tái hiện được nữa. Việc theo dõi 1 vấn đề không liên tục, ví dụ, giả sử 1 người dùng mới không thể thêm những sản phẩm vào giỏ hàng của họ. Điều này xảy ra 6 trên 10 lần.

Vấn đề được tìm thấy chỉ khi chúng ta khởi động lại ứng dụng.

Trong tất cả những trường hợp này, rất khó để xác định điều kiện chính xác và báo cáo nó đúng. Có những vấn đề tiêu tốn rất nhiều thời gian trong việc đầu tư vào. Loại vấn đề này không thể lờ đi/bỏ qua vì người dùng cuối/ khách hàng cũng có thể bắt gặp chúng.

** Làm thế nào để tái tạo lỗi? **

Có một vài điểm dưới đây có thể giúp chúng ta việc này:

• Xóa toàn bộ cache và cookies trong khi thực hiện kịch bản test.

• Quan sát từng bước chạy kịch bản.

• Đôi khi chúng ta tìm kiếm các bug tương tự(similar bug) hoặc các mẫu thử ( pattern) có thể có ích trong việc tái tạo một lỗi. Điều này có thể sẽ dễ dàng hơn để nhận ra kích bản test nếu pattern này được hiểu đúng.

• Ghi note lại cho mỗi bước chạy kịch bản và các yếu tố khác ( như test data, môi trường test, setting hệ thống, screenshots, logs...), điều đó có thể dễ dàng tái tạo kịch bản trong lần chạy tiếp theo.

• Verify kịch bản vài lần để xác định chỗ có bug. Đừng tin tưởng và báo cáo ngay dựa vào việc bug mới chỉ xuất hiện 1 lần.

• Việc kiểm thử với sự kiên nhẫn là yếu tố then chốt giống như sức mạnh tuy nhiên nó cũng mất nhiều thời gian.

Ngoài ra:

• Ngay cả khi chúng ta thực hiện test thăm dò (exploratory testing), hãy chắc chắn rằng toàn bộ cấu hình cũng chuẩn như việc hệ thống thiết lập.

• Bạn nên dùng sự sáng tạo của mình để khám phá application theo nhiều cách khác nhau và thử một vài các kịch bản khác thường. Mặc dù trong trường hợp này nên đi theo thứ tự logic thay vì thực hiện các bước random.

• Một khi một vấn đề được theo dõi, nó luôn là một cách tốt để verify cùng một vấn đề trên các browsers/OS khác nhau, thiết bị khác nhau ( được hỗ trợ).

• Điều này giúp chúng ta xác định liệu vấn đề xảy ra là do nguyên nhân system, đặc tả trình duyêt, đặc tả thiết bị.

• Hãy luôn update mình theo xu hướng mới và các diễn đàn về các loại khác của vấn đề và các sự cố của họ. Sự giúp đỡ này tỏng các đặc tả hệ thống cụ thể, trình duyệt cụ thể, sản phẩm cụ thể và các vấn đề bên ngoài...

• Thay vì tiếp tục cố gắng tái tạo vấn đề xảy ra 1 lần, thì đôi khi ngồi lại và phân tích các bước được thực hiện có thể giúp tìm ra giải pháp.

• Thảo luận với các team members hoặc quản lý đôi khi cũng rất hữu ích bởi họ là những người có kinh nghiệm.

• Chia sẻ màn hình của bạn từ screenshort và video để giải thích vấn đề với đội phát triển là cách nên cân nhắc tới.

• Tái tạo vấn đề Bug xảy ra hơn 1 lần có thể chắc chắn về sự xuất hiện của vấn đề đó. Trong trường hợp này, bạn có thể tự tin trong khâu testing của bạn và có thể trả lời các câu hỏi và thắc mắc của đội phát triển.

** Kết luận: **

Với các cuộc trao đổi tổng thể, thì có thể kết luận rõ ràng rằng đây là vấn đề quan trọng để "tái tạo một bug" nhằm mục đích tìm được bug và sửa bug. Nếu bug này khôgn thể tái tạo, thì effort test được sử dụng để tìm kiếm, phân tích và báo cáo rằng đây là bug đặc biệt thì thật lãng phí.

Đối với sự hiểu biết và tái tại 1 bug, thì điều cần thiết để có chi tiết phải có giải thích chi tiết và thích hợp các bước tái tạo bug, trạng thái và môi trường trong mỗi bug xảy ra. Có thể sửa một bug không thể tái tạo, nhưng có thể sẽ mất thời gian. Một yếu tốt quan trọng khác là việc communicate thích hợp nếu mà thiếu nó thì một bug hợp lệ sẽ bị bỏ qua.

Do vậy, để tạo ra effort test trong việc tìm kiếm bug có giá trị thì những đề cập trên có thể giúp ích.