Sau khi phát hiện ra bug Tester sẽ làm gì?

Các vấn đề liên quan đến bug/defect và các hệ thống quản lý lỗi
Forum rules
Các bạn chỉ được phép post bài liên quan đến bug/defect và các hệ thống quản lý lỗi.
Post Reply
hoangliensonmt
Jr. Tester
Posts: 88
Joined: Mon 26 Jul, 2010 5:42 pm
Contact:

Sau khi phát hiện ra bug Tester sẽ làm gì?

Post by hoangliensonmt » Mon 23 Aug, 2010 2:24 pm

Sau khi phát hiện ra bug Tester sẽ làm gì?

The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:

* Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
* Bug identifier (number, ID, etc.)
* Current bug status (e.g., 'Released for Retest', 'New', etc.)
* The application name or identifier and version
* The function, module, feature, object, screen, etc. where the bug occurred
* Environment specifics, system, platform, relevant hardware specifics
* Test case name/number/identifier
* One-line bug description
* Full bug description
* Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
* Names and/or descriptions of file/data/messages/etc. used in test
* File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
* Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
* Was the bug reproducible?
* Tester name
* Test date
* Bug reporting date
* Name of developer/group/organization the problem is assigned to
* Description of problem cause
* Description of fix
* Code section/file/module/class/method that was fixed
* Date of fix
* Application version that contains the fix
* Tester responsible for retest
* Retest date
* Retest results
* Regression testing requirements
* Tester responsible for regression tests
* Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

Thường các công ty phát triển phần mềm thường sử dụng chương trình quản lý bug riêng của mình hoặc các phần mềm open soucre được ưa chuộng như Mantis, Bugzilla,...
Những mô tả trên đều được mô tả trong các công cụ quản lý bug này.



tvn
Admin
Posts: 4900
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Re: Sau khi phát hiện ra bug Tester sẽ làm gì?

Post by tvn » Mon 20 Dec, 2010 8:49 am

~~Bản dịch sang Tiếng Việt~~

Bug phát hiện được cần phải liên hệ và phân công cho DEV chịu trách nhiệm sửa lỗi này (người phụ trách fix bug màn hình mà mình đã tìm ra bug). Sau khi bug đã được fix xong thì các lỗi này cần phải test lại và quyết tâm thực hiện các yêu cầu liên quan đến kiểm thử hồi qui để kiểm tra việc kiểm tra lỗi không làm phát sinh thêm các vấn đề khác. Nếu có sử dụng hệ thống quản lý lỗi thì nó sẽ gói gọn các qui trình sau. Trên thị trường đang có sẵn hàng loạt các công cụ phần mềm quản lý/theo dõi lỗi (Xem phần "Công cụ quản lý lỗi" để biết thêm về danh sách này). Các hạng mục sau đây có thể có trong qui trình quản lý bug:

* Thông tin đầy đủ để DEV có thể hiểu được lỗi, để cho ý kiến về mức độ nghiêm trọng của lỗi, đoán được nó bị lỗi ở chỗ nào và có thể tái hiện lỗi khi cần.
* Mã lỗi (ví dụ như số hoặc ID v.v...)
* Trạng thái của bug hiện tại (ví dụ như 'Released for Retest', 'New', v.v...)
* Tên hoặc ID và phiên bản của ứng dụng
* Hàm, mô đun, chức năng, đối tượng, màn hình,... xảy ra lỗi.
* Các mô tả môi trường, hệ thống, platform, và phần cứng liên quan
* Tên/ số/ ID của test case
* Một dòng mô tả lỗi
* Mô tả đầy đủ
* Mô tả các bước cần để tái hiện bug nếu không bao gồm trong test case hoặc nếu DEV truy cập test case/test script/test tool khó khăn.
* Tên và/hoặc các mô tả về file/data/messages/v.v... sử dụng trong lúc test
* Các trích đoạn file/các thông báo lỗi/trích đoạn file log/chụp màn hình/log của test tool để giúp ích trong việc tìm ra lỗi của vấn đề.
* Ước lượng mức độ nghiêm trọng (thường là một phạm vi 5 mứcnhư từ 1 đến 5 hoặc từ 'critical' đến 'low')
* Bug có tái hiện lại được không?
* Tên Tester
* Ngày test
* Ngày báo cáo Bug
* Tên của DEV/Nhóm/Tổ chức được phân công (assigned) sửa bug
* Mô tả nguồn gốc nguyên nhân lỗi
* Mô tả việc sửa chữa lỗi
* Đoạn Code/file/module/class/method mà đã fixed
* Ngày fix
* Phiên bản ứng dụng đã fix
* Tester chịu trách nhiệm test lại
* Ngày test lại
* Kết quả test lại
* Các yêu cầu test hồi qui
* Tester chịu trách nhiệm thực hiện test hồi qui
* Kết quả test hồi qui

Một bản báo cáo hoặc một qui trình quản lý lỗi nên cho phép thông báo đến người được phân công trong từng giai đoạn. Ví dụ, các tester cần phải biết khi nào cần test lại, các developer cần biết khi nào có bug và làm thế nào để lấy những thông tin cần thiết và báo cáo/tóm tắt các khả năng cần thiết cho quản lý.

Tham khảo danh sách các công cụ quản lý lỗi tại mục Công cụ quản lý lỗi - Bug tracking/management system

Mong các bạn đóng góp ý kiến để nội dung của bản dịch ngày càng tốt hơn và chính xác hơn.



Post Reply

Return to “Bug Tracking/Management System - Bug và Công cụ Quản lý Bug”