Công việc cuối cùng trong một Quy trình kiểm thử thông thường sẽ là Các hoạt động kết thúc kiểm thử. Hãy cùng mình tìm hiểu chi tiết hơn trong bài viết ngày hôm nay nhé!
Các Hoạt Động Kết Thúc Kiểm Thử
Công việc kết thúc kiểm thử là công việc thường bị lãng quên nhưng quan trọng ở cuối quá trình kiểm thử để đảm bảo và nắm bắt giá trị còn lại có sẵn cho nhóm kiểm thử, nhóm dự án lớn hơn và toàn bộ tổ chức. Hoạt động kết thúc kiểm thử bao gồm bốn công việc chính:
- Đảm bảo rằng công việc kiểm tra đã được kết thúc
- Cung cấp sản phẩm kiểm thử
- Tham gia hồi tưởng dự án
- Lưu trữ sản phẩm công việc kiểm thử
Chúng ta hãy cùng nhìn vào từng điều này
Đảm Bảo Rằng Công Việc Kiểm Tra Đã Được Kết Thúc
Hoạt động kiểm tra đơn giản để đảm bảo rằng công việc của chúng ta đã thực sự hoàn thành. Ở những dự án lớn hoặc phân tán, bạn rất dễ quên điều đó. Người quản lý kiểm tra thông tin, khi quy trình kiểm thử chặt chẽ, hãy kiểm tra kỹ để đảm bảo rằng:
- Mọi thứ đã được lên kế hoạch đều được thực hiện
- Tất cả các kế hoạch kiểm tra đã được thực hiện khi kết thúc hoặc bị bỏ qua (và được chấp nhận bỏ qua)
- Tất cả các lỗi đã biết chưa được giải quyết (bao gồm cả việc kiểm tra xác thực lỗi đã được sửa), được trì hoãn (với sự hỗ trợ phù hợp từ nhóm dự án) hoặc được chấp nhận như những lỗi đó hạn chế vĩnh viễn.
Cung Cấp Sản Phẩm Kiểm Thử
Tiếp theo là tìm kiếm cơ hội sử dụng lại các sản phẩm kiểm thử. Sau khi phát hành, nhiều sản phẩm công việc này có thể hữu ích cho những người khác trong nhóm dự án, nhóm hỗ trợ hoặc thậm chí cho khách hàng. Ví dụ: chúng ta có thể thông báo cho người dùng, khách hàng hoặc những người hỗ trợ về các lỗi đã biết nhưng đã được hoãn lại hoặc chấp nhận. Chúng ta có thể chuyển các bài kiểm tra và môi trường kiểm tra cho những người sẽ thực hiện kiểm tra bảo trì. Chúng ta có thể cung cấp các gói kiểm tra hồi quy tự động hoặc thủ công cho khách hàng nếu họ tích hợp hệ thống của chúng ta vào một hệ thống lớn hơn.
Tham Gia Hồi Tưởng Dự Án – Retrospective Activities
Loại hoạt động kết thúc thử nghiệm phổ biến nhất là sử dụng các bản hồi quy dự án để ghi lại các bài học kinh nghiệm (cả tốt và xấu) từ dự án và lập kế hoạch quản lý các sự kiện, bất ngờ và vấn đề của các dự án trong tương lai tốt hơn. Ví dụ: trong quá trình phân tích hồi cứu dự án, chúng ta có thể nhận thấy rằng nhiều cụm lỗi không mong muốn trong quá trình thử nghiệm. Phát hiện này có thể giúp chúng ta mở rộng danh sách những người tham gia phân tích rủi ro chất lượng cho các dự án trong tương lai.
Có thể chúng ta đã bỏ sót đáng kể các ước tính của mình trong một số khía cạnh. Điều này có thể khiến chúng ta đánh giá được nguyên nhân gốc rễ của những sai lệch này. Những nguyên nhân như vậy có thể bao gồm nhiều lỗi hơn dự kiến, nhiều công việc kiểm thử hơn dự kiến, v.v. Sau đó chúng ta có thể áp dụng các kế hoạch để giải quyết những nguyên nhân đó trong tương lai.
Khi chúng ta nhận ra xu hướng và nguyên nhân lỗi, thì có thể sẽ có nhiều cơ hội để tìm ra lỗi sớm hơn, giảm số lượng lỗi hoặc ngăn chặn hoàn toàn lỗi.
Hãy nhớ rằng việc hồi cứu nên áp dụng cho thử nghiệm cũng như cho toàn bộ dự án và thậm chí là cho tổ chức rộng hơn. Các vấn đề có xu hướng mang tính hệ thống, không riêng lẻ.
Lưu Trữ Sản Phẩm Công Việc Kiểm Thử
Cuối cùng, việc kết thúc thử nghiệm bao gồm việc lưu trữ các công việc kiểm thử. Hoạt động kiểm thử cung cấp kết quả kiểm tra trung gian và cuối cùng, các file nhật ký kiểm tra, báo cáo trạng thái kiểm tra cũng như các tài liệu và sản phẩm công việc khác.
Chúng ta nên đặt những thứ này vào hệ thống quản lý cấu hình. Hệ thống đó phải liên kết các sản phẩm công việc kiểm thử khác nhau với hệ thống đang được thử nghiệm (cả về tên và phiên bản). Ví dụ: chúng ta nên nắm bắt và lưu trữ cả kế hoạch kiểm thử và kế hoạch dự án, cùng với các trường hợp kiểm thử, quy trình kiểm thử, dữ liệu kiểm thử và kết quả kiểm thử.
Ví Dụ Về Hoạt Động Kết Thúc Kiểm Thử
Sau lần phát hành đầu tiên của hệ thống HELLOCARMS, bạn tổ chức một cuộc họp hồi quy. Khi nghiên cứu kết quả, bạn phát hiện ra những điều sau:
- 27% các khiếm khuyết được báo cáo liên quan đến chức năng thế chấp ngược đã bị từ chối vì không phải là vấn đề thực tế.
- 25% lỗi được báo cáo đối với tính năng bảo hiểm nhân thọ tùy chọn đã bị từ chối vì không phải là vấn đề thực tế.
- 37% lỗi được báo cáo đối với LoDoPS đã bị từ chối vì không phải là vấn đề thực tế
Tỷ lệ từ chối báo cáo lỗi trung bình là 5% đối với nhóm của bạn. Bạn cho rằng điều đó có thể chấp nhận được, nhưng bất cứ điều gì trên 10% đều không thể chấp nhận được. Liệt kê ít nhất năm cải tiến tiềm năng để điều tra cho phiên bản thứ hai và các phiên bản tiếp theo.
Danh sách của bạn nên bao gồm một số điều sau đây:
- Sử dụng chương trình đào tạo, tuyển dụng hoặc hỗ trợ người dùng để nâng cao kiến thức chuyên môn về thế chấp ngược trong nhóm kiểm thử.
- Đánh giá xem các yêu cầu liên quan đến khiếm khuyết thế chấp ngược bị từ chối cụ thể có mơ hồ hoặc có sai sót hay không.
- Kiểm tra tỷ lệ cao các khiếm khuyết được báo cáo tại hiện trường liên quan đến các khiếm khuyết thế chấp ngược bị từ chối.
- Sử dụng hoạt động đào tạo, tuyển dụng hoặc hỗ trợ người dùng để nâng cao kiến thức chuyên môn về bảo hiểm nhân thọ trong nhóm thử nghiệm.
- Đánh giá xem các yêu cầu liên quan đến khiếm khuyết ở bảo hiểm nhân thọ bị từ chối cụ thể có mơ hồ hay có sai sót hay không.
- Kiểm tra tỷ lệ cao các khiếm khuyết được báo cáo tại hiện trường liên quan đến các khiếm khuyết bảo hiểm nhân thọ bị từ chối.
- Sử dụng hoạt động đào tạo, tuyển dụng hoặc hỗ trợ người dùng để nâng cao kiến thức chuyên môn về LoDoPS trong nhóm thử nghiệm.
- Đánh giá xem các yêu cầu liên quan đến các lỗi LoDoPS bị từ chối cụ thể có mơ hồ hay bị lỗi hay không.
- Kiểm tra tỷ lệ lỗi cao được báo cáo tại hiện trường liên quan đến lỗi LoDoPS bị từ chối.
- Tổ chức một cuộc họp với các nhà phát triển để thảo luận lý do tại sao các vấn đề cụ thể bị từ chối và tìm cách cải thiện giao tiếp giữa hai nhóm.
- Có quy trình xem xét lỗi để mỗi báo cáo lỗi được kiểm tra bởi một hoặc nhiều người kiểm tra trước khi báo cáo được nhập vào hệ thống theo dõi.
Ngoài những giải pháp trên đây, có lẽ bạn cũng có thể nghĩ được thêm nhiều giải pháp khác. Hãy nhớ rằng, điều quan trọng khi xem xét cải tiến là sử dụng dữ liệu.
Mình xin kết thúc loạt bài về quy trình kiểm thử tại đây. Cảm ơn các bạn đã luôn đồng hành cùng mình. Hẹn gặp lại các bạn trong các bài viết tiếp theo.
Happy testing!