+1

Hướng dẫn cách viết một báo cáo kiểm thử (Test report) một cách hiệu quả

Trong quy trình kiểm thử phần mềm, sau khi hoàn thành thực hiện test, QA trong dự án cần chuẩn bị một bản báo cáo tổng hợp kết quả kiểm thử. Tuy nhiên, có khá nhiều QA còn băn khoăn và lúng túng trong việc tạo một bản báo cáo chi tiết. Trong bài viết này chúng ta sẽ cùng nhau tìm hiểu cách viết báo cáo kiểm thử một cách rõ ràng và hiệu quả.

1. Báo cáo tóm tắt kiểm thử là gì?

Trước tiên, chúng ta cùng nhau tìm hiểu khái niệm báo cáo kiểm thử. Báo cáo Tóm tắt kiểm thử là một văn bản bàn giao quan trọng được chuẩn bị ở quá trình kiểm thử, hay đúng hơn là sau khi giai đoạn thực hiện kiểm thử được hoàn thành. Mục tiêu chính của tài liệu này là giải thích các chi tiết và hoạt động khác nhau về kiểm thử được thực hiện cho dự án, cho các bên liên quan tương ứng như Quản lý cấp cao, Khách hàng, v.v.

Là một phần của báo cáo trạng thái hàng ngày, kết quả kiểm tra hàng ngày sẽ được chia sẻ với các bên liên quan mỗi ngày. Nhưng Báo cáo Tóm tắt kiểm thử cung cấp một báo cáo tổng hợp về kiểm thử được thực hiện cho đến thời điểm hiện tại của dự án.

Giả sử rằng nếu Khách hàng ngồi ở một vị trí xa cần hiểu kết quả và trạng thái về một dự án được thực hiện kiểm thử trong một khoảng thời gian, ví dụ - bốn tháng, Báo cáo Tóm tắt kiểm thử sẽ giải quyết mục đích này.

2. Báo cáo tóm tắt kiểm thử bao gồm những thông tin gì?

Mẫu Báo cáo thử nghiệm điển hình sẽ chứa thông tin như bên dưới, tuy nhiên, dựa trên mỗi định dạng và thực tiễn của từng công ty, nội dung có thể khác nhau. Những chia sẻ dưới đây sẽ cung cấp cho các bạn các ví dụ thực tế để hiểu rõ hơn.

Dưới đây, mình sẽ hướng dẫn 12 bước chi tiết để tạo một báo cáo kiểm thử hiệu quả:

Bước 1: Mục tiêu của tài liệu báo cáo

<Mô tả ngắn về mục tiêu chuẩn bị tài liệu báo cáo>

Ví dụ: Tài liệu này giải thích các hoạt động khác nhau được thực hiện như là một phần của kiểm thử ứng dụng hệ thống vận chuyển ABCD.

Bước # 2: Tổng quan về ứng dụng

<Mô tả ngắn gọn về ứng dụng được thử nghiệm>

Ví dụ: Hệ thống giao thông ABCD, ứng dụng đặt vé xe buýt dựa trên web. Vé cho các xe buýt khác nhau có thể được đặt bằng cách sử dụng các phương tiện trực tuyến. Thông tin hành khách thời gian thực được nhận từ Hệ thống kho lưu trữ trung tâm, sẽ được giới thiệu trước khi đặt chỗ được xác nhận. Có một số mô-đun như Đăng ký, Đặt chỗ, Thanh toán và Báo cáo được tích hợp để hoàn thành mục tiêu.

Bước # 3: Phạm vi thử nghiệm

  • Trong phạm vi kiểm thử
  • Ngoài phạm vi kiểm thử
  • Các phần chức năng không được kiểm thử

<Phần này giải thích về các chức năng / mô-đun trong phạm vi & ngoài phạm vi để thử nghiệm; Bất kỳ mục nào không được kiểm tra do bất kỳ ràng buộc / phụ thuộc / hạn chế>

