Redmine Cho Fresher Tester: Hướng Dẫn Log Bug Đầu Tiên

6 tháng trước · 13 phút đọc

Redmine là gì và tại sao fresher tester cần biết?

Mình nhớ lần đầu được giao task: "Em log bug lên Redmine nhé." Mình gật đầu, mở máy tính, rồi... ngồi im 10 phút vì không biết Redmine là gì, bắt đầu từ đâu.

Nếu bạn đang ở đúng tình huống đó, bài này viết cho bạn.

Redmine là một công cụ quản lý dự án và theo dõi lỗi (issue tracker) mã nguồn mở. Nói đơn giản hơn: đây là nơi team tester ghi lại tất cả bug tìm được trong quá trình kiểm thử, để dev biết cần fix gì, fix xong chưa, fix có đúng không.

343167 Redmine - nơi bug được ghi nhận và theo dõi từ lúc phát hiện đến lúc fix xong

Tại sao Redmine phổ biến trong đào tạo tester? Vì nó miễn phí, dễ cài đặt, và giao diện khá gần với các tool thương mại như Jira hay MantisBT. Học được Redmine, bạn sẽ dễ dàng chuyển sang các tool khác khi đi làm thực tế.

Theo Redmine nằm trong top các công cụ issue tracking được sử dụng rộng rãi, Redmine vẫn là một trong những công cụ issue tracking phổ biến nhất được sử dụng trong các team phát triển phần mềm tại Việt Nam và khu vực Đông Nam Á.

Một điều mình muốn nói thẳng: bạn không cần biết lập trình để dùng Redmine. Không cần hiểu code. Chỉ cần biết điền form và mô tả bug cho rõ ràng - kỹ năng đó ai cũng học được.

Truy cập và tạo tài khoản Redmine

Để thực hành ngay mà không cần cài đặt, bạn có thể dùng bản demo online miễn phí. Truy cập tại: Redmine Demo Online

Nếu công ty bạn đã có server Redmine riêng, dùng link họ cung cấp và bỏ qua bước đăng ký.

Đăng ký tài khoản (nếu dùng bản demo):

Vào trang chủ Redmine → Click "Register" ở góc trên phải → Điền thông tin:

Login: tên đăng nhập (viết thường, không dấu, ví dụ: nguyen_tester)
Password: mật khẩu ít nhất 8 ký tự
Email: email thật để xác nhận
First name / Last name: tên của bạn

343168 Điền đầy đủ, nhớ xác nhận email trước khi đăng nhập

Sau khi đăng ký xong và xác nhận email, đăng nhập vào. Giao diện Redmine khá đơn giản - phần quan trọng nhất là thanh menu ngang ở trên cùng và sidebar bên trái.

Một điểm mình hay thấy người mới nhầm: Redmine phân biệt Project (dự án) và Issue (công việc/bug). Mỗi bug phải thuộc về một project cụ thể. Nếu chưa có project nào, bạn phải tạo trước mới log bug được.

Tạo project đầu tiên trên Redmine

Project trong Redmine giống như một "thư mục" chứa tất cả công việc của một dự án phần mềm cụ thể. Bạn không thể log bug nếu chưa có project - vậy nên tạo ngay.

Bước 1: Click "Projects" trên thanh menu → chọn "New project"

Bước 2: Điền thông tin project:

Trường	Ý nghĩa	Ví dụ
Name	Tên project	`Ứng dụng bán hàng ABC`
Identifier	Mã định danh (URL) - tự động điền	`ung-dung-ban-hang-abc`
Description	Mô tả ngắn về dự án	`Dự án thực hành test của cá nhân`
Homepage	Website (không bắt buộc)	Để trống

343169 Identifier tự động tạo từ tên - không cần chỉnh tay

Bước 3: Phần Modules - đây là phần quan trọng. Đảm bảo tích chọn ít nhất:

Issue tracking - để log bug
Wiki (tùy chọn) - để ghi tài liệu

Bước 4: Click "Create".

Project vừa tạo sẽ xuất hiện trong danh sách Projects. Click vào tên project để vào trang quản lý. Từ đây bạn sẽ thấy các tab: Overview, Activity, Issues, Wiki... Tab Issues là nơi bạn sẽ làm việc nhiều nhất.

Cấu hình Issue tracker - Hiểu trước khi log bug

Trước khi log bug đầu tiên, bạn cần hiểu các trường trong Issue của Redmine. Đây là thứ mình ước được giải thích kỹ hơn từ đầu - vì hiểu sai thì bug report viết xong cũng vô dụng.

Tracker - loại công việc:

Bug: lỗi trong phần mềm (dùng cho testing)
Feature: tính năng mới cần làm
Support: yêu cầu hỗ trợ

