Bài 4: Quy trình kiểm thử phần mềm cơ bản

TỔNG QUAN VỀ QUY TRÌNH KIỂM THỬ PHẦN MỀM CƠ BẢN

Quy trình kiểm thử không phải là một bước đơn lẻ mà là một hệ thống gồm nhiều giai đoạn liên kết chặt chẽ.
Quy trình này đóng vai trò là khung xương cho toàn bộ hoạt động đảm bảo chất lượng phần mềm (QA/QC).
Nội dung chính bao gồm 07 giai đoạn cốt lõi: * Lập kế hoạch kiểm thử (Test Planning). * Giám sát và kiểm soát kiểm thử (Test Monitoring and Control). * Phân tích kiểm thử (Test Analysis). * Thiết kế kiểm thử (Test Design). * Triển khai kiểm thử (Test Implementation). * Thực hiện kiểm thử (Test Execution). * Hoàn thành kiểm thử (Test Completion).

GIAI ĐOẠN 1: LẬP KẾ HOẠCH KIỂM THỬ (TEST PLANNING)

Đây là bước đặt nền móng cho toàn bộ dự án kiểm thử. Ở giai đoạn này, đội ngũ quản lý như Test Manager hoặc Test Lead sẽ xác định bức tranh tổng thể.

Mục tiêu chính: * Xác định mục tiêu: Xác định những gì cần đạt được sau đợt kiểm thử (ví dụ: đảm bảo tính năng thanh toán hoạt động không lỗi). * Xác định phạm vi (Scope): Chỉ rõ tính năng nào cần test và tính năng nào không cần test. * Phân bổ nguồn lực: Quyết định nhân sự (ai làm gì), thiết bị, máy chủ, hoặc các công cụ phần mềm cần thiết. * Lên lịch trình: Xác định thời gian bắt đầu và kết thúc của từng giai đoạn cụ thể. * Đánh giá rủi ro: Dự đoán các rủi ro có thể xảy ra và xây dựng phương án dự phòng.
Dữ liệu đầu vào (Inputs): * Tài liệu Yêu cầu (Requirements Documents): Bao gồm Tài liệu yêu cầu nghiệp vụ (BRD), Tài liệu đặc tả hệ thống (SRS), Use Cases, hoặc User Stories (trong mô hình Agile). * Kế hoạch dự án (Project Plan): Nắm bắt các mốc thời gian (milestones) quan trọng và thời hạn (deadlines) tổng thể từ Project Manager (PM). * Chiến lược kiểm thử / Chính sách kiểm thử (Test Strategy / Test Policy): Các quy chuẩn, tiêu chuẩn chung của tổ chức. * Thông tin về Nguồn lực (Resource Information): Ngân sách, số lượng tester, các công cụ (tools) và thiết bị phần cứng sẵn có. * Đánh giá rủi ro ban đầu (Initial Risk Assessment): Những rủi ro đã được nhận diện sớm (ví dụ: công nghệ mới, thời gian gấp).
Dữ liệu đầu ra (Outputs): * Tài liệu Kế hoạch Kiểm thử (Test Plan): Một bản kế hoạch chuẩn chỉnh (thường viết bằng Word, Confluence hoặc Excel) chứa thông tin về: * Phạm vi kiểm thử (In-scope và Out-of-scope). * Phương pháp tiếp cận (Test Approach): Kỹ thuật test, có dùng Automation (tự động) hay Manual (thủ công), có test hiệu năng/bảo mật không. * Tiêu chí bắt đầu (Entry) và kết thúc (Exit Criteria): Điều kiện để bắt đầu nhận code từ Dev và điều kiện chất lượng để release sản phẩm (ví dụ: $100\%$ test case quan trọng được chạy, không còn lỗi nghiêm trọng). * Lịch trình và Ước lượng (Schedule & Estimation). * Phân bổ nguồn lực (Resource Allocation). * Quản lý rủi ro kiểm thử (Test Risk Management): Phương án dự phòng cho các trường hợp như tester nghỉ ốm, server sập, dev giao code trễ.

GIAI ĐOẠN 2: GIÁM SÁT VÀ KIỂM SOÁT KIỂM THỬ (TEST MONITORING AND CONTROL)

Hoạt động này không diễn ra độc lập mà song hành và liên tục xuyên suốt dự án để đảm bảo mọi thứ đi đúng hướng.

