- vừa được xem lúc

Format khi log bug, resolved và retest bug dành cho dev, tester

0 0 5

Người đăng: Nguyen Thu Thuy

Theo Viblo Asia

Cần log bug như thế nào để bất cứ ai đọc cũng có thể hiểu? image.png

Dạo này test tủng các thứ gặp nhiều bug quá, log không xuể 🥲. Đôi khi còn phải retest bug của người khác nữa mà mình đọc bug không hiểu 😗.

Các bạn đã đi làm thì hẳn là biết tối thiểu 1 bug khi log sẽ cần những phần gì; với những bạn chưa đi làm thì các bạn cũng có thể google để biết.

Mình thấy ở mỗi nơi hoặc ngay cả khi cùng một team, nếu không có 1 format dùng chung thì mỗi người hẳn sẽ có những cách log bug khác nhau. Do đó rất khó để control, chưa kể nếu bug được log thiếu thông tin thì sẽ mất thời gian để confirm khi người fix hoặc người retest không hiểu rõ phần bị lỗi.

Dưới đây là các format mà mình đã đúc kết được trong quá trình làm việc, mọi người có thể tham khảo nha:

Format log bug: dành cho tester

ENV:

  • Môi trường: Dev/Test/STG/PROD
  • Browser: trình duyệt, version
  • Device: tên thiết bị test, os and version

PRE-CONDITION:

  • Điều kiện trước khi thực hiện các steps
  • Dữ liệu test

STEP:

  • Các bước thực hiện (tái hiện bug)

ACTUAL:

  • Kết quả thực tế
  • Evidence
  • Số lần tái hiện (ví dụ: 10/10)

EXPECTED:

  • Kết quả mong muốn

DOC, DESIGN:

  • Thiết kế, SRS, tài liệu liên quan khác

Format resolved bug: dành cho dev

Nguyên nhân: Nguyên nhân gây ra lỗi

Cách thực hiện: Cách fix

Actual: Trạng thái code đã được review chưa? Đã merge vào mtr nào?

Evidence:

  • FE: cần chụp ảnh màn hình chứng minh đã làm theo exp.
  • BE: cần chụp ảnh hoặc paste text rõ POST/GET, URL, req, res, ...

Phạm vi ảnh hưởng: Liệt kê các chức năng, màn hình có thể ảnh hưởng sau khi fixed

Format retest bug: dành cho tester

{ngày retest} - {môi trường test} - {trạng thái retest: NG/OK}

Step/Actual: (optional) Mô tả cách retest, data test khi có sự thay đổi

Evidence: Images hoặc video record khi retest bug


Với tham vọng phát triển phần mềm "no bug" 😂, việc cung cấp đủ thông tin về bug mang lại ý nghĩa rất lớn trong quá trình fix, retest bug và kiểm soát chất lượng của tất cả chức năng trong phần mềm.

Các format trên chưa hoàn toàn đầy đủ, mọi người có thể tùy chỉnh lại cho phù hợp với mình nhé. Hy vọng sẽ giúp ích được phần nào đó!🫡

P/S: Mọi người có thể đọc thêm bài viết khác của mình ở đây nhé ❤️ - https://thuy83tmu.wixsite.com/hoctestdao

Bình luận

Bài viết tương tự

- vừa được xem lúc

Mở đầu về API Testing (Phần 2)

Như đã đề cập ở phần trước, link bài viết:. https://viblo.

0 0 87

- vừa được xem lúc

Interview Question : Mobile application testing

Our Manual Testing Interview Questions and Answers blog guides you to master this field through the carefully collated set of Manual Testing interview questions. Good luck .

0 0 26

- vừa được xem lúc

Sự khác nhau giữa Manual Testing và Automation Testing

1. Manual Testing là gì. 2. Automation Testing là gì.

0 0 64

- vừa được xem lúc

Use case diagram và lý do sử dụng trong kiểm thử phần mềm (P1)

Hế lô các bạn, là mình đây ... Mình đã quay lại =)). Sau một vài lần phải tham gia vào dự án ở giai đoạn đang phát triển thì mình nhận ra Use case diagram hỗ trợ việc tiếp cận dự án và quá trình test

0 0 17

- vừa được xem lúc

Use case diagram và lý do sử dụng trong kiểm thử phần mềm (P2)

Tadaaa . Phần 1 cho ai chưa đọc đây nha: https://viblo.

0 0 18

- vừa được xem lúc

Phân biệt: modal, popup, tooltip, popover, alert, …

Với các bạn mới đi làm, non-IT hoặc có background IT nhưng không chuyên về code (giống mình) thì mình nghĩ đâu đó các bạn cũng ít khi gặp hoặc phân biệt được các thuật ngữ như: popover, dialog, popup,

0 0 11