Trong phần này, chúng ta sẽ tìm hiểu về Life cycle của Bug và các trạng thái khác nhau của Bug và mẫu báo cáo Bug.
Ở đây, chúng ta sẽ nói về Life cycle hoàn chỉnh của một Bug từ giai đoạn nó được tìm thấy, sửa, kiểm tra lại và đóng.
Chúng tôi có một số trạng thái Bug khác nhau như mới / mở, đã chỉ định, sửa, mở lại và đã đóng.
Ngay sau khi kỹ sư kiểm tra tìm thấy Bug, trạng thái được đưa ra là New, cho biết rằng Bug vừa được tìm thấy.
Bug mới này cần được báo cáo cho Developers có liên quan bằng cách thay đổi trạng thái là Assigned để người chịu trách nhiệm xử lý Bug.
Các bài viết liên quan:
Sau đó, Developers đầu tiên xem xét Bug, có nghĩa là Developers đọc tất cả các bước điều hướng để quyết định xem đó có phải là Bug hợp lệ hay không.
Dựa trên điều này, nếu Bug hợp lệ, Developers bắt đầu tái tạo Bug trên ứng dụng, khi Bug được tái tạo thành công, Developers sẽ phân tích code và thực hiện các thay đổi cần thiết, đồng thời thay đổi trạng thái là Fixed.
Sau khi thay đổi code được thực hiện và Bug được Fixed, kỹ sư kiểm tra sẽ kiểm tra lại Bug, có nghĩa là kỹ sư kiểm tra thực hiện lại hành động tương tự một lần nữa, được đề cập trong báo cáo Bug và thay đổi trạng thái cho phù hợp:
Close, nếu Bug được sửa đúng cách và hoạt động đúng chức năng theo yêu cầu.
HOẶC LÀ
Re-open, nếu Bug vẫn tồn tại hoặc không hoạt động đúng theo yêu cầu, thì Bug sẽ gửi lại cho Developers một lần nữa.
Quá trình này diễn ra liên tục cho đến khi tất cả các Bug được Fixed và Close.
Lưu ý 1:
- Kỹ sư kiểm tra không thể thông báo Bug bằng miệng cho Developers vì những lý do sau:
- Các Developers có thể bỏ qua Bug này
- Developers đã hiểu sai Bug
- Quên Bug
- Bug có thể không được tìm thấy ở vị trí chính xác
Ai chỉ định Bug
Bug có thể được gán cho những điều sau:
- Developers
- Developers lead
- Test lead
Developers: Nếu chúng tôi biết ai đã phát triển mô-đun cụ thể đó.
Developers lead: Nếu chúng tôi không biết Developers đã phát triển mô-đun cụ thể.
Test lead: Khi chúng tôi không có bất kỳ tương tác nào với nhóm phát triển.
Khi Bug được fix và close hoặc nếu nó có bất kỳ tác động nào đến mô-đun khác, thì chúng tôi sẽ đi đến một báo cáo Bug mới.
HOẶC LÀ
Khi tình trạng Bug re-open và ảnh hưởng đến mô-đun khác, thì chúng ta phải chuẩn bị báo cáo Bug mới.
Lưu ý 2:
- Bất cứ khi nào chúng tôi tìm thấy Bug và Developers sửa Bug đó, chúng tôi phải kiểm tra một vòng khu vực ảnh hưởng.
- Nếu Bug cũ được sửa chính xác, hãy thay đổi trạng thái thành Đóng.
- Và nếu chúng tôi tìm thấy một Bug trong khu vực tác động, sau đó được báo cáo là một Bug mới.
- Nếu Bug cũ không được sửa đúng cách, hãy chuyển trạng thái thành Mở lại.
- Hoặc, nếu chúng tôi tìm thấy khu vực ảnh hưởng của Bug, thì hãy thay đổi trạng thái thành Mới hoặc được báo cáo là Bug mới.
Các trạng thái khác của Bug
Sau khi chúng tôi chuẩn bị báo cáo Bug và gửi cho Developers, Developers sẽ chấp nhận Bug và bắt đầu thực hiện các thay đổi mã cần thiết để trở thành luồng tích cực của Life cycle Bug.
Có thể có một điều kiện serval trong đó Developers có thể không thực hiện các thay đổi mã cần thiết và tùy thuộc vào tình huống, điều này sẽ trở thành một luồng hoặc trạng thái tiêu cực của Life cycle Bug.
Sau đây là các trạng thái khác nhau của Life cycle Bug:
- Invalid/rejected
- Duplicate
- Postpone/deferred
- Can’t fix
- Not reproducible
- RFE (Request for Enhancement)
Invalid/rejected
Khi Kỹ sư kiểm tra viết một Báo cáo Bug không chính xác vì hiểu sai các yêu cầu, thì Developers sẽ không chấp nhận Bug và đưa ra trạng thái là Không hợp lệ và gửi lại. (Đôi khi Developers cũng có thể hiểu sai các yêu cầu).
Bất kỳ Bug nào không được Developers chấp nhận được gọi là Bug không hợp lệ.
Lý do cho trạng thái không hợp lệ của Bug
Tình trạng không hợp lệ của Bug xảy ra vì những lý do sau:
- Kỹ sư kiểm tra hiểu sai các yêu cầu
- Developers đã hiểu sai các yêu cầu
Hãy xem một ví dụ mà kỹ sư thử nghiệm và Developers đã hiểu sai các yêu cầu như chúng ta có thể thấy trong hình ảnh bên dưới:
Duplicate
Khi cùng một Bug đã được các kỹ sư kiểm tra khác nhau báo cáo nhiều lần được gọi là Bug trùng lặp.
Lý do cho tình trạng trùng lặp của Bug
Sau đây là những lý do dẫn đến tình trạng trùng lặp:
- Các tính năng chung:
Ví dụ: Giả sử chúng ta có kỹ sư kiểm thử P và Q đang kiểm thử phần mềm, kỹ sư kiểm thử P và Q sẽ kiểm tra các tính năng của họ như đăng nhập ứng dụng.
Tại đây, kỹ sư kiểm tra P nhập tên người dùng và mật khẩu hợp lệ, và nhấp vào nút đăng nhập.
Khi P nhấp vào nút đăng nhập, nó sẽ mở ra một trang trống, có nghĩa là đó là một Bug.
Sau đó, P chuẩn bị một báo cáo Bug cho một Bug cụ thể và gửi cho Developers.
Sau đó, kỹ sư kiểm tra Q cũng đăng nhập ứng dụng và gặp Bug tương tự. Q cũng chuẩn bị một báo cáo Bug và gửi cho Developers.
Sau khi Developers nhận được báo cáo Bug của cả hai kỹ sư kiểm tra, họ sẽ gửi lại báo cáo Bug cho Q và nói rằng nó trùng lặp.
- Mô-đun phụ thuộc
Như chúng ta có thể xem trong hình ảnh bên dưới, kỹ sư thử nghiệm muốn soạn thư, vì vậy trước tiên, kỹ sư thử nghiệm cần đăng nhập, sau đó chỉ anh / cô ấy mới có thể soạn thư.
Nếu Bug được tìm thấy trong mô-đun đăng nhập, kỹ sư kiểm tra không thể thực hiện thêm quá trình vì mô-đun soạn thảo phụ thuộc vào mô-đun đăng nhập.
Để tránh Bug trùng lặp
- Nếu Developers nhận được Bug trùng lặp, thì họ sẽ đi đến kho lưu trữ Bug và tìm kiếm Bug và cũng kiểm tra xem Bug đó có tồn tại hay không.
- Nếu cùng một Bug tồn tại, thì không cần ghi lại Bug tương tự trong báo cáo.
- Hoặc là
- Nếu Bug không tồn tại, hãy ghi lại Bug và lưu trữ trong kho lưu trữ Bug, đồng thời gửi cho Developers và Kỹ sư kiểm tra thêm chúng vào [CC].
Lưu ý 1:
Nói chung, chúng tôi không tìm kiếm từng Bug trong kho để kiểm tra tính trùng lặp.
Để tiết kiệm thời gian, chúng tôi chỉ tìm kiếm Bug có đặc điểm chung và tính năng phụ thuộc.
Lưu ý 2:
- Bất cứ khi nào chúng tôi so sánh hai báo cáo Bug để tìm xem nó có trùng lặp hay không, chúng tôi luôn phải xem xét hai điều, như sau:
- Các bước điều hướng phải giống nhau.
- Ngoài trạng thái đóng, bất kỳ trạng thái nào khác sẽ tồn tại, chúng ta không nên ghi lại một Bug, nếu không nó sẽ trở thành một Bug trùng lặp như chúng ta có thể thấy trong hình ảnh dưới đây:
Not Reproducible
Developers chấp nhận Bug, nhưng không thể tái tạo do một số lý do.
Đây là những Bug mà Developers không thể tìm thấy nó, sau khi trải qua bước điều hướng do kỹ sư kiểm tra đưa ra trong báo cáo Bug.
Lý do cho tình trạng không thể tái tạo của Bug như sau:
- Báo cáo Bug không đầy đủ
- Kỹ sư Kiểm tra đã không đề cập đến các bước điều hướng hoàn chỉnh trong báo cáo.
- Môi trường không phù hợp
- Môi trường không phù hợp có thể được mô tả theo hai cách:
- Máy chủ không khớp
- Nền tảng không phù hợp
Máy chủ không khớp: Kỹ sư kiểm tra đang sử dụng một máy chủ khác (Máy chủ kiểm tra) và Developers đang sử dụng máy chủ khác (Máy chủ phát triển) để tạo lại Bug như chúng ta có thể thấy trong hình ảnh bên dưới:
Nền tảng không khớp: Kỹ sư kiểm tra sử dụng Nền tảng khác (cửa sổ 7 và trình duyệt Google Chrome) và cả Developers sử dụng Nền tảng khác (window XP và internet explorer).
Dữ liệu không khớp: Các giá trị khác nhau được kỹ sư kiểm thử sử dụng trong khi kiểm tra & Developers sử dụng các giá trị khác nhau.
Xây dựng không phù hợp: Kỹ sư kiểm tra sẽ tìm thấy Bug trong một Bản dựng và Developers đang tạo lại Bug tương tự trong một bản dựng khác. Bug này có thể được sửa tự động trong khi sửa một Bug khác.
Bug không nhất quán: Bug được tìm thấy vào một lúc nào đó, và đôi khi nó sẽ không xảy ra.
Giải pháp cho Bug không nhất quán:
- Ngay sau khi chúng tôi tìm thấy Bug, trước tiên, hãy chụp ảnh màn hình, sau đó Developers sẽ xác nhận lại Bug và sửa nếu tồn tại.
Can’t fix
Khi Developers chấp nhận Bug và cũng có thể tái tạo, nhưng không thể thực hiện các thay đổi mã cần thiết do một số ràng buộc.
Lý do cho tình trạng không thể khắc phục của Bug
Sau đây là những hạn chế hoặc lý do không thể sửa Bug:
- Không hỗ trợ công nghệ: Bản thân ngôn ngữ lập trình chúng tôi sử dụng không có khả năng giải quyết vấn đề.
- Bug nằm trong cốt Bug của mã (khung): Nếu Bug nhỏ (không quan trọng và không ảnh hưởng đến ứng dụng), trưởng nhóm phát triển cho biết nó có thể được sửa trong bản phát hành tiếp theo.
- Hoặc nếu Bug nghiêm trọng (được sử dụng thường xuyên và quan trọng đối với doanh nghiệp) và trưởng nhóm phát triển không thể từ chối Bug.
- Chi phí sửa Bug nhiều hơn là giữ nó.
Ghi chú:
- Nếu bất kỳ Bug nào là nhỏ nhưng Developers không thể sửa nó, điều đó có nghĩa là Developers có thể sửa, nhưng Bug đang ảnh hưởng đến công nghệ hiện có vì nó đã có trong Bug của mã.
- Mỗi Bug không thể sửa là Bug nhỏ.
Deferred / postponed
Trì hoãn / hoãn lại là trạng thái trong đó các Bug được hoãn lại bản phát hành trong tương lai do hạn chế về thời gian.
Tình trạng hoãn lại của Bug không được khắc phục trong bản dựng ban đầu do thời gian hạn chế.
Như chúng ta có thể thấy trong hình ảnh dưới đây:
Bug Bug ID-B001 được tìm thấy ở bản ban đầu, nhưng nó sẽ không được sửa trong cùng bản dựng, nó sẽ bị hoãn và được sửa trong bản phát hành tiếp theo.
Và Bug ID- B0024, B0025 và B0026 là những Bug được tìm thấy trong giai đoạn cuối của quá trình xây dựng và chúng sẽ được sửa vì những Bug này là những Bug nhỏ.
Ghi chú:
- Tất cả các Bug nhỏ không thể được hoãn lại, nhưng tất cả các Bug được hoãn đều là Bug nhỏ.
- Bất cứ khi nào không có bản phát hành trong tương lai, thì Bug hoãn sẽ chỉ được sửa ở giai đoạn bảo trì.
RFE (Request for Enhancement)
Đây là những đề xuất được đưa ra bởi kỹ sư thử nghiệm nhằm nâng cao ứng dụng dưới dạng báo cáo Bug. RFE là viết tắt của Request for Enhancement.
Như chúng ta có thể thấy trong hình ảnh ví dụ dưới đây, kỹ sư thử nghiệm nghĩ rằng giao diện của ứng dụng hoặc phần mềm không tốt vì kỹ sư thử nghiệm đang thử nghiệm ứng dụng với tư cách là người dùng cuối và anh ấy / cô ấy sẽ thay đổi trạng thái như RFE.
Và nếu khách hàng nói Có, thì trạng thái sẽ được Khắc phục.
Hoặc là
Nếu khách hàng nói không, thì trạng thái sẽ là Đóng.
Mẫu báo cáo Bug (excel)
Mẫu báo cáo Bug như sau:
Hãy xem một ví dụ về báo cáo Bug:
Ở đây, chúng tôi đang mô tả một số thuộc tính quan trọng của báo cáo Bug.
ID Bug: nó là một số duy nhất được cấp cho Bug.
Test case name:: Khi chúng tôi tìm thấy Bug, chúng tôi sẽ gửi báo cáo Bug, không phải trường hợp thử nghiệm cho Developers liên quan. Nó được sử dụng làm tài liệu tham khảo cho kỹ sư thử nghiệm.
Severity: Đó là tác động của một Bug trên ứng dụng. Nó có thể là một người chặn, quan trọng, chính và phụ.
Priority: Trong điều này, chúng ta phải quyết định Bug nào phải được sửa trước. Nó có thể là P1 / P2 / P3 / P4, khẩn cấp, cao, trung bình và thấp.
Status: Các trạng thái khác nhau của Bug có thể Assigned, không hợp lệ, trùng lặp, hoãn lại, v.v.
Reporter: Trong này, chúng tôi sẽ đề cập đến tên của người đã tìm ra Bug. Đó có thể là kỹ sư thử nghiệm và đôi khi có thể là Developers, nhà phân tích kinh doanh, khách hàng, v.v.
Date: Nó cung cấp ngày mà Bug được tìm thấy.
Release/Build Version: Nó cung cấp số phát hành mà Bug xảy ra và cũng là phiên bản xây dựng của ứng dụng.
Platform: Đề cập đến chi tiết nền tảng, nơi chúng tôi tìm thấy chính xác Bug.
Description: Trong phần này, chúng tôi sẽ giải thích các bước điều hướng, kết quả mong đợi và thực tế của một Bug cụ thể.
Attachments: Đính kèm ảnh chụp màn hình của Bug mà chúng tôi đã chụp lại vì nó giúp các Developers nhìn thấy Bug.
Mặt trái của báo cáo Bug thủ công
Sau đây là những nhược điểm của báo cáo Bug thủ công:
- Mất thời gian. Trong khi tìm kiếm mọi Bug trong báo cáo Bug, quá trình này sẽ mất thời gian.
- Khả năng xảy ra Bug của con người. Một Bug có thể được lặp lại, sai dữ liệu được đề cập trong báo cáo Bug và bỏ sót điều gì đó để thêm vào báo cáo Bug.
- Không an toàn. Bất kỳ ai cũng có thể thay đổi hoặc xóa nó.
- Quá trình tẻ nhạt. Không có kho lưu trữ tập trung
