Cách Viết Test Case Cho App / TOP #10 ❤️ Xem Nhiều Nhất & Mới Nhất 9/2022 ❣️ Top View | Ezlearning.edu.vn

Cách Viết Test Case Cho Phần Mềm

Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử

13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào

Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile

Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop

Bài 4. Kiểm Thử Ứng Dụng Di Động

1. Test Case là gì?

Các test case giúp hướng dẫn tester thông qua một chuỗi các bước để xác thực xem application có lỗi hay không và hoạt động theo yêu cầu của người dùng hay không. Học cách viết các test case đòi hỏi các kỹ năng viết cơ bản, chú ý đến chi tiết và tester phải hiểu rõ về application được test.

Thông thường, các test case được viết cho một mô-đun nhất định hoặc một phần của application, được nhóm thành một test suite. Không phải thông thường, một phiên test sẽ bao gồm nhiều test case vì thường sẽ có nhiều hơn một kịch bản cụ thể được test.

2. Một test case được viết tốt sẽ cho phép bất kỳ tester nào cũng hiểu được và thực hiện được test.

Khi viết test case, điều quan trọng là bạn phải đặt mình vào vị trí của người dùng và nghĩ về tất cả những điều bạn cho là cần thiết để application hoạt động đúng. Trước tiên là bạn phải nổ lực để viết các test case tốt trước sẽ giúp bạn tiết kiệm thời gian và công sức sau này. Các test case được viết tốt sẽ tạo ra sự khác biệt giữa một application được test tốt và một application được test không tốt.

Viết các test case – đặc biệt là viết một số lượng lớn trong cùng một lúc – có thể là một công việc tốn thời gian. Ở đây, chúng ta sẽ nghiên cứu một số mẹo về cách viết các test case, cùng với một mẫu của một test case ở cuối bài viết này.

3. Cách viết test case cho phần mềm:

3.1. Sử dụng một tiêu đề rõ ràng

Một test case tốt bắt đầu với một tiêu đề rõ ràng. Như một best practice, tốt nhất là đặt tên cho test case cùng với tên mô-đun mà bạn đang test. Ví dụ: nếu bạn đang test trang login, hãy thêm “ Login successfully.

Summary: Verify if a user will be able to login with a valid username and valid password.

Pre-condition: User created an account before.

Step by Step

1. Navigate to button 5. Observe

Expected result: Login successfully when entering username and password are correct

5. Công cụ để viết test case

Không có một phương pháp chính xác để viết lại nội dung các test case của bạn, nhưng có nhiều công cụ giúp quá trình viết các test case hiệu quả. Ví dụ, các test case thường được viết trong file excel. Nhiều testing team vẫn lựa chọn phương pháp này. Nó khá linh hoạt, bạn có thể tạo quy trình và phương pháp theo dõi các test case của riêng mình, nhưng nó cũng có thể cực kỳ tốn thời gian và cồng kềnh.

Một số team sử dụng các công cụ quản lý dự án để ghi lại các test case của họ. Đây là một thay thế tuyệt vời cho excel vì có khả năng share giữa các member trong team

Với một công cụ dành riêng cho các test case, bạn có thể viết các test case của mình, thực hiện các test của mình, báo cáo kết quả và cộng tác với nhóm của bạn trong mỗi bước của quy trình.

6. Lợi ích thêm của viết test case

Việc luyện tập viết test case giúp cho testing team có thể coverage được nhiều case nhất có thể xuyên suốt application, nhưng việc viết các test case thậm chí có tác động hơn đến việc đảm bảo chất lượng và trải nghiệm người dùng.

Bạn sẽ tìm thấy những lỗi trong thiết kế sớm hơn

Bạn sẽ tìm thấy các vấn đề về khả năng sử dụng

Những thành viên mới có thể nhận và test application mà không cần phải đào tạo nhiều

Nó có thể tạo sự đồng cảm với người dùng của bạn

Nó giúp bạn và những người khác hiểu về product