Bạn là tester → chủ yếu dùng Bug.

Priority - mức độ ưu tiên:

Mức	Ý nghĩa thực tế
Immediate	Crash hệ thống, mất dữ liệu - fix ngay trong ngày
Urgent	Tính năng chính không dùng được
High	Bug ảnh hưởng nhiều user, có workaround tạm
Normal	Bug thường, ảnh hưởng nhỏ
Low	Lỗi nhỏ, giao diện, chính tả

343170 Hiểu đúng Priority giúp dev sắp xếp việc fix bug hiệu quả hơn

Status - trạng thái bug:

New: vừa log, chưa ai nhận
In Progress: dev đang fix
Resolved: dev fix xong, chờ tester verify
Closed: tester xác nhận đã fix
Rejected: không phải bug (spec đúng vậy)

Một lỗi fresher hay gặp: tạo bug xong để status Closed luôn. Status chỉ chuyển Closed khi bạn đã verify lại sau khi dev fix - không phải khi mới log.

Ngoài ra còn trường Assignee (giao cho ai fix) và Target version (dự kiến fix ở version nào). Hai trường này thường do team lead hoặc dev tự điền - bạn không cần điền ngay.

Log bug đầu tiên - từng bước một

Phần này là trọng tâm bài. Mình sẽ hướng dẫn bạn log một bug cụ thể, không nói chung chung.

Tình huống thực hành: Bạn đang test tính năng đăng nhập của một ứng dụng bán hàng. Phát hiện bug: nhập mật khẩu sai 5 lần liên tiếp nhưng hệ thống không khóa tài khoản như đặc tả yêu cầu.

Bước 1: Vào project → click tab "Issues" → click "New issue"

Bước 2: Điền thông tin bug

Dưới đây là cách điền từng trường:

Tracker: chọn Bug

Subject (Tiêu đề): Đây là trường quan trọng nhất. Format chuẩn:

[Tên tính năng] - Mô tả lỗi ngắn gọn

Ví dụ: [Đăng nhập] Không khóa tài khoản sau 5 lần nhập sai mật khẩu

343171 Tiêu đề bug tốt giúp dev hiểu vấn đề chỉ sau 5 giây đọc

Description (Mô tả): Đây là phần cần viết kỹ nhất. Template chuẩn mình hay dùng:

**Môi trường:**
- OS: Windows 10
- Browser: Chrome 120
- URL: https://demo-shop.com/login

**Các bước tái hiện:**
1. Truy cập trang đăng nhập
2. Nhập email hợp lệ: [email protected]
3. Nhập mật khẩu sai: "wrongpass123"
4. Lặp lại bước 3 thêm 4 lần (tổng cộng 5 lần)

**Kết quả thực tế:**
Hệ thống vẫn cho phép đăng nhập tiếp, không hiện thông báo khóa tài khoản

**Kết quả mong đợi:**
Sau 5 lần nhập sai, hệ thống phải khóa tài khoản 15 phút và hiển thị thông báo: "Tài khoản bị khóa tạm thời. Thử lại sau 15 phút."

**Đặc tả liên quan:** REQ-AUTH-05

Priority: chọn High (tính năng bảo mật quan trọng)

Assignee: để trống hoặc giao cho dev phụ trách

Bước 3: Click "Create" - bug đã được log!

