Redmine Cho Tester Fresher: Hướng Dẫn Sử Dụng Cơ Bản Quản Lý Bug
6 tháng trước · 7 phút đọc
Redmine là gì và tại sao công ty Việt Nam hay dùng?
Bạn vừa pass vòng phỏng vấn tester, ngày đầu đi làm được assign vào project - và thấy một cái tool lạ hoắc tên Redmine. Không phải Jira. Không phải Trello. Là Redmine.
Redmine là phần mềm quản lý dự án mã nguồn mở (open-source), miễn phí hoàn toàn. Đây là lý do chính khiến rất nhiều công ty vừa và nhỏ tại Việt Nam - đặc biệt các công ty outsource Nhật Bản - chọn Redmine thay vì Jira. Jira của Atlassian tính phí theo số lượng user, còn Redmine thì không.
Redmine miễn phí và mã nguồn mở - lý do nhiều công ty outsource Việt chọn dùng
Về chức năng, Redmine làm được những thứ cơ bản mà tester cần hằng ngày: tạo issue (bug, task, feature request), theo dõi trạng thái xử lý, attach file/screenshot, comment trao đổi với dev, và xem lịch sử thay đổi. Đủ dùng cho workflow tester thông thường.
Một điểm nữa: nhiều dự án outsource cho khách Nhật, Hàn dùng Redmine như công cụ tiêu chuẩn. Biết Redmine = bạn fit vào được nhiều dự án hơn.
Làm quen với giao diện Redmine trong 5 phút
Lần đầu nhìn vào Redmine, bạn sẽ thấy giao diện khá cũ - không đẹp như Jira hay Linear. Nhưng đừng để UI đánh lừa. Sau khi biết chỗ nào làm gì, bạn dùng quen rất nhanh.
Các khu vực cần biết ngay:
Projects - thanh menu trên cùng. Click vào tên project bạn được assign để vào.
Issues - menu con quan trọng nhất với tester. Đây là nơi tạo bug, xem danh sách bug, lọc theo trạng thái.
My page - trang tổng quan cá nhân, hiển thị issue được assign cho bạn. Mỗi sáng đầu ngày nên check ở đây.
Activity - lịch sử hoạt động của project theo ngày. Tiện để xem dev đã update gì, ai đổi trạng thái issue nào.
My page là nơi đầu tiên cần check mỗi sáng - xem issue nào đang chờ bạn
Trong menu Issues, bạn sẽ thấy các filter mặc định: Open issues, My open issues, Reported by me. Khi mới vào, chọn My open issues để xem những gì dev đang cần bạn verify, hoặc Reported by me để xem bug bạn đã log.
Một mẹo nhỏ: bookmark thẳng URL của trang Issues project bạn đang làm. Mỗi ngày chỉ cần vào đó là làm việc được, không cần click nhiều bước.
Cách tạo bug report trên Redmine từng bước
Mình nhớ lần đầu log bug trên Redmine, điền thiếu mục Priority và Assignee, dev không biết bug quan trọng cỡ nào và không ai nhận xử lý. Bug nằm đó 3 ngày không ai động vào. Từ đó mình học: điền đủ trường, đừng bỏ qua.
Đây là các bước tạo một bug report chuẩn:
Bước 1: Vào Issues > New Issue
Trong project của bạn, click Issues > nút New issue góc phải trên.
Bước 2: Chọn Tracker = Bug
Field Tracker cho phép chọn loại: Bug, Feature, Support, Task. Với tester, bạn sẽ dùng Bug chủ yếu.
Bước 3: Điền Subject (tiêu đề)
Viết ngắn gọn, đủ ý. Công thức tốt: [Màn hình] + [Hành động] + [Kết quả sai]
- Tốt:
[Đăng nhập] Nhập đúng mật khẩu vẫn báo lỗi sai mật khẩu - Không tốt:
Lỗi đăng nhập
Bước 4: Chọn Priority
Redmine thường có 5 mức: Immediate, Urgent, High, Normal, Low. Đừng để mặc định Normal cho tất cả - bug crash app hoặc mất tiền user phải là Urgent/Immediate.
Bước 5: Assign cho đúng người
Field Assigned to: chọn dev phụ trách tính năng đó. Hỏi team lead nếu chưa biết ai phụ trách gì.
Bước 6: Điền Description theo template
Phần này quan trọng nhất. Mình hướng dẫn chi tiết ở section tiếp theo.
Điền đủ 6 trường từ đầu - dev nhận bug mới có đủ thông tin để fix
Bước 7: Attach file screenshot/video
Click Files ở cuối form, đính kèm screenshot có đánh dấu vùng lỗi. Bug có ảnh = dev fix nhanh hơn 50% vì không mất công reproduce.
Template bug report chuẩn để dùng ngay trong Redmine
Phần Description là nơi nhiều fresher viết sơ sài nhất. "Bấm vào nút thì lỗi" - dev đọc xong vẫn không biết reproduce thế nào. Template dưới đây mình dùng từ năm đầu và vẫn dùng đến giờ.
Copy template này vào Description mỗi khi tạo bug:
**Môi trường:**
- OS: Windows 11 / macOS 14 / Android 13...
- Browser: Chrome 124 / Firefox 125...
- App version: 1.2.3
- Môi trường: Staging / Production
**Bước tái hiện (Steps to Reproduce):**
1. Mở trang [tên trang]
2. Nhập [dữ liệu cụ thể]
3. Click [tên nút]
4. Quan sát
**Kết quả thực tế (Actual Result):**
[Mô tả rõ điều gì xảy ra - kèm error message nếu có]
**Kết quả kỳ vọng (Expected Result):**
[Hệ thống đáng lẽ phải làm gì]
**Tần suất xảy ra:**
[ ] Luôn luôn (100%) [ ] Thỉnh thoảng (~50%) [ ] Hiếm (<10%)
**Mức độ ảnh hưởng:**
[Bug này ảnh hưởng gì đến user? Có chặn flow chính không?]
Template đủ 6 phần - dev đọc là reproduce được ngay, không cần hỏi lại
Tại sao cần Bước tái hiện chi tiết? Vì dev không ngồi cạnh bạn. Họ phải tự reproduce bug trên máy mình. Nếu bước không đủ chi tiết, họ sẽ comment "Không reproduce được" - và bug lại bay về bạn, mất thêm 1-2 ngày.
Kết quả thực tế vs Kết quả kỳ vọng là cặp quan trọng nhất. Nhiều fresher chỉ viết actual result mà không viết expected - dev sẽ không biết behavior đúng là gì, dễ fix sai.
Tải template này về để dùng ngay: Tải template bug report Redmine
Theo dõi và cập nhật trạng thái issue
Tạo bug xong không phải là hết việc. Theo dõi issue đến khi Closed mới là xong.
Redmine dùng hệ thống trạng thái (status) để track vòng đời của bug. Workflow thông thường:
| Trạng thái | Người thực hiện | Ý nghĩa |
|---|---|---|
| New | Tester tạo | Bug vừa được log |
| In Progress | Dev nhận | Dev đang fix |
| Resolved | Dev đổi | Dev đã fix, chờ verify |
| Closed | Tester đổi | Verified - bug đã fix đúng |
| Rejected | Dev/Lead đổi | Không phải bug, là feature |
| Reopened | Tester đổi | Verify xong vẫn còn lỗi |
Khi bug chuyển sang Resolved, bạn nhận được email notification (nếu đã bật). Đây là lúc bạn cần test lại (regression test - kiểm thử hồi quy) để xác nhận dev đã fix đúng.
Vòng đời bug từ New đến Closed - tester quản lý 2 đầu: tạo và verify
Nếu verify thấy bug vẫn còn: đổi status sang Reopened, comment rõ "Đã test lại trên build 1.2.4, lỗi vẫn xuất hiện. Steps: [...]" kèm screenshot mới. Đừng chỉ Reopen mà không comment - dev sẽ không biết bạn đã test gì.
Nếu verify thấy fix đúng: đổi sang Closed, comment ngắn "Verified on build 1.2.4 - PASS". Dù chỉ 1 dòng, comment này giúp team biết ai verify lúc nào.
Một điều mình thấy fresher hay bỏ qua: theo dõi bug của mình mỗi ngày. Dành 5-10 phút đầu giờ vào My page xem issue nào được Resolved, cần verify. Để lâu quá dev sẽ hỏi, mà bạn lại không nhớ context bug đó.
Mẹo dùng Redmine hiệu quả hơn cho fresher
Sau vài tháng đầu dùng Redmine, mình tổng hợp được một số thói quen giúp làm việc nhanh hơn và ít mắc lỗi hơn.
Dùng filter Issues thành thạo
Trang Issues có phần filter khá mạnh. Bạn có thể lọc theo: Assignee (ai đang xử lý), Status (đang ở giai đoạn nào), Priority (độ ưu tiên), Version (build nào). Mình thường lọc Status = Resolved + Assigned to = Me để thấy ngay danh sách bug cần verify.
Xem lịch sử thay đổi của issue
Mỗi issue Redmine lưu toàn bộ lịch sử: ai đổi field gì, lúc nào, comment gì. Phần History nằm cuối trang issue. Khi có tranh cãi về bug, đây là nơi tra cứu.
Watcher - theo dõi issue không phải của mình
Bạn có thể click Watch trên issue bất kỳ để nhận notification khi issue đó có thay đổi. Hữu ích khi muốn theo dõi bug nghiêm trọng mà dev đang xử lý.
Ba tính năng ít được chú ý nhưng tiết kiệm nhiều thời gian mỗi ngày
Viết comment rõ ràng
Tránh comment kiểu "test lại rồi". Thay vào đó: "Đã verify trên Chrome 124, Windows 11, build 2.1.3 ngày 15/01. Lỗi không còn xuất hiện. Closing."
Bật email notification
Vào My account > Email notifications, chọn nhận thông báo cho issue được assign cho bạn và issue bạn đã tạo. Không bật thì dev Resolve xong bạn không biết, để bug đó treo dài.
Thấy khó quen với Redmine bình thường - mình cũng mất cả tuần đầu mới nhớ workflow. Nhưng chỉ cần nhớ: New > In Progress > Resolved > Closed là bạn đã có nền tảng để làm việc được rồi. Phần còn lại tự khắc quen khi làm hằng ngày.
Nếu bạn muốn học bài bản hơn về testing từ đầu - từ viết test case, log bug, đến regression test - khóa Kiểm thử phần mềm có thể là điểm bắt đầu tốt, đặc biệt nếu bạn đang chuyển ngành vào QA.
Bắt đầu thực hành với Redmine demo
Đọc lý thuyết xong mà không có môi trường thực hành thì cũng khó nhớ. Redmine có server demo công khai để bạn thử trước khi vào dự án thật.
Truy cập Redmine demo tại: Redmine Demo Server
Trên server demo, bạn có thể:
- Tạo issue mới với đầy đủ các trường
- Thử thay đổi status, priority
- Đính kèm file, viết comment
- Xem filter hoạt động thế nào
Mình khuyên bạn thực hành theo đúng quy trình: tạo 3-5 bug report giả cho một app tưởng tượng (ví dụ: app đặt đồ ăn), điền đủ template, rồi tự verify và close. Làm vòng đó 2-3 lần là nhớ workflow.
Thực hành trên môi trường demo trước - không sợ làm hỏng dữ liệu thật
Ngoài Redmine, một số công ty Việt dùng thêm Backlog (tool của Nhật, UX đẹp hơn Redmine) hoặc GitLab Issues (nếu team dùng GitLab). Workflow log bug và theo dõi issue về cơ bản giống nhau - chỉ khác giao diện. Biết Redmine thành thạo, bạn chuyển sang tool khác trong 1-2 ngày là quen.
Tóm lại, để làm việc được với Redmine ngay từ ngày đầu:
- Nhớ workflow: New > In Progress > Resolved > Verify > Closed
- Điền đủ trường khi tạo bug: Subject, Priority, Assignee, Description theo template
- Bật email notification để không bỏ lỡ update
- Dành 5-10 phút mỗi sáng check My page
- Comment rõ ràng mỗi khi thay đổi status
Bạn có câu hỏi gì về Redmine hoặc workflow tester nói chung, comment bên dưới - mình trả lời từng bạn. Chúc thực hành vui!