Khi viết test case bạn đã đặt bạn vào vị trí của người dùng, điều này tạo nên sự đồng cảm cho những người dùngthực sự sẽ sử dụng product của bạn. Điều này có thể giúp dễ dàng feedback trở lại về thiết kế và quá trình phát triển. Khi bạn viết các test case, bạn sẽ xác định các vấn đề và các điểm cần cải thiện, những vấn đề này có thể được giải quyết trước khi application được đưa lên production.

Viết test case có nghĩa là bất kỳ thành viên nào mới đều có thể dễ dàng tăng tốc độ làm việc trên dự án mà không cần đào tạo nhiều. Cuối cùng, các test case phác thảo chính xác cách sử dụng product và những gì được mong đợi.

Một bộ các test case tốt sẽ giúp các thành viên khác trong team có thể share cho người khác để dễ dàng tìm hiểu về dự án. Hãy nghĩ về việc hỗ trợ khách hàng. Team hỗ trợ có thể duyệt các test case để hiểu các tính năng sắp tới sẽ hoạt động như thế nào. Họ có thể sử dụng những test case đó để viết tài liệu kỹ thuật và nội dung trợ giúp.

7. Phần kết luận

Viết các test case cần phải thực hành và có hiểu biết về phần mềm đang được test. Các test case được viết tốt có thể làm cho quá trình test của bạn trơn tru hơn và giúp bạn tiết kiệm thời gian trong quá trình sau này. Hãy dùng một công cụ để bạn có thể quản lý và sắp xếp các test case của mình một cách hiệu quả.

Tham khảo

All Rights Reserved

Lập Trình Ứng Dụng Facebook

Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key

Cách Tải Ứng Dụng Trên App Store Cho Iphone

Điểm Danh Sự Thành Công Của Các App Bán Hàng Tại Việt Nam 2022

Viết App Ngành Bán Hàng Theo Yêu Cầu Tại Hà Nội

How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)

Cách Tạo Api Với Rails (Phần 2) Viết Test Case

Học Kiểm Thử Api Trong 10 Phút

Giới Thiệu Tool Swagger Ui

Cách Viết Rails Api Document

Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?

Đầu tiên, chúng ta cùng tìm hiểu:

A. Testcase là gì?

Testcase là các trường hợp kiểm thử bao gồm các hành động được thực hiện nhằm kiểm tra từng chức năng của ứng dụng phần mềm có hoạt động đúng theo như mong muốn hay không.

B. Làm thế nào để có thể viết được Testcase tốt?

I. Trước khi bắt tay vào việc viết Testcase thì chúng ta cần nhớ những điểm sau đây:

Là 1 newbie, mới gia nhập công ty, chúng ta nên hỏi QA leader về template viết Testcase và xin file đó để làm. ( Vì mỗi công ty sẽ có cách viết khác nhau)

Viết Testcase nhớ phải bám sát tài liệu yêu cầu ( spec)

1 Testcase ID không quá 15 bước ( step)

Trước khi viết Testcase thì ta nên đọc và phân tích tài liệu thật kĩ càng, có chỗ nào chưa hiểu thì đặt Q&A ( Question & Answer) với các member trong team hoặc QA leader hoặc khách hàng để việc viết testcase và test được chính xác và chắc chắn hơn.

II. Những nguyên tắc để viết TestCase tốt:1. Các trường hợp kiểm thử cần phải đơn giản và minh bạch: (Test Cases need to be simple and transparent)

Tạo các testcase đơn giản nhất có thể nhưng vẫn phải rõ ràng và dễ hiểu.

2. Tạo Testcase với vai trò mình là End -user (người dùng ứng dụng đó)

Mục tiêu cuối cùng của bất kì dự án phần mềm nào cũng là đáp ứng được tất cả các yêu cầu của khách hàng. Vậy nên đặt vị trí của mình là người dùng thì sẽ thực hiện test được hiệu quả hơn. Chứ không nên có suy nghĩ mình chỉ là QA, chỉ là tester nên mình cứ test theo những gì spec nói thôi. Khi thấy UI nó khó dùng thì ta nên ta feedback lại với PM hay với mọi người để tất cả cùng cân nhắc có nên thay đổi hay không.

3. Mỗi testcase đều phải được xác định

Đặt tên ID cho từng testcase để dễ dàng theo dõi

b, Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần / nhóm bằng nhau có xu hướng có cùng hành vi.

c,Kỹ thuật Bảng quyết định (Decision tables) : Phương pháp này tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.

d, Kỹ thuật đoán lỗi (Error Guessing Technique): Đây là đoán / dự đoán lỗi có thể phát sinh trong khi thực hiện test manual.

5. Review chéo (Peer Review): Sau khi tạo xong Testcase, hãy nhờ đồng nghiệp của bạn review giúp, có thể là QA leader hay QA cùng team để phát hiện ra các case mà bạn còn thiếu hoặc bạn chưa nghĩ tới.

C. Thực hành viết Testcase:

Khi join vào dự án, chúng ta được QA Leader giao cho nhiệm vụ là viết Testcase cho màn Login của 1 website với UI như thế này:

Ta sẽ viết theo format chuẩn như sau:

Testcase ID Test Scenario Test Steps Test Data Expected Results Actual Results Status

LG01

Check UI

As expected

Pass

LG02

Check button Sign in when user input valid data

4. User can login successfully and system go to the Homepage

As expected

Pass

LG03

Check button Sign in when user input invalid data

4. User cannot login and system shows error message: Email is invalid.

As expected

Pass

Qua 3 ví dụ trên các bạn có thể dễ dàng hơn với việc với Testcase rồi đúng không nào? Tương tự các case trên, các bạn áp dụng Kĩ thuật Bảng quyết định, ta sẽ có thêm các case sau:

Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu

Cách Test Api Như Thế Nào?

Hướng Dẫn Tạo Secure Rest Api Trong

Sử Dụng WordPress Rest Api Toàn Tập

Cách Sử Dụng Api WordPress Rest

Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop

Bài 4. Kiểm Thử Ứng Dụng Di Động

Checklist Cho Kiểm Thử Ứng Dụng Di Động

5 Cách Viết Ứng Dụng Di Động

Hướng Dẫn Viết Ứng Dụng Cho Điện Thoại

Viết Ứng Dụng Di Động Phong Cách Hướng Đến 2022

Đây là một danh sách kiểm thử cho các ứng dụng web và máy tính để bàn.Mục tiêu của bài viết là để chia sẻ một trong những danh sách kiểm thử toàn diện nhất.

Tầm quan trọng của việc sử dụng checklist cho việc kiểm thử

Duy trì một kho lưu trữ tiêu chuẩn của các trường hợp thử nghiệm tái sử dụng cho các ứng dụng của bạn sẽ đảm bảo các lỗi phổ biến nhất sẽ bị bắt một cách nhanh chóng hơn.

Checklist giúp nhanh chóng hoàn tất viết test case các phiên bản mới của ứng dụng.

Sử dụng lại test case giúp tiết kiệm tiền về nguồn lực để viết kiểm tra lặp đi lặp lại.

Các trường hợp kiểm tra quan trọng sẽ được đảm bảo luôn luôn làm cho nó gần như không thể quên.

Kiểm tra checklist có thể bởi dev để đảm bảo các vấn đề phổ biến nhất được cố định trong giai đoạn phát triển bản thân.

Thực thi các kịch bản với vai trò người dùng khác nhau ví dụ như người dùng admin, người dùng khách, …

Đối với các ứng dụng web những tình huống này có thể được thử nghiệm trên nhiều trình duyệt như IE, FF, Chrome, và Safari với các phiên bản của khách hàng đã được phê duyệt.

Thử nghiệm với độ phân giải màn hình khác nhau như 1024 x 768, 1280 x 1024, …

Ứng dụng nên được thử nghiệm trên nhiều màn hình như màn hình LCD, CRT, điện thoại xách tay, máy tính bảng, và di động.

Ứng dụng thử nghiệm trên các nền tảng khác nhau như các hệ điều hành Windows, Mac, Linux.

Giả định: Giả sử rằng ứng dụng của bạn hỗ trợ chức năng sau:

Các forms với các trường khác nhau.

Cửa sổ con.

Ứng dụng tương tác với cơ sở dữ liệu.

Tiêu chí tìm kiếm bộ lọc khác nhau và hiển thị kết quả.

Upload hình ảnh.

