Viết test case từ tài liệu đặc tả yêu cầu

Bài viết được tham khảo từ nguồn:

http://www.softwaretestinghelp.com/writing-test-cases-from-srs-software-testing-qa-training-day-4/

Trong các bài trước tôi đã trình bày với các bạn về các vấn đề sau:

1. Review SRS: https://viblo.asia/trinh.thi.my.duyen/posts/MVpvKrggkKd

2. Tạo kịch bản kiểm thử: https://viblo.asia/trinh.thi.my.duyen/posts/WEMGBjqBGQK

Bây giờ, chúng ta sẽ cùng thực hành thực tế đó là thực hiện viết testcase.

Như đã nêu trong bài viết trước đây: Các trường hợp thử nghiệm được ghi nhận bởi nhóm QA trong khi giai đoạn Code trong vòng đời phát triển của phần mềm (SDLC) đang xảy ra. Nói cách khác, trong khi đội Dev xây dựng hệ thống phần mềm thì nhóm thử nghiệm sẵn sàng với các trường hợp thử nghiệm điều đó sẽ giúp đội thử nghiệm thuận lợi kiểm tra hệ thống khi nó đã sẵn sàng, nghĩa là vào cuối giai đoạn code.

Vì vậy, trong bài viết hôm nay, chúng tôi sẽ làm việc để biết test case là gì? làm thế nào để tạo ra chúng và viết vài trường hợp thử nghiệm mẫu cho một dự án cụ thể?

Hãy để chúng tôi chỉ ra cách mà chúng tôi đã làm nhé.

Khái niệm cơ bản viết Test case:

1.Nếu kịch bản thử nghiệm là tất cả về: "Những gì chúng ta sẽ kiểm tra" trên AUT – thì testcase là tất cả nội dung về việc "Làm thế nào chúng ta có thể kiểm tra một yêu cầu?".

Ví dụ, nếu các kịch bản thử nghiệm là "Xác nhận các chức năng quản trị đăng nhập".

• Từ ví dụ trên chúng ta sẽ thiết kế ra 3 testcase (hoặc là điều kiện):

• Đăng nhập (thành công).
• Đăng nhập-không thành công khi tên không chính xác đã được nhập
• Đăng nhập-không thành công khi nhập sai password.

=> Mỗi test case sẽ lần lượt có các bước để giải quyết như thế nào, chúng ta có thể kiểm tra một điều kiện thử nghiệm cụ thể được thỏa mãn hay không?

2.Các đầu vào để tạo ra một tài liệu test case trường hợp FRD, các kịch bản thử nghiệm tạo ra trong bước trước đó và bất kỳ tài liệu tham khảo khác nếu có.

3.Các tài liệu hướng dẫn trường hợp thử nghiệm là một chuyển giao quan trọng của đội ngũ QA và được chia sẻ với BA, PM và các đội khác, khi thực hiện xong cho ý kiến phản hồi của họ.

4.Công việc được phân chia giữa các thành viên trong nhóm và từng thành viên sẽ chịu trách nhiệm cho việc tạo ra các trường hợp thử nghiệm cho một module nào đó hoặc một phần của một module nào đó.

5.Cũng giống như với các kịch bản thử nghiệm, trước khi chúng ta bắt đầu tạo tài liệu test case, một template chung đã được thỏa thuận. Thực tế bất cứ điều gì có thể được sử dụng để tạo ra các test case. 2 sự lựa chọn thường xuyên nhất được sử dụng là MS Excel và MS Word.

6.MS từ mẫu trông giống như sau:

7.Template Excel có thể trông giống như sau:

8.Từ hai mẫu trên, có thể quan sát thấy rằng các lĩnh vực (hoặc các thành phần) để làm template testcase có thể nói là gần như là tương tự nhau, chỉ khác nhau về cách thức mà chúng được tổ chức.

Vì vậy, miễn là có các phương thức cho từng loại thông tin được bao gồm trong một test case, định dạng của các mẫu là không quan trọng. Tuy nhiên, với tôi tôi thường hay sử dụng bảng excel để tạo test case, bởi vì nó rất dễ dàng để mở rộng, thu nhỏ và sắp xếp, vv. Tuy nhiên, bạn nên chọn định dạng phù hợp nhất cho bạn.