Khái niệm cơ bản: * Giám sát (Monitoring): Theo dõi tiến độ thực tế so với bản Test Plan (Ví dụ: So sánh mục tiêu test xong $100$ case trong tuần với thực tế chỉ mới xong $50$ case). * Kiểm soát (Control): Đưa ra các hành động khắc phục khi thực tế sai lệch so với kế hoạch.
Dữ liệu đầu vào (Inputs - Phục vụ Giám sát): * Tài liệu Kế hoạch kiểm thử (Test Plan): Thước đo chuẩn mực để đối chiếu. * Dữ liệu thực tế (Actual Metrics/Test Status): Các con số báo cáo như số lượng Test Case đã viết/chạy, tỷ lệ Pass/Fail, số lượng Bug tìm thấy và mức độ nghiêm trọng. * Các rủi ro mới phát sinh (Emerging Risks). * Thay đổi yêu cầu (Change Requests) từ khách hàng hoặc ban giám đốc.
Dữ liệu đầu ra (Outputs - Phục vụ Kiểm soát): * Báo cáo tiến độ kiểm thử (Test Progress Reports / Status Reports): Tổng hợp dưới dạng biểu đồ, bảng biểu cho các bên liên quan. * Hành động khắc phục / Chỉ thị kiểm soát (Control Directives): * Điều động thêm nhân sự hoặc yêu cầu tăng ca (Overtime) nếu thiếu người. * Đàm phán lùi ngày phát hành (Release date) hoặc thu hẹp phạm vi test (Test Scope) nếu thiếu thời gian. * Dừng test và trả code về cho đội Dev nếu chất lượng code quá kém. * Kế hoạch kiểm thử được cập nhật (Updated Test Plan).

GIAI ĐOẠN 3: PHÂN TÍCH KIỂM THỬ (TEST ANALYSIS)

Giai đoạn này tập trung trả lời cho câu hỏi: "Chúng ta sẽ test cái gì? (What to test)".

Các hoạt động chính: * Phân tích cơ sở kiểm thử (Test Basis): Đọc và nghiên cứu kỹ các tài liệu yêu cầu (SRS, BRD), bản vẽ thiết kế (UI Mockup, Wireframe), tài liệu API. * Đánh giá tìm lỗi tài liệu: Rà soát tài liệu bằng tư duy phản biện (Kiểm thử tĩnh - Static Testing) để phát hiện sớm các yêu cầu mơ hồ, mâu thuẫn. * Xác định tính năng cần test: Phân rã hệ thống thành các hạng mục chức năng và phi chức năng. * Xác định Điều kiện kiểm thử (Test Conditions): Liệt kê các tình huống bắt buộc phải kiểm tra (Ví dụ: Đối với ô nhập "Tuổi", điều kiện có thể là: tuổi hợp lệ $18-60$ , dưới $18$ , trên $60$ , nhập chữ cái, hoặc bỏ trống). * Thiết lập truy xuất nguồn gốc: Sử dụng Ma trận (RTM) để liên kết Điều kiện kiểm thử với tài liệu Yêu cầu gốc, đảm bảo bao phủ $100\%$ mong muốn của khách hàng.
Dữ liệu đầu ra (Outputs): * Danh sách Điều kiện kiểm thử (Test Conditions). * Báo cáo lỗi tài liệu (Defect Reports): Phát hiện lỗi khi Dev còn chưa bắt đầu code, giúp tiết kiệm chi phí.

GIAI ĐOẠN 4: THIẾT KẾ KIỂM THỬ (TEST DESIGN)

Giai đoạn này trả lời câu hỏi: "Chúng ta sẽ test như thế nào? (How to test)".

Các hoạt động chính: * Thiết kế Kịch bản (Test Cases): Viết chi tiết từng bước thao tác và kết quả mong đợi. Áp dụng các kỹ thuật như Phân vùng tương đương, Phân tích giá trị biên để tối ưu hóa số lượng case. * Sắp xếp ưu tiên: Gắn nhãn Cao, Trung bình, Thấp dựa trên mức độ rủi ro để biết kịch bản nào cần chạy trước. * Xác định Dữ liệu test (Test Data): Liệt kê các thông tin cần thiết (tài khoản, mật khẩu, file mẫu). * Thiết kế Môi trường: Lên danh sách yêu cầu về phần cứng, hệ điều hành, trình duyệt, cấu hình mạng. * Cập nhật Ma trận truy xuất (RTM): Liên kết Test Cases với Điều kiện kiểm thử.
Dữ liệu đầu ra (Outputs): * Kịch bản kiểm thử (Test Cases). * Dữ liệu kiểm thử (Test Data). * Yêu cầu Môi trường kiểm thử (Test Environment). * Ma trận truy xuất nguồn gốc (RTM) được cập nhật.

GIAI ĐOẠN 5: TRIỂN KHAI KIỂM THỬ (TEST IMPLEMENTATION)

Đây là bước chuẩn bị "đạn dược" trước khi ra chiến trường, trả lời lời câu hỏi: "Mọi thứ đã sẵn sàng để chạy test chưa?".