Chức năng gửi email.

Chức năng xuất dữ liệu.

Kịch bản thử nghiệm chung

GUI và khả năng sử dụng các kịch bản thử nghiệm

Tất cả các mục trên trang (ví dụ như hộp văn bản, tùy chọn radio, danh sách thả xuống) nên được sắp xếp đúng.

Các giá trị số nên được quyền biện minh trừ khi có quy định khác.

Đủ không gian cần được cung cấp giữa các trường nhãn, cột, dòng, thông báo lỗi, …

Thanh Scroll nên được kích hoạt khi cần thiết .

Kích thước font chữ, phong cách và màu sắc cho dòng tiêu đề, mô tả văn bản, nhãn, dữ liệu infiled, và thông tin điện lưới nên được tiêu chuẩn theo quy định tại SRS.

Mô tả hộp văn bản nên đa đường.

Trường Disabled nên được chuyển sang màu xám và người sử dụng không nên thiết lập tập trung vào các trường này.

Sau khi bấm vào bất kỳ trường văn bản đầu vào, con chuột mũi tên con trỏ nên được thay đổi để trỏ.

Người dùng không nên gõ vào thả xuống chọn danh sách.

10 Thông tin lấp đầy bởi người sử dụng sẽ được giữ nguyên khi có thông báo lỗi trên trang submit. Người sử dụng sẽ nộp submit lại bằng cách sửa chữa các lỗi.

Kiểm tra nếu trường nhãn thích hợp được sử dụng trong các thông báo lỗi.

Giá trị trường Dropdown sẽ được hiển thị trong định nghĩa thứ tự sắp xếp.

Tab và Shift + Tab nên hoạt động đúng.

Tùy chọn mặc định radio nên được lựa chọn trước khi load trang.

Dòng mức cụ thể và trang trợ giúp thông điệp nên có sẵn.

Kiểm tra nếu các trường chính xác đã được nhấn mạnh trong trường hợp lỗi.

Kiểm tra xem tùy chọn danh sách thả xuống là có thể đọc được và không phải cắt ngắn nhờ vào trường kích thước giới hạn.

Tất cả các nút trên trang nên có thể truy cập bằng phím tắt và người dùng sẽ có thể thực hiện tất cả các hoạt động sử dụng bàn phím.

Kiểm tra tất cả các hình ảnh bị broken.

Kiểm tra tất cả các trang liên kết hỏng.

Tất cả các trang nên có tiêu đề.

Thông báo xác nhận sẽ được hiển thị trước khi thực hiện bất kỳ bản cập nhật hoặc xóa các hoạt động.

Giờ glass sẽ được hiển thị khi ứng dụng đang bận.

Trang văn bản nên để biện minh.

Người sử dụng nên có thể chỉ chọn một tùy chọn radio và bất kỳ sự kết hợp với hộp kiểm tra.

Kịch bản thử nghiệm cho bộ lọc tiêu chuẩn

Người sử dụng sẽ có thể lọc kết quả sử dụng tất cả các thông số trên trang chức năng tìm kiếm.

Tinh chỉnh nên tải trang tìm kiếm với tất cả người sử dụng lựa chọn các thông số tìm kiếm.

Khi có ít nhất một trong các tiêu chí lọc là cần thiết để thực hiện các hoạt động tìm kiếm, đảm bảo đúng thông báo lỗi được hiển thị khi người dùng gửi trang mà không chọn bất kỳ tiêu chí lọc.

Khi có ít nhất một trong các tiêu chí lọc lựa chọn không phải là người sử dụng bắt buộc sẽ có thể gửi trang và mặc định tiêu chí tìm kiếm nên được sử dụng để truy vấn kết quả.

Tin nhắn xác nhận đúng sẽ được hiển thị cho các giá trị hợp lệ cho tiêu chí lọc.

Kịch bản thử nghiệm cho lưới kết quả

Kịch bản thử nghiệm cho một cửa sổ

Kiểm tra xem kích thước cửa sổ mặc định là chính xác.

Kiểm tra xem kích thước cửa sổ con là đúng.

Kiểm tra nếu có bất kỳ trường trên trang tập trung mặc định (trọng tâm cần được thiết lập trên trường input đầu tiên của màn hình).