Các trường trong test case:

Chúng ta hãy lấy một ví dụ, để quan sát các trường hợp mà là một phần của một test case.

Các trường khác có thể được giải thích như sau:

a) Điều kiện tiền đề – trạng thái của AUT (trạng thái trong đó AUT được cho là cần thiết để bắt đầu)

b) Đầu vào - bước nhập dữ liệu. Đối với những bước quan trọng là phải lưu ý những loại thông tin đầu vào được yêu cầu - dữ liệu thử nghiệm

c) Điểm Validation / kích hoạt / hành động – xác định những validation nào đang xảy ra? (Click vào một nút hoặc chuyển đổi hoặc truy cập liên kết. Hãy chắc chắn rằng có ít nhất một điểm xác nhận đến 1 test case- kiểm tra nếu không có nó tất cả sẽ là nhập dữ liệu với không có gì để tìm. Ngoài ra để đảm bảo rằng chúng tôi có đủ module, cố gắng không để kết hợp quá nhiều điểm xác nhận vào một trường hợp thử nghiệm. Mỗi một trường hợp thử nghiệm là tối ưu.)

d) Kết quả - Kết quả mong đợi

e) Điều kiện post - Đây là thông tin bổ sung được cung cấp cho các lợi ích của tester, chỉ để làm cho các trường hợp thử nghiệm sâu sắc hơn và có thông tin. Điều này bao gồm một lời giải thích về những gì sẽ xảy ra hoặc những gì có thể được dự kiến của AUT một khi tất cả các bước kiểm tra trường hợp được thực hiện.

Test case ví dụ cho một dự án: Bây giờ chúng ta có thông tin cơ bản đủ để bắt đầu quá trình tạo test case, chúng ta có được đi và tạo ra một vài test case cho dự án trực tiếp của chúng ta.

Căn cứ vào các quy trình nêu trên, chúng tôi đã tạo ra một số trường hợp thử nghiệm mẫu cho module dự án "Quản lý dịch vụ". Ở đây tôi sẽ cung cấp cho các bạn cách tạo testcase cho chức năng cụ thể như sau:

Có yêu cầu như sau:

Hệ thống về “Quản lý dịch vụ”. Hãy tạo testcase cho chức năng “Danh sách tổ chức”

Hình ảnh design như sau:

Nếu user click trên checkbox “Include In-active”, tất cả “Organisations” hoạt động hay không hoạt động sẽ hiển thị trên list.

User có thể sắp xếp Organisations bằng cách click đến tên cột.

Nếu user chọn [Inactive Organisation] trong list, hệ thống sẽ hiển thị message “Do you want to make this

Organization active?” với 2 button: OK và Cancel

• Nếu click [OK] button, màn hình “Organisation Details” sẽ hiển thị và hệ thống tự động cập nhật trạng thái của Organisation từ Inactive thành Active.

• Nếu click [Cancel] button, vẫn hiển thị màn hình “Organisation List” và trạng thái của “Organisation” vẫn là inactive

Phân tích về mặt chức năng:

1. Check hiển thị trên Form:

• Check hiển thị trên list: Hiển thị tất cả các “Organisations” hoạt động
• Trường hợp không có “Organisations” thì sẽ hiển thị blank.

2. Check hoạt động của checkbox: “Include In-active”

• Check đến checkbox: List hiển thị là những “Organisations” không hoạt động
• Uncheck đến checkbox: List hiển thị là tất cả những “Organisations” hoạt động hay không hoạt động

3. Check logic active và inactive của “Organisation”

3.1. Active or inactive không thành công

• Chọn trên list những “Organisation” is Inactive
• Click [Cancel] button
• Confirm trạng thái của “Organisation” trong list Expect: Hiển thị message: ““Do you want to make this Organization active?” Message biến mất Trạng thái của “Organisation” vẫn là Inactive

3.2. Active or inactive thành công

• Chọn trên list những “Organisation” is Inactive
• Click [OK] button
• Confirm trạng thái của “Organisation” trong list

