How to report Test execution smartly

Lời tựa: Trách nhiệm giải trình và tính minh bạch (A & T) rất cần thiết cho mọi dự án CNTT ở các cấp khác nhau - Mức độ dự án, cấp độ nhóm, cấp nhiệm vụ trong công việc và cả cấp độ cá nhân. Làm thế nào để chúng ta chắc chắn rằng những thuộc tính này được đáp ứng? Câu trả lời là - sự giao tiếp hoặc chính thức hơn - báo cáo trạng thái!

Ở mức độ cá nhân, không phải tất cả chúng ta đều gửi các báo cáo, chủ yếu, EOD hàng ngày để truyền đạt rằng các task đã được hoàn thành (hoặc không hoàn thành) hàng ngày. Điều này chứng minh rằng, bạn thực sự "đang" nhận thức được nhiệm vụ của mình bắt đầu.

1. Daily Status Report (Báo cáo tiến trình trạng thái hàng ngày)

Những thông tin cần nêu ra trong báo cáo trạng thái hàng ngày đó là:

• Bạn đã làm được j ngày hôm nay
• Kế hoạch ngày mai làm gì?
• Bạn có gặp vấn đề nào trong cả ngày hôm nay không? Nếu có thì vấn đề đó đã giải quyết được chưa hay vẫn dở dang?
• Bạn có cần dữ liệu đầu vào (inputs) nào cho ngày mai không? Nếu có thì lấy inputs từ đâu và cần những gì? Người nhận email/ báo cáo này thường là giám đốc, trưởng bộ phận hoặc cũng có thể là các thành viên trong team được CC - Điều này được phụ thuộc vào giao thức truyền đạt mà team đang áp dụng.

2. Test report (Báo cáo thử nghiệm)

Bây giờ, chúng ta sẽ tìm hiểu cụ thể về các báo cáo mà các nhóm Thử nghiệm / QA gửi.

Các đội thử nghiệm gửi các báo cáo khác nhau ở các giai đoạn khác nhau trong quá trình phát triển phần mềm

• Trạng thái kế hoạch thử nghiệm
• Trạng thái kiểm tra tài liệu
• Trạng thái thực hiện thử nghiệm (tình trạng lỗi)

Kế hoạch thử nghiệm: Có thể giao tiếp với các nhóm dự án còn lại, khi kế hoạch thử nghiệm được tạo ra hoặc khi có thay đổi lớn.

Tài liệu kiểm tra - Hãy để tất cả các nhóm biết khi thiết kế kiểm thử, thu thập dữ liệu và các hoạt động khác khi bắt đầu và cũng như khi chúng đã kết thúc. Báo cáo này sẽ không chỉ cho họ biết về sự tiến triển của công việc mà còn là những dấu hiệu của team khi cần phải xem xét và kí kết rằng họ đang lên kế hoạch tiếp theo.

Thực hiện kiểm thử - Thực thi test là một giai đoạn của dự án khi nhóm kiểm tra là trọng tâm chính -cả nghĩa tích cực và tiêu cực - chúng ta đóng vai cả những anh hùng và những kẻ phản diện.

Điển hình trong chu kỳ thử nghiệm không được thực hiện, trừ khi báo cáo trạng thái hàng ngày được gửi đi. Ở một số đội, họ có thể chấp nhận về một báo cáo hàng tuần, nhưng việc gửi báo cáo hàng ngày là phải theo chuẩn.

Thông thường thì luôn có cuộc họp về tình trạng hàng ngày (hoặc tuần) để trình bày tình trạng của nhóm QA cho các bên có liên quan.

Do đó, chế độ báo cáo trạng thái có thể là:

Email / tài liệu Họp / trình bày Cả hai - email hàng ngày và cuộc họp hàng tuần hoặc tương tự như vậy.

3. Báo cáo Tình trạng Thực hiện Thử nghiệm

• Báo cáo Thực thi kiểm thử Hàng ngày / Hàng tuần:

Nó là gì? Thông thường, đây là thông báo được gửi ra để thiết lập tính minh bạch cho các hoạt động của nhóm QA trong ngày trong suốt chu trình kiểm thử - bao gồm cả thông tin lỗi và thông tin về các trường hợp chạy thử.

Ai nên tham dự buổi báo cáo này? - Thông thường, Nhóm phát triển, Nhóm hỗ trợ môi trường, Nhà phân tích nghiệp vụ và nhóm dự án là những người nhận / những người tham dự cuộc họp. Kế hoạch thử nghiệm (Test plan) là tài liệu tốt nhất để bạn tìm ra thông tin này.

• Báo cáo trạng thái thực thi kiểm thử bao gồm những gì?
  • Số lượng trường hợp test dự kiến thực thi trong ngày là bao nhiêu?
  • Số lượng trường hợp test đã thực thi trong ngày là bao nhiêu?
  • Tổng số lượng trường hợp test đã thực thi là bao nhiêu ?
  • Số lượng lỗi (bugs) đã tìm ra trong ngày? Trạng thái tương ứng của lỗi?
  • Số lượng lỗi (bugs) đã tìm ra được cho đến ngày hiện tại là bao nhiêu? Và trạng thái tương ứng của lỗi?
  • Số lượng bugs logic vẫn còn open là bao nhiêu?
  • File đính kèm của sheet thực thi test/ Hoặc link đến tool quản lý kiểm thử nơi lưu tài liệu testcases
  • File đính kèm của báo cáo bugs/ hoặc link đến tool quản lý kiểm thử Biểu đồ dưới đây thể hiện cho số lượng lỗi còn đang open Bạn có thể dùng các màu để phân biệt các tình trạng của bug ví dụ như Màu xanh: Đúng hạn Cam: Hơi trễ một chút (nhưng trong giới hạn cho phép) Đỏ: bị delay, chậm trễ Theo đó, báo cáo cũng có thể có bao gồm các điều kiện khác nữa: Kế hoạch hoạt động tiếp theo là gì/ Hoặc mọi người có cần dữ liệu đầu vào nào cho các team khác hoặc tương tự như thế không? Cuối cùng, sau đây là vài gợi ý để giúp cho quá trình này hoàn thiện hơn:

• Hãy vắn tắt và xúc tích khi hoàn thành quá trình
• Đảm bảo kết quả bạn báo cáo là chính xác
• Sử dụng các gạch đầu dòng giúp báo cáo dễ đọc hơn
• Kiểm tra kép đảm bảo đúng ngày tháng, chủ đề, danh sách và tài liệu đính kèm. Nếu báo cáo quá lớn và có quá nhiều yếu tố để báo cáo: hãy đặt nó ở vị trí thông thường dưới dạng tệp và gửi liên kết trong email thay vì tệp tin đó (Hãy chắc chắn rằng người nhận có quyền truy cập vào vị trí này và tệp tin ) Nếu đó là một cuộc họp về tình trạng - Chuẩn bị cho buổi thuyết trình, đến đúng giờ và quan trọng nhất là (đừng quá tự hào về những bugs tìm ra - vì chúng vẫn là những "tin xấu"). Dưới đây là mẫu báo cáo trạng thái thử nghiệm của QA Báo cáo này gồm 3 sheets để truyền đạt các mức thông tin khác nhau
  • Sheet 1: Giống như bản kết luận về tổng thể các trạng thái trong dự án
  • Sheet 2: Chi tiết về trạng thái của testcases
  • Sheet 3: Biểu mẫu về báo cáo lỗi