Ví dụ: Không thể kiểm tra xác minh chức năng cần kết nối với ứng dụng của bên thứ ba, vì không thể thiết lập kết nối do một số hạn chế kỹ thuật. Phần này phải được ghi lại rõ ràng, phần khác sẽ được giả định rằng Kiểm tra bao trùm tất cả các lĩnh vực của ứng dụng.

a) Trong phạm vi kiểm thử Kiểm tra chức năng cho các mô-đun sau nằm trong Phạm vi kiểm thử:

  • Đăng ký
  • Đặt trước
  • Thanh toán

b) Ngoài phạm vi Kiểm tra hiệu suất đã không được thực hiện cho ứng dụng này.

c) Các phần chức năng không được thử nghiệm Xác minh kết nối với hệ thống bên thứ ba Hệ thống kho lưu trữ trung tâm không được kiểm tra, vì kết nối không thể được thiết lập do một số hạn chế kỹ thuật. Điều này có thể được xác minh trong UAT (Kiểm tra chấp nhận người dùng) nơi kết nối có sẵn hoặc có thể được thiết lập.

Bước # 4: Số liệu

<Số liệu sẽ giúp hiểu kết quả thực hiện kiểm tra, trạng thái của các trường hợp kiểm tra & lỗi, v.v. Các số liệu cần thiết có thể được thêm vào khi cần thiết. Ví dụ: Tóm tắt lỗi-Mức độ ảnh hưởng của lỗi lên hệ thông; Phân bố lỗi trên các chức năng / Mô-đun; vv .. Biểu đồ / Đồ thị có thể được đính kèm để thể hiện hình ảnh tốt hơn>

a) Số trường hợp thử nghiệm được lên kế hoạch so với thực hiện b) Số trường hợp kiểm tra đạt / không đạt

c) Số lượng bug được tìm thấy kèm theo trạng thái và mức độ ảnh hưởng

d) Phân phối các lỗi trên các chức năng, mô đun

Bước 5: Các loại kiểm thử được thực hiện

  1. Kiểm thử khói
  2. Kiểm thử tích hợp hệ thống
  3. Kiểm thử hồi quy

*<Mô tả các loại Thử nghiệm khác nhau được thực hiện cho Dự án. Điều này sẽ đảm bảo ứng dụng đang được kiểm tra đúng cách thông qua các loại thử nghiệm được thống nhất theo Chiến lược thử nghiệm.

Lưu ý: Nếu một số vòng Thử nghiệm đã được thực hiện, các chi tiết cũng có thể được đưa vào đây.>*

Ví dụ: a) Kiểm thử khói Thử nghiệm này được thực hiện bất cứ khi nào Build được nhận (triển khai vào môi trường Test) để Kiểm tra để đảm bảo chức năng chính hoạt động tốt, Build có thể được chấp nhận và Thử nghiệm có thể bắt đầu.

b) Kiểm thử tích hợp hệ thống

Đây là Thử nghiệm được thực hiện trên Ứng dụng đang được thử nghiệm, để xác minh toàn bộ ứng dụng hoạt động theo yêu cầu. Các kịch bản kinh doanh quan trọng đã được thử nghiệm để đảm bảo chức năng quan trọng trong ứng dụng hoạt động như dự định mà không có bất kỳ lỗi nào.

c) Kiểm thử hồi quy

Kiểm tra hồi quy được thực hiện mỗi khi bản dựng mới được triển khai để kiểm tra có sửa lỗi và cải tiến mới nếu có. Kiểm tra hồi quy đang được thực hiện trên toàn bộ ứng dụng chứ không chỉ là các chức năng mới và sửa lỗi. Thử nghiệm này đảm bảo rằng chức năng hiện có hoạt động tốt sau khi sửa lỗi và các cải tiến mới được thêm vào ứng dụng hiện có. Các trường hợp thử nghiệm cho chức năng mới được thêm vào các trường hợp thử nghiệm hiện có và được thực thi.

