8 hướng dẫn viết testcase hoàn chỉnh

Để mang đến một sản phẩm phần mềm chất lượng đáng tin cậy thì việc phân tích yêu cầu là khâu vô cùng quan trọng trong quá trình xây dựng phần mềm. Hoạt động này đòi hỏi sự kết hợp rất chặt chẽ giữa khách hàng và người phân tích để vạch ra được xem chúng ta phải phát triển cái gì.

Yêu cầu của phần mềm là tất cả các yêu cầu về phần mềm do người dùng nêu ra bao gồm các chức năng của phần mềm, hiệu năng của phần mềm, giao diện của phần mềm và một số các yêu cầu khác.

Thông thường các yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau:

• Các yêu cầu về phần mềm
• Các yêu cầu về phần cứng
• Các yêu cầu về dữ liệu
• Các yêu cầu về con người

Mục tiêu quan trọng nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng.

Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Và việc của các kỹ sư phát triển phần mềm đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực và xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách hợp lý.

• Đọc và cố gắng hiểu mục đích của ứng dụng đang mong muốn là gì?
• Vừa đọc và hình dung, tưởng tượng xem phần mềm /màn hình đó sẽ chạy như thế nào.
• Thẩm định từng yêu cầu phần mềm để xác định xem chúng có khả năng thực hiện được hay không.
• Xác định các rủi ro có thể xảy ra với từng yêu cầu cụ thể.
• Thảo luận với BA về những băn khoăn, vướng mắc, bất hợp lý, chưa rõ ràng trong tài liệu đặc tả yêu cầu
• Viết Q & A gửi cho Khách Hàng

Hướng dẫn viết TESTCASES

Testcase là gì?

• Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì lý do này, việc chuẩn bị test case sớm nhất có thể trong qui trình phát triển phần mềm là rất hữu ích
• Các trường hợp kiểm thử phải bao phủ được toàn bộ luồng xử lý chức năng mô tả trong tài liệu phân tích và thiết kế; các yêu cầu về bảo mật an toàn thông tin, yêu cầu hiệu năng của hệ thống.

Mục đích kiểm thử ( Miêu tả testcase-Testcase Description ): + Miêu tả của test case là phần bạn sẽ đề cập một cách chi tiết những gì mà bạn sẽ test và cách xử lý riêng biệt được kiểm tra bằng test.

• “Miêu tả” của một test case nên đưa ra được “Mình sẽ test những gì”? (Ví dụ: Test nhập quá max length cho username)

Các bước thực hiện / Testcase Procedure:

• Dữ liệu đầu vào của test: định nhập cái gì để ra được kết quả mong muốn
• Việc xác định dữ liệu đầu vào của test thực sự là hoạt động tốn nhiều thời gian.
• Dữ liệu test chính là phần Input dữ liệu đầu vào, để hệ thống xử lý và trả ra Kết quả mong đợi
• Ví dụ: tester nhập dữ liệu test: 1.Nhập username = anhdt 2.Nhập password = abc@123 **Kết quả mong đợi / Expected result: **
• Một test case được viết tốt cần phải đề cập một cách rõ ràng kết quả mong đợi của ứng dụng hoặc hệ thống.
• Mỗi bước thiết kế test nên chỉ ra rõ ràng những gì bạn mong đợi
• Phần mềm sẽ phải chạy đúng như Kết quả mong đợi, nếu ko giống thì sẽ là Lỗi ( bug/ defect) và test case đó là Fail

Cột Kết quả test/Test result: Thông thường sẽ là pass, fail, và pending. Đây là kết quả thực tế khi thực hiện test theo test case trên môi trường của hệ thống