Kiểm tra xem cửa sổ con đang nhận được đóng vào đóng cửa sổ cha / mở window.

Nếu cửa sổ con được mở ra, người sử dụng không nên sử dụng hoặc cập nhật bất kỳ trường trên nền hoặc cửa sổ cha.

Kiểm tra cửa sổ tối thiểu, tối đa và chức năng đóng cửa sổ.

Kiểm tra nếu cửa sổ khá lớn.

Kiểm tra chức năng thanh cuộn cho cửa sổ cha và con.

Kiểm tra hủy bỏ chức năng của nút cho cửa sổ con.

Cơ sở dữ liệu kiểm tra kịch bản thử nghiệm

Kịch bản thử nghiệm cho hình ảnh tính năng tải lên

(Cũng được áp dụng cho các chức năng upload file khác)

Kịch bản thử nghiệm cho việc gửi email

Gửi email mẫu nên sử dụng CSS tiêu chuẩn cho tất cả các email .

Địa chỉ Email phải được xác nhận trước khi gửi email.

Ký tự đặc biệt trong trường email nên được xử lý đúng cách.

Ký tự ngôn ngữ cụ thể (ví dụ như ký tự ngôn ngữ Nga, Trung, Đức) phải được xử lý đúng cách trong trường email.

Tiêu đề email không nên để trống.

Trường placehoder được sử dụng trong mẫu email phải thay thế bằng giá trị thực tế ví dụ như {FirstName} {Lastname} nên được thay thế với các cá thể đầu tiên và cuối cùng tên đúng cho tất cả người nhận.

Nếu báo cáo với các giá trị động mới có trong nội dung email, dữ liệu báo cáo phải được tính toán một cách chính xác.

Email tên người gửi không nên được trống.

Email nên được kiểm tra trong các khách hàng email khác như Outlook, Gmail, Hotmail, Yahoo! Mail, …

Kiểm tra chức năng gửi email sử dụng TO, CC và BCC.

Kiểm tra văn bản email thô.

Kiểm tra HTML định dạng email.

13 . Kiểm tra tiêu đề email và footer cho logo của công ty, chính sách bảo mật và các liên kết khác.

Kiểm tra email với file đính kèm.

Kiểm tra chức năng gửi email tới đơn, đa hoặc phân phối người nhận danh sách.

Kiểm tra nếu trả lời vào địa chỉ email là chính xác.

Kiểm tra gửi khối lượng lớn các email.

Kịch bản thử nghiệm cho chức năng Excel Export

Tập tin nên được xuất trong hợp phần mở rộng tập tin.

Tên tập tin cho tập tin Excel được xuất nên được theo các tiêu chuẩn, ví dụ như nếu tên tập tin được sử dụng dấu thời gian, nó nên được thay thế đúng vào thời điểm thực tế tại thời điểm xuất các tập tin

Kiểm tra định dạng ngày nếu tập tin Excel xuất chứa các cột ngày.

Kiểm tra số định dạng cho giá trị số hoặc tiền tệ. Định dạng nên được giống như hiển thị trên trang.

Tệp tin xuất nên có cột với tên cột thích hợp.

Mặc định trang phân loại phải được tiến hành trong tập tin xuất như vậy.

Dữ liệu tập tin Excel nên được định dạng đúng với tiêu đề và văn bản footer, ngày, số trang, … giá trị cho tất cả các trang.

Kiểm tra xem dữ liệu hiển thị trên trang và tập tin Excel xuất là như nhau.

Chức năng xuất khi pagination được kích hoạt.

Kiểm tra nếu nút xuất là hiển thị biểu tượng thích hợp theo loại tập tin xuất biểu tượng như file Excel là xls.

Kiểm tra chức năng xuất cho các tập tin có kích thước rất lớn.

Kiểm tra chức năng xuất cho các trang có chứa ký tự đặc biệt. Kiểm tra xem các ký tự đặc biệt được xuất đúng trong tập tin Excel.

Hiệu suất kịch bản thử nghiệm

Kiểm tra thời gian tải trang nằm trong phạm vi chấp nhận được.