Sau khi tạo xong, Redmine tự động gán số ID cho bug (ví dụ: #42). Số này dùng để tham chiếu trong các cuộc họp hoặc chat với dev: "Em log bug #42, anh check giúp em nhé."

Những lỗi fresher thường mắc khi log bug

Mình đã review bug report của nhiều bạn học, và lỗi lặp đi lặp lại nhiều nhất không phải kỹ thuật - mà là cách viết.

Lỗi 1: Tiêu đề quá chung chung

❌ Bug trang đăng nhập
✅ [Đăng nhập] Không khóa tài khoản sau 5 lần nhập sai mật khẩu

Dev nhận hàng chục bug mỗi ngày. Tiêu đề mơ hồ = họ phải mở ra đọc chi tiết mới hiểu = mất thời gian = bạn mất điểm.

Lỗi 2: Không viết "Kết quả mong đợi"

Nhiều bạn chỉ viết "lỗi như này" mà không ghi kết quả đúng phải là gì. Dev sẽ hỏi lại: "Vậy đúng ra phải hiển thị gì?". Một câu hỏi thừa, một ngày trôi qua.

Lỗi 3: Không ghi môi trường test

Bug có thể chỉ xuất hiện trên Chrome, không xuất hiện trên Firefox. Nếu bạn không ghi trình duyệt đang dùng, dev test trên trình duyệt khác → không reproduce được → đánh dấu "Not a bug" → bạn phải mở lại → rất mất thời gian.

343172 3 lỗi phổ biến khi log bug - tránh được sẽ tiết kiệm rất nhiều thời gian cho cả team

Lỗi 4: Priority không đúng

Mình từng thấy bạn mark tất cả bug là Urgent vì nghĩ "cái gì cũng quan trọng". Kết quả? Dev không biết phải fix cái gì trước. Sau đó team lead phải ngồi re-prioritize lại hết - rất mất thời gian của cả team.

Lỗi 5: Attach screenshot thiếu hoặc không rõ

Nếu bug có giao diện bị lỗi, bắt buộc phải attach screenshot. Screenshot mờ, cắt sai chỗ, hoặc quên khoanh vùng lỗi thì gần như vô dụng. Dùng Snipping Tool (Windows) hoặc Lightshot để chụp và khoanh đỏ vùng lỗi trước khi đính kèm.

Thấy khó ở chỗ viết mô tả kỹ không? Bình thường. Mình cũng mất 2-3 tuần mới viết bug report "đạt" được. Cứ thực hành, càng viết càng quen.

Theo dõi và cập nhật bug sau khi log

Log bug xong không phải hết việc. Phần này nhiều fresher hay bỏ quên nhất.

Sau khi dev fix bug, họ sẽ chuyển status sang Resolved và note lại đã fix ở đâu. Lúc đó, việc của bạn là:

Deploy/cài bản mới lên môi trường test
Tái hiện lại đúng các bước đã ghi trong bug report
Kiểm tra xem bug đã thật sự được fix chưa
Kiểm tra thêm xem fix này có gây ra lỗi mới không (regression)

Nếu fix đúng → chuyển status sang Closed, ghi note ngắn: "Đã verify trên Chrome 120 / staging environment. Bug đã fix."

Nếu chưa fix hoặc fix sai → chuyển lại In Progress hoặc Reopened, ghi rõ lý do và bước tái hiện lại.

343173 Vòng đời của một bug từ lúc phát hiện đến khi đóng - tester tham gia ở đầu và cuối

Một mẹo nhỏ: dùng tính năng Watch (biểu tượng mắt) trên issue để nhận email thông báo mỗi khi bug được cập nhật. Bạn sẽ không bỏ lỡ khi dev mark Resolved.

Cuối sprint hoặc cuối tuần, vào tab Issues → filter theo Status = Resolved để xem danh sách bug cần verify. Thói quen này giúp bạn không để bug "đọng" lại không ai đóng - điều team lead không thích chút nào.

Muốn thực hành thêm với môi trường thật, bạn có thể tạo project cá nhân trên Redmine và tự log bug cho các app bạn đang dùng hàng ngày - Shopee, Grab, bất kỳ app nào. Đây là cách nhanh nhất để quen tay trước khi đi phỏng vấn.

Tải template bug report chuẩn để bắt đầu: Tải template bug report chuẩn

Thực hành ngay: checklist log bug đầu tiên

Bài này đã cover đủ để bạn bắt đầu. Giờ là lúc thực hành - không đọc thêm, không chờ "hiểu hết" mới làm.

Checklist để tự kiểm tra trước khi click Create:

[ ] Tracker đã chọn Bug chưa?
[ ] Tiêu đề có đúng format [Tính năng] - Mô tả lỗi chưa?
[ ] Đã ghi đủ môi trường (OS, browser, URL) chưa?
[ ] Các bước tái hiện có đánh số thứ tự và ai cũng làm theo được không?
[ ] Đã ghi kết quả thực tế (actual result) chưa?
[ ] Đã ghi kết quả mong đợi (expected result) chưa?
[ ] Priority có đúng mức độ ảnh hưởng thực tế không?
[ ] Screenshot được attach và khoanh vùng lỗi rõ chưa?

343174 Checklist 8 điểm này mình vẫn dùng mỗi ngày, dù đã làm 4 năm

Bước tiếp theo sau khi thực hành Redmine: học cách viết test case kỹ hơn - vì bug bạn tìm được phụ thuộc vào test case bạn viết có kỹ không. Hai kỹ năng này liên kết chặt với nhau.

Nếu bạn đang muốn chuyển ngành sang tester và chưa biết bắt đầu từ đâu, có thể tham khảo thêm phần kiến thức nền về quy trình phát triển phần mềm - hiểu được dev làm gì sẽ giúp bạn viết bug report sát thực tế hơn.

Comment bên dưới nếu bạn gặp khó ở bước nào - mình đọc và trả lời từng bạn. Chúc thực hành suôn sẻ!

Lửng Lọc Lõi