Một test case trong công nghệ phần mềm là một single step hoặc một chuỗi các step để xác nhận đúng các hành vi/chức năng của các tính năng nhất định của ứng dụng. Một testcase về cơ bản xác định liệu ứng dụng hay hệ thống phần mềm có làm việc như yêu cầu hay không. Mục đích của việc viết testcase là để giúp chuẩn hóa quá trình test và giảm thiểu những cách thức test tùy tiện hay ad-hoc. Có thể sẽ mất nhiều testcase để test một hệ thống phần mềm một cách đầy đủ và kỹ lưỡng trước khi nó được release.

Có 2 bước cơ bản khi viết một testcase là bước chuẩn bị và bước viết testcase. Bên dưới sẽ mô tả chi tiết cách thức thực hiện 2 bước này.

2. Chuẩn bị để viết một testcase

Cân nhắc testcase đó đã có hay chưa. Trước khi viết một testcase mới cho một module, bạn luôn cần tìm xem đã có testcase nào đã được viết để test cho cùng module đó hay chưa, điều này có thể giúp tiết kiệm nhiều thời gian. Nếu bạn đã tìm được testcase cho module đó thì hãy cân nhắc việc cập nhật nó thay vì viết một cái mới.

Biết những đặc điểm của một testcase tốt. Biết điều gì tạo nên một testcase tốt sẽ giúp bạn viết một testcase tốt hơn và mạnh hơn. Những đặc điểm này bao gồm:

• Tính chính xác: Phải làm rõ được mục đích của việc kiểm thử
• Khả năng của việc kiểm thử là có thể bám sát lại theo các yêu cầu
• Tính lặp lại: test case có thể được sử dụng để thực hiện test nhiều lần nếu cần.
• Tính tái sử dụng: test case có thể được sử dụng lại nếu cần thiết.
• Tính độc lập: Mỗi testcase bạn viết phải có thể được thực hiện theo bất kỳ thứ tự nào, mà không phụ thuộc vào các test case khác.
• Sự can thiệp: Mô tả về một testcase phải đơn giản, rõ ràng và không có các bước hoặc từ không liên quan. Một tester có thể hiểu nó bằng cách đọc nó một lần. Mô tả nên sử dụng các từ hành động, như "do 'x'" và "do 'y'."

Xem xét các kịch bản khác nhau trước khi viết. Tập trung vào điều gì có thể xảy ra với sản phẩm khi được sử dụng bởi khách hàng. Hãy suy nghĩ về điều này một cách cẩn thận và thiết kế các bài test của bạn cho phù hợp.

Kịch bản nên ngắn gọn. Mục tiêu của một test case không phải là cung cấp nhiều chi tiết cụ thể, mà thay vào đó là truyền đạt một ý tưởng cụ thể về thử nghiệm một trường hợp cụ thể.

Cho bản thân bạn đủ thời gian viết. Vì các kịch bản và trường hợp là cơ sở cho các test case và việc test trong tương lai, bạn cần cho mình đủ thời gian để viết một bài test chất lượng cũng như thời gian để quy trình test được xem xét kỹ lưỡng.

3. Viết một testcase

Chọn một công cụ để viết một test case. Bảng tính Excel rất được khuyến khích để viết các test case cơ bản và để test chúng theo cách thủ công. Khi bạn có kế hoạch tự động hóa các test case, hãy nghĩ đến việc lấy giấy phép, bản quyền cho các công cụ như Test Director. Ngoài ra còn có một số công cụ có thể được tải xuống miễn phí trên Internet.

Viết một test case với công cụ bạn chọn. Điều này sẽ cho phép bạn luôn giữ được sự theo dõi với test case và các dữ liệu liên quan. Một mẫu test case tốt bao gồm:

• Số serial: Đây là số đếm đại diện cho test case.
• ID của bộ test: Đây là số ID của bộ test mà test case này thuộc về.
• ID của test case: ID của test case.
• Tóm tắt test case: Mô tả tóm tắt test case hoặc mục tiêu của test case
• Yêu cầu liên quan: Số ID của yêu cầu mà test case này trỏ đến.
• Điều kiện tiên quyết: Đây là bất kỳ điều kiện tiên quyết nào phải được thực hiện trước khi thực hiện bài test.
• Phương pháp kiểm thử/Steps: Đây là phương pháp step-by-step để thực thi việc kiểm thử. Ở phần này, hãy mô tả thật cụ thể và rõ ràng, vì đây là thành phần quan trọng nhất của một test case. Mỗi bước có thể được viết trực tiếp bằng cách sử dụng các từ khóa như "nhập", "xác minh", "nhấp chuột", "đăng nhập", ...
• Kết quả dự kiến: Kết quả dự kiến ​​của bài test. Trong khi viết test case, hãy lưu ý trang / màn hình nào bạn muốn xuất hiện sau khi test. Bạn cũng có thể đính kèm ảnh chụp màn hình hoặc tài liệu đặc tả vào bước có liên quan và lưu ý rằng hệ thống nên hoạt động như được phác thảo để giúp đơn giản hóa bước và dự đoán kết quả và thực hiện quá trình dễ dàng hơn để làm theo cho người thử nghiệm.
• Kết quả thực tế: Đây là kết quả của bài test sau khi nó được thực hiện.
• Trạng thái: Đây là trạng thái sẽ xảy ra trong quá trình test, ví dụ: "Đạt" hoặc "Thất bại / Lỗi". Tình trạng khác cũng có thể được sử dụng, chẳng hạn như "Không được thực hiện" nếu test không được thực hiện và "Bị chặn" nếu test bị chặn.
• Lưu ý: Tại đây bạn có thể thêm bất kỳ nhận xét nào về test case hoặc quá trình thực hiện test case.
• Tạo bởi: Đây là tên của người tạo ra bài test.
• Ngày tạo: Đây là ngày khi bạn thực hiện test.
• Được thực hiện bởi: Đây là tên của người thực sự thực hiện bài test.
• Ngày thực hiện: Ngày bạn thực hiện test.
• Môi trường thử nghiệm: Các hệ thống trong đó các bài test được thực thi. Ví dụ, hệ điều hành và trình duyệt web bạn đã sử dụng.

Viết một bản tường trình cơ bản. Có một định dạng điển hình cho bản tường trình này:

• Xác minh [những gì đang được thử nghiệm].
• Sử dụng [tên công cụ, tên thẻ, hộp thoại, ...]. Thay vì "sử dụng", bạn cũng có thể dùng "nhập" hoặc "chọn", tùy thuộc vào tình huống của test case cụ thể của bạn.
• Với [điều kiện của bài test].
• Để [những gì được trả lại, hiển thị, chứng minh]

Review test case đã được viết. Công việc của bạn sẽ chưa hoàn thành sau khi bạn viết test case, bạn sẽ cần xem lại mọi thứ đã được viết và đánh giá rằng tất cả các bước đều rõ ràng và dễ hiểu và kết quả mong đợi phù hợp với các bước đó. Bạn có thể tự xem xét trường hợp và đánh giá bất kỳ khoảng trống hoặc khu vực bị thiếu nào bằng cách đặt mình vào vai trò của người kiểm tra. Bạn cũng có thể xem xét test case của mình bởi những tester ngang hàng (được gọi là việc review đánh giá ngang hàng), bởi người phát triển, bởi chủ sở hữu sản phẩm hoặc bất kỳ bên liên quan nào.

4. Lời khuyên

Trong khi viết các test case, hãy đảm bảo rằng tất cả các test case của bạn phải đơn giản và dễ hiểu. Hãy viết thật xúc tích, chính xác và đi vào mục tiêu ngay lập tức. Đừng viết một test case như một bài luận.

Viết test case của bạn đủ chi tiết để có thể đưa cho thành viên nhóm hoặc đồng nghiệp mới, người có thể dễ dàng thực hiện test và sẽ giúp xác định bất kỳ khu vực nào đang có vấn đề.