Trong phần này, chúng ta sẽ khám phá về quá trình phát triển của lỗi (Bug) và các trạng thái khác nhau mà một Bug có thể trải qua, cũng như mẫu báo cáo Bug.
Vòng Đời của Bug
Vòng đời của Bug là quá trình mà một lỗi (bug) trong phần mềm trải qua từ khi nó được phát hiện cho đến khi nó được sửa chữa và đóng lại. Quá trình này giúp quản lý và theo dõi mọi lỗi trong phần mềm, từ khi nó được ghi nhận cho đến khi nó được giải quyết và kiểm tra lại. Vòng đời của Bug có thể bao gồm các trạng thái và các bước xử lý khác nhau, nhưng thường bao gồm các giai đoạn chính sau:
- Phát Hiện (New/Open): Bug được phát hiện khi kỹ sư kiểm thử hoặc người dùng cuối gặp phải sự cố hoặc lỗi trong phần mềm.
- Chỉ Định (Assigned): Bug mới được gán cho một nhóm hoặc nhân viên có trách nhiệm giải quyết vấn đề.
- Sửa (Fixed): Nhóm phát triển sửa lỗi, thường bằng cách thực hiện các thay đổi trong mã nguồn của phần mềm.
- Kiểm Tra Lại (Reopened): Kỹ sư kiểm thử kiểm tra lại bug để đảm bảo rằng sửa chữa đã được thực hiện đúng và không tạo ra các vấn đề phụ khác.
- Đóng (Closed): Nếu bug đã được sửa và kiểm tra lại thành công, nó được đóng và không còn được xem xét hay theo dõi nữa.
Các trạng thái khác như “Mở Lại (Reopened)” có thể xuất hiện nếu bug xuất hiện lại sau khi đã được đóng. Quá trình này giúp đảm bảo rằng tất cả các lỗi đã được giải quyết một cách hiệu quả và đảm bảo tính ổn định của phần mềm.
Ai Được Gán Bug?
Bug có thể được gán cho các đối tượng sau:
- Developers (Nhà Phát Triển): Nếu chúng ta biết rõ ai là người đã phát triển mô-đun cụ thể.
- Developers Lead (Nhóm Lãnh Đạo Phát Triển): Nếu chúng ta không biết chính xác ai trong nhóm phát triển đã thực hiện mô-đun đó.
- Test Lead (Nhóm Lãnh Đạo Kiểm Thử): Khi không có tương tác nào giữa chúng tôi và nhóm phát triển và chúng tôi muốn chỉ định bug.
Khi Bug được sửa và đóng hoặc nếu nó ảnh hưởng đến mô-đun khác, chúng tôi sẽ tạo một báo cáo Bug mới.
HOẶC LÀ
Khi tình trạng Bug mở lại và tác động đến mô-đun khác, chúng ta cũng sẽ chuẩn bị một báo cáo Bug mới.
Lưu ý 2:
Mỗi khi chúng ta phát hiện một Bug và Developers sửa nó, chúng ta cần kiểm tra kỹ vùng ảnh hưởng.
Nếu Bug cũ được sửa chính xác, hãy chuyển trạng thái thành Đóng.
Nếu chúng ta phát hiện Bug vẫn tồn tại hoặc không được sửa đúng cách, chúng ta sẽ chuyển trạng thái thành Mở Lại.
Hoặc, nếu chúng ta phát hiện khu vực ảnh hưởng của Bug, chúng ta có thể thay đổi trạng thái thành Mới hoặc tạo một Bug mới để báo cáo.
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 thử lập Báo cáo Bug với thông tin không chính xác do hiểu lầm về yêu cầu, Developers sẽ không chấp nhận Bug và chuyển trạng thái sang “Không Hợp Lệ” để gửi lại (Sự hiểu lầm cũng có thể xảy ra từ phía Developers).
Bất kỳ Bug nào mà Developers từ chối chấp nhận đều được xem là Bug không hợp lệ.
Nguyên Nhân Của Trạng Thái Bug Không Hợp Lệ
Sự không hợp lệ của Bug có thể xuất hiện vì các lý do sau:
- Kỹ sư kiểm thử hiểu lầm yêu cầu.
- Developers hiểu lầm yêu cầu.
Hãy xem xét một ví dụ mô phỏng tình huống khi cả Kỹ sư kiểm thử và Developers đều hiểu lầm về yêu cầu, như thể hiện trong hình ảnh dưới đây:
Duplicate
Khi một Bug đã được báo cáo nhiều lần bởi các kỹ sư kiểm thử khác nhau, chúng ta nói đó là một trường hợp Bug trùng lặp.
Lý do dẫn đến tình trạng trùng lặp Bug có thể bao gồm:
- Các Tính Năng Chung:
Ví dụ: Kỹ sư kiểm thử P và Q đều thực hiện kiểm thử đăng nhập ứng dụng. Kỹ sư P gặp một Bug khi nhấp vào nút đăng nhập, và sau đó, Kỹ sư Q cũng gặp Bug tương tự khi thực hiện cùng một bước. Khi Developers nhận được báo cáo Bug từ cả hai kỹ sư kiểm thử, họ có thể xác định đó là một Bug trùng lặp.
- Mô-đun Phụ Thuộc:
Trong trường hợp khi một mô-đun phụ thuộc vào một mô-đun khác, một Bug tìm thấy trong mô-đun đầu tiên có thể ảnh hưởng đến các thử nghiệm trong mô-đun phụ thuộc. Điều này có thể dẫn đến việc báo cáo nhiều lần về cùng một lỗi.
Phòng Ngừa Bug Trùng Lặp:
- Kiểm Tra Kho Lưu Trữ Bug:
- Nếu Developers nhận được một Bug mới, họ sẽ kiểm tra trong kho lưu trữ Bug để đảm bảo rằng nó không trùng lặp với các Bug đã được báo cáo trước đó.
- Tính Công Bằng Trong Xác Định Trùng Lặp:
- Khi so sánh hai báo cáo Bug để xác định tính trùng lặp, cần xem xét cả bước điều hướng và trạng thái của Bug. Chúng ta không chỉ tìm kiếm từng Bug một cách cụ thể trong kho lưu trữ, mà còn xem xét tính tương đồng về tính năng và phụ thuộc.
- Giữ Thông Tin Chính Xác:
- Để tránh Bug trùng lặp, cần duy trì thông tin chính xác và chi tiết trong các báo cáo Bug, bao gồm cả bước điều hướng và mô-đun phụ thuộc.
Tổng cộng, quản lý và phòng tránh Bug trùng lặp đòi hỏi sự chú ý đặc biệt vào việc duy trì thông tin đầy đủ và chính xác trong quá trình quản lý Bug.
Not Reproducible
Một số Bug có thể được Developers chấp nhận nhưng gặp khó khăn khi cố gắng tái tạo chúng, vì một số lý do cụ thể.
Dưới đây là những lý do khiến việc tái tạo Bug trở nên khó khăn:
- Báo Cáo Bug Thiếu Thông Tin:
- Nếu báo cáo Bug không cung cấp đủ thông tin chi tiết, Developers có thể gặp khó khăn khi cố gắng tái tạo vấn đề. Điều này có thể bao gồm thiếu các bước điều hướng quan trọng hoặc mô tả không rõ ràng.
- Không Đề Cập Đến Bước Điều Hướng Hoàn Chỉnh:
- Nếu Kỹ sư Kiểm tra không đề cập đến tất cả các bước điều hướng trong báo cáo Bug, việc tái tạo sẽ trở nên khó khăn cho Developers. Một hướng dẫn chi tiết là quan trọng để giúp nhóm phát triển xác định và sửa lỗi.
- Môi Trường Không Phù Hợp:
- Môi trường khác nhau giữa Kỹ sư Kiểm tra và Developers có thể dẫn đến khả năng không thể tái tạo Bug. Các khía cạnh của môi trường bao gồm máy chủ không khớp, nền tảng không khớp và dữ liệu không khớp.
- Máy chủ không khớp: Sự khác biệt giữa máy chủ kiểm tra và máy chủ phát triển có thể dẫn đến sự không nhất quán trong việc tái tạo.
- Nền tảng không khớp: Sự khác biệt giữa nền tảng của Kỹ sư Kiểm tra và Developers cũng là một nguyên nhân khó khăn khi tái tạo Bug.
- Dữ liệu không khớp: Sự không tương thích trong các giá trị dữ liệu sử dụng để kiểm thử và phát triển cũng có thể tạo ra khả năng không thể tái tạo.
- Xây Dựng Không Phù Hợp:
- Nếu Bug được tìm thấy trong một bản dựng cụ thể và Developers đang sử dụng một bản dựng khác, có thể gây khó khăn trong việc tái tạo vấn đề.
- Bug Không Nhất Quán:
- Bug có thể xuất hiện không nhất quán, không lặp lại trong mọi trường hợp và không dễ dàng tái tạo.
Giải Pháp cho Bug Không Nhất Quán:
- Để giải quyết vấn đề Bug không nhất quán, sau khi phát hiện Bug, việc chụp ảnh màn hình là quan trọng. Sau đó, Developers có thể xác nhận lại Bug và tiến hành sửa lỗi nếu cần thiết, có hình ảnh là một nguồn chứng cứ hữu ích.
Can’t fix
Khi Developers chấp nhận Bug nhưng gặp khó khăn trong việc thực hiện các thay đổi mã cần thiết do một số ràng buộc, có những hạn chế và lý do cụ thể không thể khắc phục vấn đề đó.
Dưới đây là những hạn chế và lý do không thể sửa Bug:
Không Hỗ Trợ Công Nghệ:
- Môi trường lập trình chúng ta sử dụng có thể không có khả năng giải quyết vấn đề của Bug. Ngôn ngữ lập trình cụ thể này có thể không cung cấp các công cụ hoặc tính năng cần thiết để sửa lỗi một cách hiệu quả.
Bug Nằm Trong Cốt Bug của Mã (Khung):
- Nếu Bug được coi là nhỏ (không quan trọng và không ảnh hưởng đến ứng dụng), trưởng nhóm phát triển có thể quyết định rằng nó có thể đợi đến bản phát hành tiếp theo để được sửa. Tuy nhiên, nếu Bug là một phần quan trọng của hệ thống (được sử dụng thường xuyên và quan trọng đối với doanh nghiệp), trưởng nhóm phát triển có thể không thể từ chối sửa Bug ngay lập tức.
Chi Phí Sửa Bug Nhiều Hơn Lợi Ích:
- Trong một số trường hợp, chi phí để sửa một Bug có thể cao hơn so với lợi ích mà sự sửa đổi mang lại. Trong tình huống này, quyết định giữ Bug không sửa có thể được đưa ra dựa trên tính kinh tế và chiến lược phát triển.
Ghi Chú:
- Nếu có bất kỳ Bug nhỏ nào mà Developers không thể sửa, điều đó có thể do Bug ảnh hưởng đến công nghệ hiện tại, vì nó nằm trong cốt lõi (khung) của mã nguồn. Mỗi Bug không thể sửa đều được xem xét như là một Bug nhỏ, nhưng đôi khi chúng có ảnh hưởng đáng kể đối với hệ thống tổng thể.
Deferred / postponed
Trạng thái Trì hoãn/Hoãn lại là khi các Bug được chọn để hoãn lại và sẽ được xử lý trong các bản phát hành sau đó do hạn chế về thời gian.
Tình trạng hoãn lại của Bug không cho phép khắc phục trong bản dựng ngay lúc đầu do những hạn chế về thời gian.
Như hình dưới đây mô tả:
Bug có ID-B001 đã được phát hiện trong bản dựng ban đầu, nhưng thay vì sửa ngay trong bản dựng đó, nó sẽ được hoãn lại và chờ đến bản phát hành tiếp theo để tiến hành xử lý.
Còn với Bug có ID-B0024, B0025 và B0026, chúng xuất hiện trong giai đoạn cuối của quá trình xây dựng và sẽ được sửa lỗi, vì chúng được xem xét là những Bug nhỏ.
Lưu ý:
- Tất cả các Bug nhỏ không nhất thiết phải được hoãn lại, nhưng mọi Bug được hoãn lại đều được coi là những Bug nhỏ.
- Trong trường hợp không có bản phát hành dự kiến trong tương lai, Bug bị hoãn lại sẽ chỉ được xử lý khi chúng ta đến giai đoạn bảo trì.
RFE (Request for Enhancement)
Dưới đây là những đề xuất được đưa ra bởi kỹ sư thử nghiệm nhằm cải thiện hiệu suất của ứng dụng thông qua việc báo cáo các cải tiến yêu cầu (RFE – Request for Enhancement).
RFE là một từ viết tắt chỉ yêu cầu cải tiến.
Trong ví dụ ảnh dưới đây, kỹ sư thử nghiệm đánh giá rằng giao diện của ứng dụng hoặc phần mềm có thể được cải thiện. Điều này xuất phát từ trải nghiệm sử dụng của kỹ sư thử nghiệm với vai trò người dùng cuối. Anh ấy / cô ấy sẽ thay đổi trạng thái của một yêu cầu cải tiến.
Nếu khách hàng chấp nhận yêu cầu cải tiến, trạng thái của nó sẽ chuyển sang “Đang xử lý”.
Ngược lại, nếu khách hàng từ chối, 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.
