12/08/2018, 16:15

Làm thế nào để không bị trả lại lỗi đã log

Bài viết sau được dịch từ link: http://www.softwaretestinghelp.com/how-to-get-your-all-bugs-resolved/ Tôi không thích việc bị trả lại bug mình log từ phía đội phát triển (dev team). Bạn thì sao? Tôi nghĩ là mọi tester luôn cố gắng để lỗi mình log được sửa hoàn toàn. Điều đó yêu cầu phải có kỹ ...

Bài viết sau được dịch từ link: http://www.softwaretestinghelp.com/how-to-get-your-all-bugs-resolved/ Tôi không thích việc bị trả lại bug mình log từ phía đội phát triển (dev team). Bạn thì sao? Tôi nghĩ là mọi tester luôn cố gắng để lỗi mình log được sửa hoàn toàn. Điều đó yêu cầu phải có kỹ năng report bug. Lý do chính của việc trả lại bug từ đội phát triển (dev team) là việc tái hiện bug không đầy đủ từ phía tester trước khi log bug. Ở bài này, tôi sẽ chỉ tập trung vào việc thực hiện các bước để tìm ra nguyên nhân chính gây ra bug. Việc tái hiện giúp cho bạn xác định được những vấn đề ko hợp lý mà mình tìm ra trong khi test là bug hay do thao tác sai trong khi test? Đúng vậy, 50% số lượng bug bị trả lại là do tester chưa hoàn thành các bước trong testcase. Bạn tìm ra một điểm vô lý của ứng dụng trong quá trình test, bạn đang chuẩn bị các bước để report bug. Nhưng khoan đã, bạn đã thực hiện đủ các bước tái hiện trước khi report bug chưa? Hay bạn đã thực sự chắc chắn đó là bug chưa?

Vậy bạn cần làm gì trước khi log bug? Hãy tìm câu trả lời cho các câu hỏi sau:

  1. Cái gì đang không hoạt động?
  2. Tại sao nó ko hoạt động?
  3. Làm thế nào để nó hoạt động?
  4. Đâu là lý do gây ra hiện tượng này?

Câu trả lời cho câu hỏi đầu tiên là đủ để bạn log lại các bước tái hiện trên hệ thống quản lý lỗi. Vậy tại sao chúng ta lại cần phải trả lời 3 câu hỏi còn lại? Hãy suy nghĩ vượt ra ngoài khuôn khổ trách nhiệm của bạn. Hãy hành động như một người thông minh thay vì một kẻ khờ khạo luôn chỉ bám theo những bước tái hiện đơn thuần mà không nghĩ được gì hơn thế. Bạn nên nghĩ đến tất cả những phương án giải quyết có thể để sửa lỗi và tính hiệu quả cũng như mặt hạn chế của từng phương án. Điều đó giúp tăng sự tôn trọng của các thành viên trong dự án với bạn và giảm thiểu việc bug bị trả lại, không phải vì tôn trọng mà vì kỹ năng tái hiện bug của bạn.

Trước khi log bất kỳ mỗi lỗi nào, hãy chắc rằng đó là bug chứ không phải sai lầm của bạn trong khi test. Bạn có thể bỏ qua một bước quan trọng hoặc chưa thực hiện đúng các bước trong testcase. Tái hiện lý do cho lỗi trên ứng dụng. Hãy log bug khi thực hiện đúng các bước tái hiện. Tôi đưa ra một danh sách các vấn đề thường gặp trong quá trình test khiến chúng ta nhầm tưởng nó là bug ở dưới đây. Hãy kiểm tra qua xem sao, dưới đây là một loạt những lý do khác nhau dẫn đến nhầm lẫn.

  1. Nếu bạn sử dụng config file để test ứng dụng của mình, hãy đảm bảo rằng file đó luôn được cập nhật với mỗi yêu cầu của ứng dụng. Rất nhiều lần file global config được thiết lập để lấy hoặc thiết lập một số flag cho ứng dụng. Việc không cập nhật những file này theo những yêu cầu của phần mềm có thể gây ra trục trặc cho ứng dụng của bạn trong lúc test. Bạn không thể log bug trong trường hợp này.
  2. Hãy kiểm tra xem database (DB) của bạn đã đúng chưa? Thiếu bảng trong DB thường là nguyên nhân khiến ứng dụng của bạn không hoạt động đúng. Tôi có một ví dụ điển hình cho trường hợp này. Một trong số dự án của tôi có thực hiện chức năng query rất nhiều bảng dữ liệu các tháng dùng để hiển thị lên report của người dùng. Cột đầu tiên được check ở bảng master (bảng master này chỉ chứa tên bảng theo tháng) và dữ liệu sẽ được query từ những bảng từng tháng riêng. Rất nhiều tester chọn khoảng thời gian lớn để xem report. Nhưng rất nhiều lần, ứng dụng bị crash vì một trong số bảng chứa dữ liệu không có trong DB test, hệ thống báo lỗi câu lệnh Sql và những tester đó đã log lại hiện tượng đó là bug- sau đó nó lại bị trả lại bởi đội phát triển.
  3. Nếu bạn đang làm việc với một dự án automation test thì hãy debug script test ít nhất 2 lần trước khi kết luận hệ thống chạy sai do lỗi.
  4. Hãy chắc chắn rằng bạn không đang access vào ứng dụng bằng cách không hợp lệ (VD: tài khoản fake)
  5. Kiểm tra xem phần mềm có tương thích hay không?
  6. Kiểm tra xem có vấn đề nào về phần cứng hay không?
  7. Đảm bảo rằng ứng dụng của bạn phù hợp với phần cứng.
  8. Kiểm tra xem mọi thành phần của ứng dụng được cài đặt đúng trên môi trường test. Kiểm tra để chắc chắn rằng mọi đăng ký đều hợp lệ.
  9. Với mọi lỗi có vẻ là lỗi của hệ thống. Bạn cần phải kiểm tra file log một cách kỹ lưỡng.
  10. Trước khi bắt đầu test, hãy chắc rằng bạn đã update mọi file mới nhất lên môi trường test (Đảm bảo môi trường test là mới nhất) Trên đây là một số sai lầm nhỏ thường gặp nhưng có thể tác động đến mối quan hệ cũng như sự tin tưởng trong team của bạn. Khi bạn tìm ra bug và nó bị trả lại bởi một trong số lý do như tôi đã đề cập ở trên thì đó sẽ là một sai lầm ngớ ngẩn và khiến bạn xấu hổ (ít nhất là với tôi). Vì vậy, hãy cố gắng đừng mắc phải những sai lầm đó!
0