Bước # 6: Kiểm tra môi trường & công cụ

<Cung cấp chi tiết về Môi trường thử nghiệm trong đó Thử nghiệm được thực hiện. Máy chủ, cơ sở dữ liệu, URL ứng dụng, v.v ... Nếu bất kỳ Công cụ nào được sử dụng như Trung tâm chất lượng (hiện là HP ALM) để ghi nhật ký lỗi>

Bước 7: Bài học

<Phần này được sử dụng để mô tả các vấn đề quan trọng phải đối mặt và các giải pháp của họ (cách chúng được giải quyết trong quá trình Thử nghiệm). Bài học kinh nghiệm sẽ giúp đưa ra quyết định chủ động trong lần tham gia Thử nghiệm tiếp theo, bằng cách tránh những sai lầm này hoặc tìm cách giải quyết phù hợp>

Bước # 8: Các khuyến nghị, gợi ý

<Bất kỳ cách giải quyết hoặc đề xuất nào có thể được đề cập ở đây>

Thí dụ:

Kiểm soát của quản trị viên đối với công cụ quản lý lỗi có thể được trao cho người quản lý Kiểm tra Offshore để cung cấp quyền truy cập vào nhóm Kiểm tra. Mỗi lần Quản trị viên tại chỗ không cần liên hệ với các yêu cầu bất cứ khi nào chúng phát sinh, do đó tiết kiệm thời gian do chênh lệch múi giờ địa lý.

Bước # 9: Các hành động thực tiễn tốt nhất

<Sẽ có rất nhiều hoạt động được thực hiện bởi nhóm Thử nghiệm trong dự án. Một số trong số chúng có thể đã tiết kiệm thời gian, một số được chứng minh là một cách tốt và hiệu quả để làm việc, v.v. Những thứ này có thể được ghi lại dưới dạng ‘Giá trị Thêm, để giới thiệu với các SH*

Thí dụ:

Một nhiệm vụ lặp đi lặp lại được thực hiện thủ công mỗi lần là tốn thời gian. Nhiệm vụ này được tự động hóa bằng cách tạo tập lệnh và chạy mỗi lần, giúp tiết kiệm thời gian và tài nguyên. Các trường hợp kiểm tra khói được tự động hóa và các kịch bản đã được chạy, chạy nhanh và tiết kiệm thời gian. Các kịch bản tự động hóa đã được chuẩn bị để tạo ra các khách hàng mới, trong đó rất nhiều bản ghi cần được tạo để Thử nghiệm. Các kịch bản quan trọng trong kinh doanh được kiểm tra riêng trên toàn bộ ứng dụng, điều quan trọng để chứng nhận rằng chúng hoạt động tốt.

Bước # 10: Tiêu chí dừng kiểm thử

<Tiêu chí dừng kiểm thử được định nghĩa là Hoàn thành kiểm thử bằng cách đáp ứng một số điều kiện nhất định như (i) Tất cả các trường hợp thử nghiệm theo kế hoạch được thực hiện; (iI) Tất cả các lỗi nghiêm trọng đã bị đóng, v.v.>*

Thí dụ: a) Tất cả các trường hợp kiểm tra nên được thực hiện - Có b) Tất cả các khiếm khuyết về mức độ nghiêm trọng, nghiêm trọng, trung bình cần được xác minh và đóng - Có. c) Bất kỳ khiếm khuyết mở nào về mức độ nghiêm trọng tầm thường - Kế hoạch hành động được chuẩn bị với ngày đóng cửa dự kiến.

Không có khiếm khuyết Severity1 nên ‘MỞ HOẠT; Chỉ có 2 khuyết điểm Severity2 nên ‘MỞ RỘNG; Chỉ có 4 khuyết điểm Severity3 nên ‘MỞ. Lưu ý: Điều này có thể thay đổi từ dự án để dự án. Kế hoạch hành động cho các khuyết điểm mở cần được đề cập rõ ràng với các chi tiết về thời điểm và cách chúng sẽ được giải quyết và đóng lại.>

