Trước đây, Bug Tracking System (BTS) là hệ thống trao đổi thông tin giữa Lập Trình Viên (LTV) và Kiểm Thử Viên (Tester-KTV). Hiện nay BTS được mở rộng ra thành hệ thống quản lý ticket, trong đó ticket có thể là bug (lỗi lập trình), defect (lỗi do thiết kế sai yêu cầu), feedback/support (phản hồi từ khách hàng), feature (yêu cầu nâng cấp tính năng), các yêu cầu nghiệp vụ mới (requirement), dịch vụ gia tăng (request service) … Để cho dễ hiểu, ticket có thể dịch ra tiếng Việt một cách chung chung là “công việc”.

Xem thêm: Quy trình kiểm soát lỗi TIGO BugKiller

Thí dụ: Quy trình vòng đời bug tracking life cycle

Đối tượng: Tất cả Developer, Tester, Chăm sóc khách hàng (CSKH) đều có thể tạo ra các công việc, các yêu cầu (request). Tập hợp tất cả các yêu cầu, lỗi, kịch bản test (Test Case), kiến nghị (Inquiry)... ta gọi chung là Ticket.

Quản lý danh sách công việc:
Mỗi project sẽ có danh sách các công việc (link ở vị trí thứ 3 trên MenuBar). Các công việc có mức ưu tiên “Cao” sẽ được highlight màu đỏ nổi bật.

Chức năng Sort: Click vào tên cột sẽ sắp xếp dữ liệu cột theo A...Z và ngược lại.

Chức năng Filter: Chức năng “lọc” trên grid khá mạnh, với khá nhiều điều kiện lọc và các toán tử logic phức tạp. Mặc định sẽ lọc theo “Trạng Thái”. Các điều kiện lọc khác cũng hay được quan tâm là: Mức ưu tiên, Kiểu công việc, Tác giả, Người được phân công, Chủ đề.

Chức năng Option (Tùy chọn): Cho phép ẩn/hiện các cột (grid động). 

Tạo công việc mới:

Thông báo email: Mỗi một công việc được tạo ra sẽ được gửi đến những người liên quan (người tạo, người được phân công, người trong danh sách quan sát/theo dõi).

Phân loại công việc: Được chia làm 5 nhóm chính như sau

Một bản mô tả bug đầy đủ cần có các thông tin như sau:

Attach hình ảnh: Bạn có thể gắn hình ảnh trực tiếp lên RedMine, hoặc upload ảnh lên cloud bên ngoài (thí dụ imgur.com là dịch vụ kho ảnh miễn phí hàng đầu thế giới).

CÁC NGUYÊN TẮC:
1. Nhóm CSKH nên tạo một project riêng để lưu trữ các thông tin phản hồi từ khách hàng hoặc các công việc được tìm thấy ở cấp độ cao nhất (high-level). Nếu công việc nào đã được duyệt để sửa, thì Tester có thể move sang project của nhóm kỹ thuật để phân công cho PM trước (PM sau đó sẽ phân công LTV phù hợp ở một thời điểm thích hợp).

2. Các công việc cần mô tả chi tiết các bước thao tác, kết quả thực tế xảy ra, kết quả mong muốn và các thông tin bổ sung (metadata) khác như: có dễ biểu diễn lại hay không, có thường xuyên xuất hiện hay không, có khiến chương trình không thể tiếp tục vận hành (lỗi dạng này gọi là showstopper bug). Ngoài ra nên gắn kèm ảnh chụp màn hình để người đọc hình dung tốt hơn về flow của công việc. 

3. Các issues không phù hợp với giai đoạn hiện tại (thí dụ bug về tốc độ load chậm không thể giải quyết ở giai đoạn đầu của vòng đời dự án) thì cần lưu nháp (Riêng tư) hoặc lưu tạm đâu đó (thí dụ local Excel) trước khi post lên IMS. 

 

Rule of thumb: Issue phải được phân công cho người phù hợp ở một thời điểm thích hợp.

4. Thận trọng khi đánh dấu mức độ ưu tiên công việc là “Cao” hoặc “Khẩn cấp”. Có những công việc ở phase 1 là “Thấp”, nhưng khi sang phase 2 sẽ chuyển trạng thái sang “Cao”.

5. Nếu LTV chưa thể giải quyết được ngay công việc, thì nên comment càng sớm càng tốt. Trước mắt đề xuất giải pháp sơ bộ, các hướng xử lý và có thể là thời hạn dự kiến để xử lý.

Tác giả: TIGO Engineering Team