Ở bài viết trước, mình có giới thiệu về Triển khai và Thực hiện kiểm thử. Bài viết hôm nay, hãy cùng mình tìm hiểu về Đánh giá tiêu chí đầu ra và các công việc báo cáo trong Quy trình kiểm thử. Nào, hãy bắt đầu ngay bây giờ nhé!
Đánh Giá Tiêu Chí Đầu Ra Và Báo Cáo Cần Làm Gì?
Theo một nghĩa nào đó, việc đánh giá các tiêu chí đầu ra và báo cáo kết quả là một hoạt động quản lý kiểm thử. Chúng cần được phân tích, lập biểu đồ, trình bày và báo cáo kết quả kiểm tra như một phần của hoạt động kiểm soát và giám sát tiến độ kiểm thử. Tuy nhiên, bài viết này chúng ta chỉ xem xét đến đánh giá tiêu chí đầu và báo cáo kết quả là một hoạt động trong quản lý kiểm thử.
Với tư cách là nhà phân tích thử nghiệm, chúng ta cần quan tâm tới hai khía cạnh chính:
- Đầu tiên, thu thập thông tin cần thiết để hỗ trợ việc báo cáo kết quả quản lý kiểm thử.
- Thứ hai, đo lường tiến độ hoàn thành và phát hiện những sai lệch so với kế hoạch.
Để đo lường mức độ đầy đủ của quá trình kiểm thử liên quan tới tiêu chí đầu ra và tạo thông tin cần thiết cho việc báo cáo, chúng ta có thể đo lường các thuộc tính của quá trình thực hiện kiểm thử như sau:
- Số test condition, test case, hoặc test procedure được lên kế hoạch/ đã thực hiện/ đã pass, failed
- Tổng số lỗi được phân loại theo mức độ nghiêm trọng, mức độ ưu tiên, trạng thái và một số yếu tố khác.
- Yêu cầu thay đổi được đề xuất, chấp nhận, được kiểm thử
- Rủi ro về chất lượng, cả được giảm thiểu và còn tồn tại
- Thời gian mở rộng do các sự kiện blocking
- Kết quả xác nhận, hồi quy
Chúng ta có thể theo dõi đánh giá và báo cáo các mốc cũng như nhiệm vụ theo cấu trúc phân chia công việc. Điều này rất hữu ích trong việc xác định xem chúng có đang được tiến hành theo ước tính và tiến độ hay không.
Test Suite Summary
Hình minh họa dưới đây hiển thị bảng tính test suite summary. Một bảng tính như vậy tóm tắt thông tin ghi nhật ký từng thử nghiệm được mô tả trong phần trước. Với tư cách là nhà phân tích kiểm thử, bạn có thể sử dụng bảng tính này để theo dõi một số thuộc tính quan trọng của quá trình thực hiện kiểm thử cho đến hiện tại:
Bảng tổng kết kiểm thử
Trong bảng minh họa này:
Ở phía bên trái, bạn sẽ thấy hai cột, tên bộ kiểm thử – suite và tổng số lượng testcase mà nó chứa.
Ở phía giữa bên trái, bạn sẽ thấy bốn cột bên dưới tiêu đề chung là “Planned Tests Fulfilled – Đã hoàn thành các thử nghiệm theo kế hoạch”. Đây là những bài kiểm tra không còn công việc nào nữa, ít nhất là trong quá trình vượt qua bài kiểm tra này.
Các con số lỗi – Fail có trọng số cho mỗi bộ kiểm thử, được tìm thấy trong cột ở giữa bảng, đưa ra thước đo về hiệu quả tìm kiếm lỗi trong lịch sử.
Mỗi lỗi được tính trọng số – Weighted Failure theo mức độ ưu tiên và mức độ nghiêm trọng.
Ở phía giữa bên phải, bạn sẽ thấy bốn cột bên dưới tiêu đề chung là “Planned Tests Unfullfilled – Các thử nghiệm theo kế hoạch chưa được thực hiện”. Đây là những bài kiểm tra còn nhiều việc phải làm trong quá trình vượt qua bài kiểm tra này. IP là viết tắt của “in progress – đang tiến hành”.
Cuối cùng, ở phía bên phải, bạn sẽ thấy bốn cột dưới tiêu đề chung là “Earned Value – Giá trị thu được”. Giá trị thu được là một khái niệm quản lý dự án. Nó nói rằng, trong một dự án, chúng ta hoàn thành nhiệm vụ bằng cách sử dụng nhiều nguồn lực. Vì vậy, nếu phần trăm nhiệm vụ được hoàn thành gần bằng với phần trăm nguồn lực đã sử dụng thì chúng ta đang đi đúng hướng. Nếu phần trăm nhiệm vụ đã hoàn thành lớn hơn phần trăm nguồn lực đã sử dụng thì chúng ta đang tiến tới tình trạng thiếu ngân sách. Nếu phần trăm nhiệm vụ được hoàn thành nhỏ hơn phần trăm nguồn lực đã sử dụng thì chúng ta đang trên đà vượt quá ngân sách.
Defect Breakdown – Phân Tích Lỗi
Chúng ta có thể phân tích các báo cáo lỗi theo một số cách. Với tư cách là một chuyên gia kiểm thử, bạn nên nghĩ đến việc phân tích tốt và chính xác các báo cáo lỗi cũng giống như cách bác sĩ nghĩ về việc phân tích mẫu máu tốt và đúng cách.
Một trong những cách để kiểm tra báo cáo lỗi là xem xét việc phân tích các lỗi theo mức độ nghiêm trọng, mức độ ưu tiên hoặc sự kết hợp của cả hai. Nếu bạn sử dụng thang số cho mức độ nghiêm trọng và mức độ ưu tiên, bạn có thể dễ dàng nhân chúng lại với nhau để có được thước đo trọng số về tầm quan trọng tổng thể của lỗi, như bạn vừa thấy. Để tìm hiểu kỹ hơn với kỹ thuật phân tích này, bạn có thể tham khảo bài viết này của mình nhé.
Tuy nhiên, nếu chúng ta đang thực hiện thử nghiệm dựa trên rủi ro, thì hãy tìm những thứ rủi ro cao trước tiên. Nếu những phân loại mức độ nghiêm trọng này là đúng thì nhóm thử nghiệm đang làm điều đó.
Xác Nhận Tỷ Lệ Lỗi
Với tư cách là nhà phân tích kiểm thử, chúng ta có thể tin tưởng vào việc tìm ra một số lỗi. Hy vọng rằng nhiều lỗi trong số đó sẽ được phát hiện và được xử lý. Tại thời điểm đó, chúng ta xác nhận kiểm tra bản sửa lỗi.
Hình dưới đây minh họa cho một dự án thực tế.
Biểu đồ: Phân tích lỗi kiểm thử xác nhận bug
Trong dự án ngân hàng này, chúng ta có thể thấy rằng khá nhiều bản sửa lỗi đã không vượt qua được quá trình kiểm tra xác nhận. Chúng ta đã phải mở lại toàn bộ một trong sáu báo cáo lỗi ít nhất một lần. Đó là rất nhiều thời gian lãng phí. Nó cũng có rất nhiều khả năng bị trì hoãn lịch trình.
Mình xin dừng bài viết hôm nay tại đây. Hẹn gặp các bạn trong các bài viết tiếp theo.
Happy testing!