Bước # 11: Kết luận

<Phần này sẽ đề cập đến việc Nhóm Thử nghiệm có đồng ý hay không và đưa ra tín hiệu Xanh cho ứng dụng Phát trực tiếp hay không sau khi Tiêu chí Thoát được đáp ứng. Nếu ứng dụng không đáp ứng Tiêu chí Thoát, thì có thể đề cập đến nó như thế - Ứng dụng không được đề xuất cho ‘Truy cập Live. Nó sẽ được để lại với quyết định của Quản lý cấp cao và Khách hàng và các Bên liên quan khác có liên quan để thực hiện cuộc gọi về việc ứng dụng có thể ‘Truy cập Live hay không.>*

Ví dụ: Vì các tiêu chí Thoát được đáp ứng và thỏa mãn như được đề cập trong Phần 10, ứng dụng này được đề xuất để Live Phát trực tiếp bởi nhóm Thử nghiệm. Kiểm tra chấp nhận người dùng / doanh nghiệp phù hợp nên được thực hiện trước ‘Truy cập trực tiếp.

Bước # 12: Định nghĩa, từ viết tắt

<Phần này đề cập đến ý nghĩa của các thuật ngữ viết tắt được sử dụng trong tài liệu này và bất kỳ định nghĩa mới nào khác>

3. Một số điểm cần lưu ý trong khi chuẩn bị Báo cáo Tóm tắt Thử nghiệm:

  • Là một phần của Thực thi thử nghiệm, thu thập tất cả thông tin bắt buộc về Thử nghiệm được thực hiện. Điều này sẽ giúp chuẩn bị một báo cáo tóm tắt thử nghiệm âm thanh.
  • Bài học kinh nghiệm có thể được giải thích chi tiết, điều này sẽ truyền đạt Trách nhiệm được thực hiện để giải quyết các vấn đề này. Ngoài ra, đây sẽ là một tài liệu tham khảo cho các dự án sắp tới để tránh những điều này.
  • Tương tự như vậy, việc đề cập đến các Thực tiễn Tốt nhất sẽ mô tả những nỗ lực mà nhóm đã thực hiện ngoài việc thử nghiệm thông thường, cũng sẽ được coi là một Giá trị Bổ sung Hồi quy.
  • Đề cập đến các số liệu ở dạng đồ họa (Biểu đồ, đồ thị) sẽ là một cách tốt để thể hiện trực quan trạng thái & dữ liệu.
  • Hãy nhớ rằng, báo cáo tóm tắt thử nghiệm sẽ đề cập và giải thích các hoạt động được thực hiện như một phần của Thử nghiệm, để người nhận hiểu rõ hơn.
  • Một số phần thích hợp hơn có thể được thêm vào nếu cần.

Phần kết luận:

Báo cáo tóm tắt thử nghiệm là một phân phối quan trọng và cần tập trung để chuẩn bị một tài liệu hiệu quả, vì hiện vật này sẽ được chia sẻ với các bên liên quan khác nhau như quản lý cấp cao, khách hàng, v.v.

Sau khi thực hiện kiểm tra toàn diện, công bố kết quả kiểm tra, số liệu, thực tiễn tốt nhất, bài học kinh nghiệm, kết luận về ‘Go Live, v.v ... là cực kỳ quan trọng để tạo ra bằng chứng cho Thử nghiệm được thực hiện và kết luận Thử nghiệm.

Tài liệu tham khảo:

Bài viết được dịch từ tài liệu sau: https://www.softwaretestinghelp.com/test-summary-report-template-download-sample/

Xem thêm các bài viết chia sẻ về kiến thức kiểm thử phần mềm tại đây


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí