Nội dung
- Kiến thức nền tảng
- Quy trình kiểm thử
- Kỹ năng phân tích lỗi
- Công cụ hỗ trợ tester
- Kỹ thuật kiểm thử
- Kỹ năng mềm
- Kỹ năng bổ sung
Kiến thức nền tảng cho tester
1. Định nghĩa kiểm thử phần mềm
Kiểm thử phần mềm là quá trình xác minh (verification) và xác nhận (validation) rằng phần mềm được phát triển phù hợp với yêu cầu đã đề ra, hoạt động đúng như mong đợi và không có lỗi ảnh hưởng nghiêm trọng đến người dùng.
- Xác minh (Verification): Kiểm tra xem sản phẩm có được xây dựng đúng cách hay không, tập trung vào giai đoạn phát triển.
Ví dụ: Đọc tài liệu yêu cầu (SRS) để đảm bảo rằng các chức năng được mô tả rõ ràng và đúng với mục tiêu ban đầu. - Xác nhận (Validation): Đảm bảo rằng sản phẩm được xây dựng đúng nhu cầu của khách hàng và hoạt động như mong đợi.
Ví dụ: Thử nghiệm giao diện người dùng để đảm bảo sản phẩm dễ sử dụng và phù hợp với kỳ vọng của khách hàng.
2. Mục tiêu kiểm thử
- Phát hiện lỗi (bugs):
- Kiểm tra để tìm ra các lỗi chức năng hoặc logic trong phần mềm.
- Ví dụ: Một ứng dụng đặt hàng trực tuyến cho phép người dùng nhập số lượng âm. Đây là lỗi cần phát hiện trong giai đoạn kiểm thử.
- Đảm bảo chất lượng sản phẩm:
- Đảm bảo rằng sản phẩm hoạt động mượt mà, không gặp lỗi lớn khi triển khai cho khách hàng.
- Ví dụ: Một trang web thương mại điện tử phải hoạt động tốt trên các trình duyệt khác nhau như Chrome, Safari, Firefox.
- Cải thiện trải nghiệm người dùng:
- Đảm bảo sản phẩm dễ sử dụng, giao diện thân thiện và cung cấp giá trị cho người dùng.
- Ví dụ: Kiểm tra ứng dụng ngân hàng có giao diện dễ sử dụng, rõ ràng, và không gây nhầm lẫn khi thực hiện giao dịch.
3. Các mức độ kiểm thử (Testing Levels)
- Unit Testing (Kiểm thử đơn vị):
- Kiểm tra từng module hoặc đoạn mã riêng lẻ.
- Ví dụ: Kiểm tra một hàm trong mã nguồn tính toán tổng hai số. Đầu vào là
3
và5
, đầu ra kỳ vọng là8
.
- Integration Testing (Kiểm thử tích hợp):
- Kiểm tra sự giao tiếp giữa các module hoặc thành phần.
- Ví dụ: Một ứng dụng có hai module: Đăng ký tài khoản và Gửi email xác nhận. Kiểm tra xem sau khi người dùng đăng ký, email xác nhận có được gửi thành công không.
- System Testing (Kiểm thử hệ thống):
- Kiểm tra toàn bộ hệ thống như một đơn vị hoàn chỉnh.
- Ví dụ: Kiểm tra toàn bộ hệ thống đặt vé máy bay: chọn vé, điền thông tin hành khách, thanh toán, và nhận email xác nhận.
- Acceptance Testing (Kiểm thử chấp nhận):
- Kiểm tra xem phần mềm có đáp ứng các yêu cầu nghiệp vụ của khách hàng hay không.
- Ví dụ: Một khách hàng yêu cầu ứng dụng quản lý nhân sự có thể xuất báo cáo lương. Tester kiểm tra xem tính năng xuất báo cáo có hoạt động chính xác không trước khi bàn giao sản phẩm.
4. Các loại kiểm thử chính (Testing Types)
- Functional Testing (Kiểm thử chức năng):
- Đảm bảo phần mềm hoạt động đúng với các yêu cầu đã đề ra.
- Ví dụ: Trong một ứng dụng ngân hàng, kiểm tra chức năng “Chuyển tiền” với các điều kiện:
- Tài khoản nguồn còn đủ tiền.
- Tài khoản đích hợp lệ.
- Non-Functional Testing (Kiểm thử phi chức năng):
- Kiểm tra các yếu tố như hiệu suất, bảo mật, khả năng tương thích.
- Ví dụ:
- Hiệu suất: Đo tốc độ xử lý khi 1000 người dùng truy cập đồng thời.
- Bảo mật: Kiểm tra ứng dụng không bị xâm nhập khi thử nhập mã độc vào form đăng nhập.
- Regression Testing (Kiểm thử hồi quy):
- Kiểm tra lại các phần đã hoạt động sau khi thay đổi mã nguồn hoặc sửa lỗi.
- Ví dụ: Sau khi sửa lỗi tính sai số tiền trong giỏ hàng, kiểm tra toàn bộ tính năng thanh toán để đảm bảo không ảnh hưởng đến các phần khác.
- Smoke Testing (Kiểm thử khói):
- Kiểm tra nhanh các chức năng chính của phần mềm để đảm bảo hệ thống hoạt động cơ bản.
- Ví dụ: Sau khi triển khai bản build mới, kiểm tra xem ứng dụng có thể mở, đăng nhập, và thực hiện thao tác cơ bản mà không bị lỗi.
- Sanity Testing (Kiểm thử hợp lệ):
- Kiểm tra tập trung vào một tính năng cụ thể sau khi thay đổi hoặc sửa lỗi.
- Ví dụ: Sau khi cải thiện tính năng tìm kiếm trên trang web, chỉ kiểm tra tính năng này để xác nhận hoạt động tốt.
Quy trình kiểm thử (Testing Process)
Quy trình kiểm thử phần mềm bao gồm nhiều bước nhằm đảm bảo sản phẩm hoạt động đúng như mong đợi. Tester cần nắm chắc các bước trong quy trình để xử lý công việc kiểm thử hiệu quả hơn. Dưới đây là chi tiết từng bước, kèm theo ví dụ cụ thể:
1. Phân tích yêu cầu (Requirement Analysis)
Hiểu rõ yêu cầu sản phẩm từ tài liệu SRS (Software Requirement Specification) hoặc trực tiếp từ khách hàng. Đây là bước đầu tiên để xác định rõ những gì cần kiểm thử.
- Hoạt động:
- Đọc và hiểu tài liệu SRS hoặc tài liệu yêu cầu.
- Xác định các chức năng chính, chức năng phụ, và các ràng buộc.
- Phát hiện các yêu cầu không rõ ràng hoặc thiếu sót.
- Trao đổi với khách hàng hoặc team phát triển nếu cần làm rõ yêu cầu.
- Ví dụ:
Một ứng dụng đặt vé máy bay yêu cầu:- Người dùng có thể tìm kiếm chuyến bay theo ngày, địa điểm đi và địa điểm đến.
- Phải hiển thị giá vé, thời gian bay, và tên hãng hàng không.
Khi phân tích yêu cầu, tester cần đảm bảo hiểu rõ cách hoạt động của chức năng “Tìm kiếm chuyến bay” và các trường hợp cần kiểm thử như:
- Người dùng nhập sai ngày.
- Không có chuyến bay nào khả dụng.
2. Lập kế hoạch kiểm thử (Test Planning)
- Hoạt động:
- Xác định phạm vi kiểm thử (những gì sẽ và không được kiểm thử).
- Xác định mục tiêu: Ví dụ, đảm bảo các chức năng chính hoạt động đúng.
- Lựa chọn chiến lược kiểm thử: Thủ công, tự động, hoặc kết hợp cả hai.
- Chuẩn bị tài nguyên: nhân sự, công cụ (Jira, Selenium…), và môi trường kiểm thử (server, database).
- Lên kế hoạch lịch trình kiểm thử (timeline).
- Ví dụ:
- Phạm vi: Chỉ kiểm thử giao diện web, không kiểm thử phiên bản di động.
- Công cụ: Sử dụng Selenium để kiểm thử tự động.
- Môi trường: Dùng trình duyệt Chrome và Firefox trên hệ điều hành Windows 10.
3/4. Thiết kế kịch bản kiểm thử (Test Case Development & Enviroment)
- Hoạt động:
- Tạo các Test Case cụ thể, rõ ràng, dễ hiểu và có thể tái sử dụng.
- Xác định Test Data: Dữ liệu đầu vào cần thiết để thực hiện kiểm thử.
- Đảm bảo mỗi Test Case có mô tả chi tiết, bao gồm:
- ID của Test Case.
- Mục tiêu kiểm thử.
- Các bước thực hiện.
- Kết quả mong đợi.
- Ví dụ:
Test Case: Tìm kiếm chuyến bay khả dụng- ID: TC001.
- Mục tiêu: Xác minh rằng chức năng tìm kiếm chuyến bay hoạt động đúng.
- Bước thực hiện:
- Truy cập trang web đặt vé.
- Nhập thông tin:
- Địa điểm đi: Hà Nội.
- Địa điểm đến: TP. HCM.
- Ngày: 25/12/2024.
- Nhấn nút “Tìm kiếm”.
- Kết quả mong đợi: Hiển thị danh sách chuyến bay phù hợp với thông tin nhập vào.
5. Thực hiện kiểm thử (Test Execution)
- Hoạt động:
- Chạy các Test Case đã thiết kế.
- Ghi nhận kết quả thực tế (Actual Result) và so sánh với kết quả mong đợi (Expected Result).
- Gửi báo cáo lỗi (Bug Report) nếu phát hiện vấn đề.
- Ví dụ:
- Test Case: TC001 (Tìm kiếm chuyến bay).
- Kết quả thực tế: Trang web hiển thị lỗi “Không tìm thấy chuyến bay” dù thông tin nhập hợp lệ.
- Báo cáo lỗi (Bug Report):
- ID: BUG001.
- Mô tả: Chức năng tìm kiếm không hiển thị kết quả chính xác khi nhập thông tin hợp lệ.
- Môi trường: Chrome, Windows 10.
- Độ ưu tiên: Cao.
6. Theo dõi và báo cáo (Tracking & Reporting/ Test closure)
- Hoạt động:
- Theo dõi trạng thái lỗi: Mới (New), Đã sửa (Fixed), hoặc Đã đóng (Closed).
- Kiểm tra lại lỗi (Retest) để xác minh lỗi đã được sửa.
- Tổng hợp kết quả kiểm thử và gửi báo cáo kiểm thử (Test Report) cho team liên quan.
- Ví dụ:
- Trạng thái lỗi:
- BUG001: Đã sửa.
- BUG002: Chưa sửa.
- Báo cáo kiểm thử:
- Tổng số Test Case: 50.
- Số Test Case thành công: 45.
- Số Test Case thất bại: 5.
- Tỷ lệ thành công: 90%.
- Trạng thái lỗi:
Kỹ năng phân tích lỗi (Bug Analysis)
Phân tích lỗi là một trong những kỹ năng cốt lõi của tester, giúp phát hiện, ghi nhận, và truyền đạt thông tin về lỗi (bug) một cách rõ ràng, chi tiết để đảm bảo developer có đủ thông tin để khắc phục. Việc này bao gồm hiểu vòng đời lỗi, chuẩn bị báo cáo lỗi hiệu quả và sử dụng các công cụ hỗ trợ.
1. Hiểu rõ Defect Lifecycle (Vòng đời lỗi)
Vòng đời lỗi mô tả các trạng thái mà một lỗi trải qua từ khi được phát hiện đến khi được khắc phục hoàn toàn.
Các trạng thái chính trong vòng đời lỗi:
- New (Mới): Lỗi vừa được phát hiện và ghi nhận bởi tester.
- Ví dụ: Tester phát hiện khi nhập số âm vào ô “Số lượng sản phẩm”, hệ thống không hiển thị thông báo lỗi.
- Assigned (Gán): Lỗi được gán cho một developer cụ thể để xử lý.
- Ví dụ: Lỗi trên được gán cho Developer A, người chịu trách nhiệm xử lý module nhập liệu.
- Fixed (Đã sửa): Developer sửa lỗi và đánh dấu trạng thái là “Fixed”.
- Ví dụ: Developer A sửa lỗi và gửi lại cho tester để kiểm tra.
- Retested (Kiểm tra lại): Tester kiểm tra lại lỗi đã được sửa để xác nhận lỗi không còn xảy ra.
- Ví dụ: Tester thử nhập số âm vào ô “Số lượng sản phẩm” và thấy thông báo lỗi hiển thị đúng như mong đợi.
- Closed (Đóng): Lỗi được xác nhận là đã sửa xong và không còn tồn tại.
- Ví dụ: Tester đánh dấu lỗi “Closed” trong hệ thống quản lý lỗi (như Jira).
- Reopened (Mở lại): Nếu tester phát hiện lỗi vẫn còn xảy ra hoặc tái phát sau khi sửa, trạng thái sẽ chuyển thành “Reopened”.
- Ví dụ: Tester phát hiện thông báo lỗi hiển thị không đúng trên trình duyệt Safari, và lỗi được mở lại.
2. Các yếu tố cần có trong Bug Report
Bug Report là tài liệu quan trọng để mô tả chi tiết về lỗi, giúp developer hiểu và sửa lỗi nhanh chóng. Một Bug Report tốt cần các yếu tố sau:
- Mô tả chi tiết lỗi (Bug Description):
- Mô tả ngắn gọn nhưng đầy đủ về lỗi, bao gồm:
- Lỗi là gì?
- Xảy ra khi nào?
- Ở đâu trong phần mềm?
- Ví dụ: “Hệ thống không hiển thị thông báo lỗi khi nhập số âm vào ô ‘Số lượng sản phẩm’ trên trang Giỏ hàng.”
- Mô tả ngắn gọn nhưng đầy đủ về lỗi, bao gồm:
- Các bước thực hiện để tái tạo lỗi (Steps to Reproduce):
- Cung cấp từng bước cụ thể để developer có thể tái tạo lỗi.
- Ví dụ:
- Truy cập trang web [example.com/cart].
- Thêm một sản phẩm vào giỏ hàng.
- Nhập giá trị “-1” vào ô “Số lượng sản phẩm”.
- Nhấn “Cập nhật giỏ hàng”.
- Kết quả mong đợi và kết quả thực tế (Expected vs. Actual Result):
- Kết quả mong đợi: Hệ thống hiển thị thông báo lỗi: “Số lượng sản phẩm không thể là số âm.”
- Kết quả thực tế: Không có thông báo lỗi, và giỏ hàng vẫn được cập nhật với số lượng âm.
- Môi trường kiểm thử (Environment):
- Thông tin về môi trường nơi lỗi xảy ra: hệ điều hành, trình duyệt, thiết bị, phiên bản ứng dụng…
- Ví dụ:
- OS: Windows 11.
- Trình duyệt: Google Chrome, Version 118.0.
- Môi trường: Staging Server.
- Tài liệu bổ sung (Attachments):
- Đính kèm ảnh chụp màn hình hoặc video để minh họa lỗi.
- Ví dụ: Ảnh chụp màn hình giỏ hàng hiển thị số lượng “-1”.
3. Ví dụ chi tiết về Bug Report4. Lưu ý khi phân tích lỗi
- Tính rõ ràng: Viết Bug Report với ngôn ngữ dễ hiểu, tránh từ ngữ chuyên môn khó hiểu.
- Tính đầy đủ: Cung cấp đầy đủ thông tin cần thiết để developer tái tạo lỗi.
- Tính khách quan: Tập trung vào mô tả vấn đề, không phán xét cách làm việc của nhóm phát triển.
Phân tích lỗi chính xác và viết Bug Report chi tiết không chỉ giúp tăng hiệu quả sửa lỗi mà còn cải thiện sự phối hợp giữa các nhóm trong dự án.