Các hoạt động chính: * Xây dựng và ưu tiên Quy trình test: Gom nhóm các Test Cases rời rạc thành Quy trình kiểm thử (Test Procedures) theo trình tự logic. * Tạo các Bộ kiểm thử (Test Suites): Nhóm các quy trình theo mục đích (ví dụ: bộ Smoke Test để chạy nhanh, bộ Regression Test để chạy toàn diện). * Thiết lập Môi trường kiểm thử: Cài đặt máy chủ, database, cấu hình mạng ổn định và sát với thực tế. * Chuẩn bị Dữ liệu kiểm thử: Khởi tạo, giả lập và nạp (import) trực tiếp dữ liệu ảo vào hệ thống. * Lên lịch trình thực thi (Execution Schedule): Phân công rõ Tester và thời gian chạy cụ thể.
Dữ liệu đầu ra (Outputs): * Quy trình & Bộ kiểm thử (Test Suites). * Kịch bản tự động (Test Scripts) (nếu có). * Môi trường sẵn sàng. * Dữ liệu thực tế được chuẩn bị (Prepared Test Data).

GIAI ĐOẠN 6: THỰC HIỆN KIỂM THỬ (TEST EXECUTION)

Đây là lúc Tester thao tác trực tiếp trên phần mềm thực tế.

Quy trình thực hiện: * Ghi nhận thông tin môi trường (Recording Context): Ghi chép ID, phiên bản phần mềm (version) đang test. * Thực thi các kịch bản test: Chạy bằng tay (Manual) hoặc chạy công cụ (Automation). * So sánh kết quả: Đối chiếu Kết quả thực tế (Actual Result) với Kết quả mong đợi (Expected Result). * Báo cáo lỗi (Reporting Defects): Nếu kết quả sai lệch (Fail), phân tích nguyên nhân và tạo phiếu báo cáo lỗi (Log Bug) trên các hệ thống như Jira, Trello. * Cập nhật trạng thái và Retest: Đánh dấu trạng thái Pass, Fail hoặc Blocked (Bị chặn). Thực hiện kiểm tra lại (Retest) sau khi Developer báo đã sửa xong lỗi.
Dữ liệu đầu ra (Outputs): * Kết quả kiểm thử (Test Results). * Báo cáo lỗi (Defect/Bug Reports). * Nhật ký kiểm thử (Test Logs): Hồ sơ ghi chép ai chạy, khi nào, bản phần mềm nào.

GIAI ĐOẠN 7: HOÀN THÀNH KIỂM THỬ (TEST COMPLETION)

Diễn ra khi dự án kết thúc, phần mềm được phát hành hoặc bị hủy bỏ.

Các hoạt động chính: * Kiểm tra trạng thái báo cáo lỗi: Đảm bảo mọi lỗi đã đóng hoặc ghi nhận các lỗi nhỏ vào danh sách "Lỗi tồn đọng" (Known bugs). * Tạo Báo cáo tổng kết kiểm thử (Test Summary Report): Đánh giá toàn diện chất lượng, rủi ro và khuyến nghị phát hành. * Đóng gói và lưu trữ tài sản kiểm thử (Testware): Lưu trữ kịch bản, mã nguồn tự động hóa để tái sử dụng. * Họp rút kinh nghiệm (Lessons Learned): Phân tích điểm tốt và vướng mắc để cải thiện quy trình tương lai. * Bàn giao tài sản: Chuyển giao kịch bản và môi trường cho đội ngũ Vận hành (Operations) hoặc Bảo trì (Maintenance). * Giải phóng môi trường: Trả lại thiết bị, dọn dẹp dữ liệu và đóng báo cáo lỗi.

CÂU HỎI TỔNG KẾT VÀ THẢO LUẬN

Mục đích chính của giai đoạn Lập kế hoạch kiểm thử là gì? (Đặt nền móng, xác định mục tiêu/phạm vi/nguồn lực/lịch trình/rủi ro).
Hoạt động "Giám sát và kiểm soát kiểm thử" diễn ra vào thời điểm nào? (Xuyên suốt toàn bộ dự án).
Sự khác biệt giữa "Giám sát" và "Kiểm soát" là gì? (Giám sát là theo dõi tiến độ, Kiểm soát là đưa ra hành động khắc phục).
Câu hỏi cốt lõi của Phân tích kiểm thử là gì? ("Test cái gì?").
"Cơ sở kiểm thử" (Test Basis) bao gồm những gì? (SRS, BRD, User Stories, UI Mockup, API docs…).
Tại sao báo cáo lỗi trong giai đoạn phân tích tài liệu lại quan trọng? (Giúp tiết kiệm chi phí do phát hiện lỗi sớm trước khi code).
Kỹ thuật nào dùng để tối ưu số lượng Test Case? (Phân vùng tương đương, Phân tích giá trị biên).
"Bộ kiểm thử" (Test Suites) là gì? (Nhóm các kịch bản có chung mục đích hoặc đặc điểm).
Tester cần làm gì khi "Kết quả thực tế" khác "Kết quả mong đợi"? (Phân tích nguyên nhân và Log Bug).
Vai trò của "Tiêu chí kết thúc" (Exit Criteria)? (Làm thước đo để quyết định dự án đã đủ điều kiện an toàn để đóng lại chưa).