Kiểm tra tải trang trên các kết nối chậm.

Kiểm tra thời gian phản ứng đối với bất kỳ hành động dưới ánh sáng, bình thường, trung bình và điều kiện tải nặng.

Kiểm tra thực hiện các thủ tục cơ sở dữ liệu được lưu trữ và gây nên.

Kiểm tra thời gian thực hiện truy vấn cơ sở dữ liệu.

Kiểm tra tải trọng của ứng dụng.

Kiểm tra thử nghiệm stress của ứng dụng.

Kiểm tra CPU và bộ nhớ sử dụng trong điều kiện tải cao điểm.

An ninh kiểm tra kịch bản thử nghiệm

Bài viết này cố gắng để đảm bảo tất cả các kịch bản thử nghiệm tiêu chuẩn cho các chức năng ứng dụng web và máy tính để bàn. Nhưng đây không phải là một danh sách kiểm tra đầy đủ. Với các dự án khác nhau có danh sách kiểm tra thử nghiệm của riêng mình dựa trên kinh nghiệm của tester.

Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile

13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào

Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử

Cách Viết Test Case Cho Phần Mềm

Lập Trình Ứng Dụng Facebook

Cách Viết Test Report (Part 1)

Cách Viết Bài Review Sản Phẩm Hay (Viết Ra Tiền

Hướng Dẫn Cách Viết Bài Review Sản Phẩm Từ A

Hướng Dẫn Cách Viết Bài Review Hay Và Thu Hút Nhiều Người Đọc

Hướng Dẫn Cách Viết Bài Review Chất Lượng Kiếm Tiền Trên Mạng

Review Là Gì ? Cách Để Viết Bài Review Xuất Sắc Nhất

Hôm nay chúng ta sẽ tìm ra câu trả lời cho những câu hỏi: Làm thế nào để viết Test Report? Tại sao nên viết Test Report? Test Report được chuẩn bị cho ai? Bài viết này sẽ hữu ích cho những chuyên gia không chỉ trong lĩnh vực kiểm thử phần mềm mà còn từ những lĩnh vực khác như Project Managers, Product Owners, Developers …

Trong phần này mình sẽ làm rõ về những câu hỏi sau:

Test Report là gì, và tại sau chúng ta nên viết Test Report?

Test Report được chuẩn bị cho ai?

Ví dụ về thời gian làm Test Report (báo cáo kiểm thử)

1. Test Report là gì, và tại sau chúng ta nên viết Test Report?

Report (báo cáo) là mẫu tài liệu quan trọng và rút gọn về các thông tin thay đổi từ người thực thi tới khách hàng. Nhắc lại về quy trình kiểm thử phần mềm, chúng ta có những trạng thái sau:

Project creating (Khởi tạo dự án)

Test Plan pparing Execute testing (Chuẩn bị kế hoạch kiểm thử)

Test Case execution (Thực thi test case)

Finding bugs (Tìm lỗi)

Making reports (Làm báo cáo)

Như bạn có thể thấy các bản báo cáo được chuẩn bị có thể chứa các thông tin về hoạt động từ các trạng thái trước. Nên chúng ta có thể xác định Test Report như một tài liệu chứa các thông tin về các hành động đã được thực thi (Chạy test cases, phát hiện lỗi, thời gian bỏ ra…) và các kết quả của quá trình thực thi này (test case không thành công/thành công, số lượng bugs và crashes…)

Chúng ta có thật sự cần chuẩn bị Test Reports? Không nghi ngờ gì nữa câu trả lời là “Có”. Thực tế có ít nhất 3 lý do cho việc chuẩn bị Test Reports:

Bản Test Report tốt sẽ cho phép chúng ta (và không chỉ riêng chúng ta) có thể đánh giá trạng thái hiện tại của dự án cũng như chất lượng của sản phẩm.

Có khả năng đưa ra những quyết định sáng suốt nếu cần thiết.

Test Report có thể là tài liệu cuối cùng xác định việc sản phẩm đã sẵn sàng phát hành hay chưa.

Chất lượng và tính minh bạch là điều kiện bắt tiên quyết để tạo ra một Test Report. Bởi vì đấy là chìa khóa cho khách hàng đánh giá được giá trị công việc của chúng ta

2. Test Report được chuẩn bị cho ai?

Khi tạo một bản báo cáo, bạn phải hoàn toàn hiểu rõ bản báo cáo được viết cho ai, ai sẽ đọc nó. Dựa vào mức độ ưu tiên về người đọc mục tiêu, chúng ta cần phải xác định những thông tin nào bản báo cáo nên có. Có thể phân biệt được 3 nhóm mục tiêu sau:

Product Managers Họ tập trung vào việc thực thi theo các mốc deadline (ngày kết thúc), kết quả kiểm thử thuần túy mà không quan tâm đến các chi tiết kỹ thuật và thông số tổng thế.

Business Users (Product Owners) Như một điều luật, đây là những người đưa ra quyết định trong việc kết thúc kiểm thử. Họ cũng xác định chất lượng công việc đã hoàn thành. Điều quan trọng nhất với họ là kết quả cuối cùng, được chuyển thành dạng ngắn và rút gọn nhất (CÓ hay KHÔNG). Thông tin nên được trình bày dưới dạng trực quan (đồ thị, sơ đồ). Điều quan trọng là phải có ý kiến chuyên gia về khả năng phát hành sản phẩm mà không đi sâu vào chi tiết.

Tất nhiên, hầu như không thể viết một báo cáo mà sẽ phù hợp với tất cả các nhóm. Đó là lý do tại sao phải chắc chắn xác định đối tượng mục tiêu trước khi chuẩn bị một báo cáo kiểm thử. Tùy thuộc vào nó, nội dung sẽ rất khác nhau về cấu trúc và chứa các chi tiết khác nhau cần thiết cho nhóm cụ thể.

3. Ví dụ về thời gian báo cáo kiểm thử

Test Report ở khoảng thời gian giữa dự án nên thể hiển tiến độ công việc. Tiến độ không thay đổi nhưng linh động và được xác định bằng cách so sánh trạng thái của dự án ở các khoảng thời gian khác nhau (ngày, tuần, tháng). Trên thực tế, tiến độ là tập hợp các số liệu nhằm hiểu rõ các giai đoạn của dự án như thế nào.

Số liệu được tạo ra riêng biệt cho từng dự án, dựa trên các mục tiêu đã được xác định cho việc kiểm thử thành công. Chúng cho phép tạo ra sự so sánh tổng thế cho dự án một cách đủ nhanh.

Phiên bản của Test Report là một điều quan trọng khác và thường được dùng cho các báo cáo ở khoảng thời gian giữa dự án. Nó mô tả các nhiệm vụ được thực hiện bởi đội ngũ kiểm thử cho một phiên bản cụ thể của sản phẩm.

Bản báo cáo cuối cùng cho thấy một cái nhìn chung về công việc đã thực hiện (trong bối cảnh các thước đo chỉ số đã được thiết lập) và sự tiến triển của sản phẩm. Ngoài ra bạn cần phải cung cấp thông tin đầy đủ về trạng thái của sản phẩm tại thời điểm đó ( số lượng lỗi chưa sửa, liệu sản phẩm đã được kiểm thử đầy đủ chưa, hay là cần thêm chu kỳ kiểm thử nữa, độ sẵn sàng của sản phẩm cho việc phát hành)…

Trong bài viết sau về Test Report, mình sẽ nói chi tiết về nội dung của 1 Test Report, các gợi ý về các viết Test Report kèm theo ví dụ.

Tài Liệu Tham Khảo:

https://geteasyqa.com/qa/write-test-report/

Link phần 2: https://viblo.asia/p/cach-viet-test-report-part-2-end-LzD5dDYY5jY

All Rights Reserved

Hướng Dẫn Cách Trình Bày Report Tiếng Anh

Tuyển Dụng Cộng Tác Viên Viết Bài Review Sách 2022

4 Tips Cần Nhớ Để Có Một Bài Review Sách Xuất Sắc Nhất

Hướng Dẫn Cách Review Sách Sáng Tạo, Cuốn Hút

3 Cách Review Sách Độc Đáo Không Cần Viết

🌟 Home
🌟 Top