Đây là bài cuối của Manual Testing Foundation. Sau một vòng requirement, test process, test case, bug và report, giờ mới nói tới tool.
Mình cố tình để tool cuối vì người mới rất dễ học ngược: thuộc Jira nằm ở đâu, Postman bấm nút nào, nhưng hỏi tại sao cần trường Expected Result hoặc request này đang kiểm tra business rule gì thì đứng hình.
Tool giúp làm việc nhanh và có dấu vết hơn. Nó không thay phần tư duy phía trước.
Project và work tracking
Jira, Azure DevOps, GitHub Projects hoặc Linear đều có thể theo dõi backlog, task, bug và tiến độ. Tester thường dùng chúng để:
- Đọc story và acceptance criteria.
- Theo dõi build hoặc release liên quan.
- Log và triage defect.
- Link bug với requirement, test hoặc pull request.
- Quan sát thay đổi scope và dependency.
Tên tool không quan trọng bằng workflow. Một Jira có 27 status vẫn không cứu được team nếu bug Fixed chẳng ai biết đang nằm ở build nào.
Test management
TestRail, Zephyr, Xray, Qase hoặc Azure Test Plans giúp quản lý test case, test run, result và traceability.
Chúng bắt đầu có ích khi:
- Nhiều người cùng sửa và chạy test.
- Một case được chạy trên nhiều build hoặc configuration.
- Cần lịch sử execution và report theo release.
- Spreadsheet bắt đầu có những cột tên
final_v2_really_final.
Bộ test nhỏ vẫn có thể dùng Markdown hoặc spreadsheet. Đừng mua tool chỉ vì nhìn dashboard đẹp; hãy xem team đang đau ở versioning, execution, permission, traceability hay reporting.
API và network
Postman, Bruno, Insomnia hoặc command line như curl giúp gọi API. Browser DevTools cho xem request, response, cookie, storage, timing và console.
Manual tester không cần biến thành backend developer mới được mở tab Network. Chỉ cần đọc được method, URL, status, header và body đã giúp bug report khác hẳn câu “bấm không được”.
Lưu ý đừng đưa production token, cookie hay dữ liệu khách hàng vào public workspace, screenshot hoặc collection commit lên Git.
Database và dữ liệu
DBeaver, DataGrip, pgAdmin hoặc client đi kèm database giúp truy vấn và chuẩn bị data. Với tester, SQL thường dùng để:
- Xác nhận state phía sau UI/API.
- Tạo hoặc tìm data cho scenario.
- Điều tra failure.
- Kiểm tra migration và data integrity.
Quyền đọc và quyền ghi phải tách rõ. Chạy một câu UPDATE không có WHERE trên môi trường chung là cách học SQL rất nhanh nhưng hơi tốn đồng nghiệp.
Evidence và quan sát hệ thống
Screenshot, screen recorder, browser HAR, application log, Sentry, Grafana hoặc Kibana giúp lưu bằng chứng và điều tra.
Chọn thứ phù hợp với failure:
- UI tĩnh: ảnh.
- Timing hoặc animation: video.
- API: request/response và correlation ID.
- Backend: log có timestamp.
- Performance: metric và trace, không phải cảm giác “hôm nay hơi chậm”.
Luôn che secret và dữ liệu cá nhân trước khi chia sẻ.
Accessibility và compatibility
Browser DevTools, axe, Lighthouse, screen reader và dịch vụ device/browser cloud có thể hỗ trợ. Automated accessibility scan bắt được một phần lỗi, không thay keyboard test hay screen reader test thủ công.
Compatibility cũng cần bám support matrix. Test mười browser ngẫu nhiên không có giá trị bằng test đúng browser, OS và viewport mà sản phẩm cam kết hỗ trợ.
Giao tiếp và tài liệu
Slack, Teams, Confluence, Notion hay repository Markdown đều chỉ là nơi giữ thông tin. Quyết định quan trọng phải đi vào chỗ team có thể tìm lại, không nằm vĩnh viễn trong một đoạn chat riêng.
Nếu requirement được chốt trong call, ghi lại acceptance criteria. Nếu workaround được chấp nhận, cập nhật ticket. Trí nhớ tập thể của dự án không nên phụ thuộc vào việc một người còn làm ở công ty hay không.
Chọn tool thế nào?
Trước khi thêm tool, hỏi:
- Vấn đề cụ thể đang là gì?
- Tool có tích hợp với workflow hiện tại không?
- Data nằm ở đâu, ai có quyền truy cập và có secret nào không?
- Export được không nếu sau này đổi tool?
- Chi phí license, vận hành và học cách dùng có đáng không?
Tool miễn phí nhưng tốn ba ngày mỗi tháng để sửa dữ liệu cũng không thật sự miễn phí. Tool trả tiền mà team chỉ dùng như spreadsheet online cũng không tự nhiên thành đầu tư tốt.
Hết phần Foundation
Tới đây chúng ta đã đi từ Software Testing là gì tới cách đọc requirement, thiết kế test, chạy test, log bug và báo cáo. Đống kiến thức này chưa biến ai thành tester cứng ngay, nhưng ít nhất khi mở một project thật, bạn biết mình đang nhìn cái gì và cần hỏi câu nào.
Phần tiếp theo chuyển sang Robot Framework. Từ đây bắt đầu có code, command line, library và những con bug do chính automation script tạo ra — tức là hàng rào kiểm thử cũng cần được kiểm thử tử tế.