Expect: Hiển thị message: ““Do you want to make this Organization active?”

Message biến mất

Trạng thái của “Organisation” chuyển sang là active

Viết Test Cases/ Phương pháp tối ưu hóa

Bây giờ, hãy tưởng tượng một tình huống mà một trang nào đó có khoảng 10 lĩnh vực trên đó hoặc có một logic kinh doanh phức tạp được thực hiện trong đó. Để chắc chắn rằng chúng tôi tối ưu hóa các quá trình tạo test case trong những tình huống như thế, tester có phương pháp tối ưu test case trong các trường hợp nhất định.

Dưới đây là danh sách các kỹ thuật để tạo testcase:

• Phân tích giá trị biên

• Phân vùng tương đương

• Đoán Lỗi - Đây là một phương pháp rất đơn giản và dựa vào trực giác của một thử nghiệm.

Một ví dụ là: Giả sử có một lĩnh vực ngày trên một trang. Các yêu cầu sẽ xác định rằng một ngày hợp lệ là được chấp nhận bởi lĩnh vực này. Bây giờ, một thử nghiệm có thể thử "ngày 30 tháng 2" như một ngày- vì theo như các con số được quan tâm, đó là một đầu vào hợp lệ, nhưng tháng Hai là một tháng mà không bao giờ có 30 ngày trong nó- vì vậy một đầu vào không hợp lệ.

• Biểu đồ chuyển trạng thái

• Bảng quyết định

Sử dụng các kỹ thuật nói trên và sau quá trình tạo test case tổng quát, chúng ta tạo ra một tập hợp các test case đó sẽ kiểm tra hiệu quả các ứng dụng trên tay.

Một vài điểm quan trọng cần lưu ý:

• Các test case chúng tôi tạo ra không chỉ là điểm tham chiếu cho các giai đoạn QA mà còn để UAT.

• Những testcase nội bộ đã được review từng phần trong team.

• Khi một tình huống nhất định không được giải quyết bằng một testcase - hãy sử dụng quy tắc của ngón tay cái, nó sẽ không được xét test. Vì vậy, đây là một nơi tốt để kiểm tra xem ở đâu test suite sẽ được tạo ra để đạt được mục tiêu bao phủ 100% hay không. Để làm được điều đó, một ma trận truy xuất nguồn gốc có thể được tạo ra. Kiểm tra tất cả những gì cần biết abouttraceability ma trận ở đây.

• Tools - các công cụ quản lý thử nghiệm như QC, qTest giúp chúng tôi với các hoạt động tạo ra trường hợp thử nghiệm. Đối với một ví dụ về cách các trường hợp thử nghiệm có thể được xử lý bằng cách sử dụng Trung tâm Chất lượng, kiểm tra hướng dẫn Trung tâm Chất lượng này.

• Công cụ tự động có thể được sử dụng để tạo ra các bài kiểm tra cases- trong trường hợp đó, họ được gọi là, các kịch bản thử nghiệm.

Phần kết luận:

Sự kết thúc của quá trình tạo thử nghiệm / thử nghiệm giai đoạn thiết kế (STLC) và kết thúc của giai đoạn Code (SDLC) nói chung sẽ đánh dấu sự kết thúc giai đoạn chuẩn bị thử nghiệm và bắt đầu của giai đoạn thực hiện thử nghiệm.

Trong bài viết tới, chúng tôi sẽ nói về execute test, những gì nó có và những gì mong đợi từ nhóm QA trong giai đoạn này.

KẾT LUẬN.

Chúng tôi hy vọng các bạn đang theo dõi cùng với loạt bài này. Vì lợi ích của sự đơn giản, có một vài trường hợp thử nghiệm đã được tạo ra. Tuy nhiên, kết quả tốt nhất có thể được nhìn thấy khi bạn làm việc trên thử nghiệm rộng rãi, có nghĩa là viết nhiều hơn và các trường hợp thử nghiệm hơn nữa. Vì vậy, hãy thực hành làm nhiều như bạn có thể.

Xin vui lòng cho chúng tôi biết câu hỏi và ý kiến của bạn nhé!