Jira & Postman cho Tester Fresher: Hướng dẫn tạo bug, quản lý test case và test API cơ bản (2026)

3 tháng trước · 10 phút đọc

Tại sao Tester mới cần biết Jira và Postman?

Mình nhớ tuần đầu đi làm tester. Team dùng Jira để quản lý bug, dùng Postman để test API. Mình ngồi nhìn màn hình không biết bắt đầu từ đâu - không ai giải thích, mọi người cứ nghĩ "ai cũng biết rồi".

Thực tế? Jira và Postman là 2 công cụ bạn sẽ dùng gần như mỗi ngày khi làm tester. Jira để report bug, theo dõi trạng thái, quản lý test case. Postman để gọi API, kiểm tra response, debug khi tính năng bị lỗi mà không rõ lỗi ở đâu.

345587 Hai công cụ này xuất hiện trong hầu hết quy trình QA thực tế

Bài này mình hướng dẫn từng bước: cài đặt, tạo bug report đúng chuẩn trong Jira, quản lý test case, và test API cơ bản với Postman. Không cần biết code, không cần kinh nghiệm trước - chỉ cần làm theo từng bước.

Nếu bạn đang tìm hiểu ngành IT để định hướng trước khi học testing, khóa Kiến Thức Nhập Môn IT của F8 miễn phí - xem qua để có cái nhìn tổng quan trước nhé.

Cài đặt Jira và Postman - Bắt đầu từ đâu?

Trước khi làm gì cũng cần có công cụ. Tin tốt: cả hai đều có bản miễn phí, không cần xin phép team IT hay trả tiền.

Jira: Atlassian cung cấp bản Jira Free cho team tối đa 10 người. Bạn đăng ký tại Đăng ký Jira Free, tạo project mới, xong. Nếu công ty đã có Jira, xin IT cấp tài khoản và hỏi tên project bạn sẽ làm việc.

Postman: Tải bản desktop tại Tải Postman Desktop. Dùng bản desktop ổn định hơn bản web, đặc biệt khi test API nội bộ (localhost hoặc server công ty).

345588 Đăng ký tài khoản Postman - nhớ dùng email công ty nếu đang làm việc thực tế

Sau khi cài xong, tạo tài khoản Postman (miễn phí), tạo workspace mới tên "Testing Practice" để lưu các collection thực hành. Jira thì tạo project kiểu Scrum hoặc Kanban - mình hay dùng Scrum vì quen với cách team dev làm việc.

Một điều nhiều bạn mới hay bỏ qua: làm quen giao diện trước khi dùng thật. Dành 30 phút click khắp Jira xem các menu có gì. Postman cũng vậy - mở thử vài request GET đơn giản để hiểu layout. Không làm bước này, sau hay bị lạc.

Tạo bug report chuẩn trong Jira

Bug report tệ là một trong những lý do dev ghét tester. Không phải vì dev khó tính - mà vì bug report thiếu thông tin thì họ không reproduce được, tức là không fix được.

Mình từng viết bug kiểu: "Trang đăng nhập bị lỗi". Dev hỏi lại: lỗi gì, ở đâu, làm thế nào để thấy lỗi? Mất thêm 1 ngày qua lại. Từ đó mình học: bug report phải đủ để người khác tự reproduce mà không cần hỏi thêm.

345589 Một bug report đủ thông tin giúp dev fix nhanh hơn 2-3 lần

Cấu trúc bug report chuẩn trong Jira:

Summary (Tiêu đề): Ngắn gọn, đủ ý. Không viết "Lỗi đăng nhập" mà viết "Đăng nhập thất bại khi password chứa ký tự đặc biệt (@, #, $)".

Steps to Reproduce (Các bước tái hiện):

1. Truy cập trang đăng nhập: https://demo.example.com/login
2. Nhập username: [email protected]
3. Nhập password: Test@123#
4. Click nút "Đăng nhập"

Expected Result (Kết quả mong đợi): Hệ thống đăng nhập thành công, chuyển sang trang dashboard.

Actual Result (Kết quả thực tế): Hiển thị thông báo lỗi "Invalid password" dù password đúng.

Severity & Priority: Severity là mức độ nghiêm trọng về kỹ thuật (Critical/Major/Minor/Trivial). Priority là mức ưu tiên xử lý do team quyết định. Nhiều fresher nhầm hai cái này.

Attachment: Screenshot hoặc video quay màn hình. Bắt buộc. Không có ảnh, bug report yếu hẳn.

Trong Jira, tạo bug bằng cách vào project → click Create → chọn Issue Type là Bug → điền đầy đủ các trường trên.

Một lưu ý mình hay nhắc: kiểm tra xem bug đã được report chưa trước khi tạo mới. Dùng ô search trong Jira, tìm từ khóa liên quan. Duplicate bug report làm mất thời gian của cả team.

Bạn có thể tải template bug report này về dùng luôn: Tải template bug report chuẩn

Quản lý test case trong Jira

Jira không chỉ dùng để track bug. Nhiều team dùng Jira kết hợp với plugin (như Zephyr Scale hoặc Xray) để quản lý test case. Nhưng nếu team chưa có plugin, bạn vẫn quản lý được test case bằng Story và Task trong Jira bình thường.

Mô hình phổ biến nhất mình thấy ở công ty vừa và nhỏ:

Story = tính năng cần test (ví dụ: "Tính năng đăng nhập")
Task = nhóm test case theo luồng (ví dụ: "Test đăng nhập thành công", "Test đăng nhập thất bại")
Sub-task = từng test case cụ thể

345590 Cấu trúc phân cấp Story → Task → Sub-task giúp theo dõi tiến độ test rõ ràng hơn

Với mỗi test case (Sub-task), mình điền vào Description theo format:

Precondition (Điều kiện tiên quyết): User đã có tài khoản hợp lệ, hệ thống đang chạy bình thường.

Test Steps:

Mở trình duyệt, truy cập link đăng nhập
Nhập đúng email và password
Click "Đăng nhập"

Expected Result: Hệ thống chuyển sang dashboard, hiển thị tên user ở góc phải.

Test Data: email: [email protected] / password: Demo1234

Trạng thái test case mình track bằng Label trong Jira: PASS, FAIL, BLOCKED, NOT_TESTED. Đơn giản nhưng đủ dùng khi team chưa có tool riêng.

Một điều quan trọng: viết test case đủ chi tiết để người khác chạy được, không chỉ để bạn tự chạy. Mình từng viết test case kiểu "test tính năng thanh toán" - không step, không data - sau đó bạn cùng team không biết test gì. Phải viết lại hết.

Nếu team bạn dùng Zephyr Scale hoặc Xray, cách dùng khác một chút nhưng cấu trúc tư duy vẫn vậy: test case phải rõ steps, rõ expected result, rõ test data.

Postman là gì và tại sao Tester cần biết?

Postman là công cụ để gọi API và kiểm tra kết quả trả về. Nghe kỹ thuật nhưng thực ra không phức tạp.

Hãy nghĩ thế này: khi bạn đăng nhập vào app, phần giao diện (frontend) gửi thông tin username/password lên server, server xử lý và trả về kết quả (đăng nhập thành công hoặc thất bại). Luồng giao tiếp đó gọi là API. Postman cho phép bạn mô phỏng luồng đó mà không cần mở app - gửi request trực tiếp lên server, xem server trả về gì.

Tại sao tester cần?

Khi UI bị lỗi, không rõ lỗi ở frontend hay backend: dùng Postman test thẳng API xem server trả đúng không
Kiểm tra API trước khi dev làm xong giao diện
Tìm bug mà test bằng tay trên UI rất khó reproduce

345591 API hoạt động như cầu nối giữa frontend và backend - Postman giúp bạn test trực tiếp cái cầu đó

Postman không yêu cầu bạn biết code. Bạn chỉ cần hiểu:

URL (endpoint): Địa chỉ API, ví dụ https://api.example.com/login
Method: GET (lấy dữ liệu), POST (gửi dữ liệu), PUT (cập nhật), DELETE (xóa)
Request body: Dữ liệu gửi lên (ví dụ: username, password dạng JSON)
Response: Kết quả server trả về, thường là JSON
Status code: 200 OK (thành công), 400 Bad Request (sai dữ liệu), 401 Unauthorized (chưa xác thực), 500 Server Error (lỗi server)

Nắm 5 khái niệm trên là bạn đã test được phần lớn API thực tế rồi. Phần còn lại học sau.

Hướng dẫn test API cơ bản với Postman

Mở Postman lên. Mình sẽ dùng API public miễn phí để thực hành - không cần xin server công ty, không cần tài khoản đặc biệt.

API thực hành: https://jsonplaceholder.typicode.com - đây là API test miễn phí, dữ liệu giả, an toàn để thực hành.

Bước 1: Tạo Collection mới

Trong Postman, click New → Collection, đặt tên "Thực hành API cơ bản". Collection là thư mục lưu các request - giữ mọi thứ gọn gàng.

Bước 2: Test request GET đầu tiên

Click New Request trong collection
Method: chọn GET
URL: https://jsonplaceholder.typicode.com/posts/1
Click Send

Kết quả: server trả về JSON chứa thông tin 1 bài post. Status code 200 OK = thành công.

345592 Giao diện Postman sau khi gửi request GET thành công - status 200 và response JSON bên dưới

Bước 3: Test request POST (gửi dữ liệu lên)

Method: POST
URL: https://jsonplaceholder.typicode.com/posts
Vào tab Body → raw → JSON, nhập:

{
  "title": "Bài viết test",
  "body": "Nội dung thử nghiệm",
  "userId": 1
}

Click Send
Status code 201 Created = tạo thành công

Bước 4: Thêm test đơn giản (assertions)

Postman có tab Tests để viết assertion tự động. Vào tab Tests, thêm:

// Kiểm tra status code = 200
pm.test("Status code là 200", function () {
    pm.response.to.have.status(200);
});

// Kiểm tra response có trường 'id'
pm.test("Response có trường id", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property('id');
});

Có vẻ như code, nhưng thực ra chỉ là copy-paste và sửa tên trường. Không cần hiểu sâu JavaScript ở bước này.

Bạn làm được 4 bước trên là đã test được API cơ bản. Lưu collection lại, sau này thực hành với API thật của dự án thì quen ngay.

Muốn tìm hiểu sâu hơn về backend và API hoạt động như thế nào, khóa Node & ExpressJS của F8 giải thích rất rõ từ góc nhìn dev - hiểu dev build API thế nào giúp bạn test tốt hơn nhiều.