Viết test case là một trong những công việc quan trọng mà bất kỳ người kiểm thử nào cũng cần làm trong chu trình kiểm thử phần mềm của mình. Trong bài viết này, mình sẽ chia sẻ một số kinh nghiệm của mình để viết test case sao cho hiệu quả. Tuy nhiên, trước hết chúng ta hãy tìm hiểu định nghĩa về test case, tầm quan trọng của nó, cũng như format để viết một test case trong công việc kiểm thử nhé.
Test Case Là Gì?
Test case là một tài liệu mô tả tập hợp các hành động, các điều kiện và kết quả mong đợi mà tester cần xác minh đối với sản phẩm phần mềm. Đây là tài liệu căn bản cần có để xác định xem một phần mềm hoặc một trong các tính năng của nó có hoạt động theo đúng dự tính và mong muốn ban đầu hay không.
Một test case được xây dựng kém có thể dẫn đến những rò rỉ lỗ hổng đáng kể. Điều này làm tốn thời gian và tiền bạc. Do đó, việc xây dựng các test case hiệu quả là điều tối quan trọng đối với sự thành công của bất kỳ dự án phần mềm nào.
Format Của Một Test Case Tiêu Chuẩn
Dưới đây là format của ví dụ về test case login. Bạn có thể tải về mẫu template testcase tại đây.
Tuỳ thuộc vào mẫu test case khác nhau, có thể có thêm những thông tin khác nữa. Tuy nhiên một test case tiêu chuẩn cần có những thông tin về:
- Mã test case (Test Case ID)
- Mô tả Test Case (Test Case Description)
- Các bước thực hiện (Test Steps)
- Dữ liệu Test (Test Data)
- Kết quả kỳ vọng (Expected Results)
- Kết quả test (Test result)
Toàn bộ bảng này có thể được tạo trong Word, Excel hoặc bất kỳ công cụ quản lý Test nào. Tất cả đó điều được gọi là Tài liệu thiết kế Test case (Test Case Design Document).
Một Số Mẹo Để Viết Test Case Hiệu Quả
Thiết kế test case giống như một quá trình “dịch” câu chuyện của người dùng thành các trường hợp thử nghiệm. Điều này mang tới một loạt các câu hỏi như:
- Test case nên cụ thể hoặc bao quát tới mức nào?
- Test case nào cần được viết trước?
- Tôi nên đề cập tới khía cạnh nào của tính năng?
- Test case hiệu quả nên dài hay ngắn tới mức nào?
Thời gian và nguồn lực có hạn, nên việc viết tất cả các trường hợp kiểm thử là điều không thể. Làm sao để viết ít test case nhất mà vẫn đảm bảo chất lượng và quan trọng hơn cả là bao phủ những rủi ro nhất của sản phẩm? Viết test case là một nghệ thuật và điều quan trọng đối với toàn bộ quá trình này là test case phải rõ ràng, dễ hiểu cho tất cả các cá nhân tham gia. Hãy cùng mình xem xét một số quy tắc hữu ích khi viết test case nhé:
- Viết test case dựa vào mức độ rủi ro và độ ưu tiên Ưu tiên viết các test case nào trước cần dựa trên các mốc thời gian của dự án và các yếu tố rủi ro của sản phẩm. Ví dụ: Một tính năng rủi ro cao cần được release trong 6 tuần tới, và một tính năng ít rủi ro hơn cần được release trong tuần tới. Vậy cái nào cần ưu tiên hơn? Thật tiếc là không có câu trả lời cụ thể nào cho trường hợp này cả, mọi thứ cần dựa vào tình hình thực tế. Nếu bạn không thể quyết định, hãy hỏi thêm test leader, hoặc PM của bạn. Không có công thức chung nào cho tất cả các trường hợp kiểm thử, bạn sẽ cần phải giải quyết bài toán này nhiều lần.
- Quy luật 20/80 20% các trường hợp kiểm thử của bạn sẽ bao phủ được 80% sản phẩm. Lỗi thường phân bố tập trung. Ngay cả một kịch bản ngắn cũng có thể phát hiện ra một phần đáng kể các lỗi trong sản phẩm. Đó là lý do tại sao, tốt nhất bạn nên bắt đầu bằng một bộ kiểm thử từ đầu tới cuối quét qua mọi yêu cầu của phần cần xác minh trước khi bắt đầu đề cập sâu hơn đến các chi tiết cụ thể.
- Test case cần viết đơn giản và dễ hiểu Đảm bảo rằng các test case của bạn có thể được hoàn thành bởi những người khác khi cần thiết. Mình ví dụ trường hợp: Dự án đang yêu cầu gấp bạn cần nhờ các lập trình viên hỗ trợ kiểm tra sản phẩm dựa vào test case trong khi bạn đang bận kiểm tra những phần khác có độ rủi ro cao hơn mà bạn không thể giao cho bất kỳ ai. Sẽ ra sao nếu bộ test case chỉ mình bạn đọc và hiểu được? Việc đọc hiểu, xác nhận ý hiểu có thể tốn rất nhiều thời gian của hai bên, thậm trí một test case không rõ ràng có thể bị hiểu sai khiến việc hỗ trợ này không còn ý nghĩa nữa. Do vậy, khi viết test case hãy sử dụng những thuật ngữ rõ ràng, cố gắng viết đơn giản, ngắn gọn và dễ hiểu nhất có thể.
- Đặt mình vào góc độ người dùng Mục đích cuối cùng của bất kỳ sản phẩm phần mềm nào là để đáp ứng nhu cầu của khách hàng. Vì vậy test case cần thiết phải được xây dựng dựa trên quan điểm, góc nhìn của người dùng cuối. Điều này cũng đúng cả khi bạn tìm hiểu yêu cầu sản phẩm, cố gắng nhìn nhận dưới góc độ người dùng, nếu có điều gì đó bạn thấy không ổn hãy thẳng thắn góp ý với leader, BA, product owner thậm trí cả với khách hàng mà bạn đang hợp tác.
- Đừng giả định Không tự phán đoán, giả định tính năng của sản phẩm kiểm thử khi bạn chuẩn bị test case. Bám sát tài liệu đặc tả kỹ thuật. Nếu tài liệu đặc tả chưa đề cập đến, hãy đặt câu hỏi, tìm cách xác nhận với các bên liên quan.
- Liệt kê các test case bạn dự định viết trước khi đi vào viết chi tiết Xây dựng danh sách các đầu mục cần viết cũng như mức độ ưu tiên của chúng. Điều này giúp bạn có được một cái nhìn tổng thể về những thứ bạn sẽ làm, tránh thiếu sót cũng như bị trùng lặp đồng thời cũng giúp bạn tập trung vào những cái bạn cần hoặc muốn kiểm tra. Liệt kê ngay cả khi danh sách này chưa phải là cuối cùng, bởi vì sau sau đó bạn vẫn có thể tái sử dụng bằng cách chia nhỏ hoặc gộp chúng lại.
- Hướng tới 100% độ bao phủ kiểm thử Độ bao phủ kiểm thử đạt 100% nghĩa là bạn đã tạo đủ test case cho mọi yêu cầu của chương trình của mình. Không hơn không kém. Hãy dành một chút thời gian để lập kế hoạch cho các trường hợp thử nghiệm của bạn, đảm bảo bao gồm mọi thành phần và chức năng được chỉ định trong tài liệu SRS. Ma trận truy xuất nguồn gốc sẽ giúp bạn xác minh được chứng năng hay điều kiện nào chưa được nhắc tới trong kiểm thử. Bởi nó yêu cầu ánh xạ giữa các trường hợp kiểm thử và yêu cầu sẽ theo dõi bất kỳ chức năng hoặc điều kiện nào chưa được kiểm tra.
- Phân loại test case dựa vào kịch bản nghiệp vụ và chức năng Điều này cho phép bạn nhìn hệ thống từ các góc độ khác nhau. Logic đằng sau quá trình này là để biết khi nào nên thực hiện phần test case nào. Sự phân loại này cũng giúp việc lựa chọn để chạy lại, hoặc kế thừa test case cũ của bạn trở nên dễ dàng và khả thi hơn.
- Linh hoạt sử dụng các kỹ thuật kiểm thử Không thể kiểm tra mọi điều kiện có thể trong sản phẩm của bạn. Các kỹ thuật kiểm thử giúp bạn chọn một số trường hợp điển hình để tiết kiệm thời gian nhưng vẫn đảm bảo tính khả thi về khả năng tìm ra lỗi tối đa. Các kỹ thuật kiểm thử bao gồm:
- Phân tích giá trị biên (Boundary value analysis – BVA): Đây là kỹ thuật xác định việc kiểm tra các giá trị biên cho một phạm vi giá trị xác định.
- Phân vùng tương đương (Equivalence Partitioning – EP): 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.
- Kỹ thuật chuyển đổi trạng thái (State transition): Phương pháp này được sử dụng khi hành vi của phần mềm thay đổi từ trạng thái này sang trạng thái khác sau một hành động cụ thể.
- Kỹ thuật đoán lỗi (Error Guessing): Đây là đoán/dự đoán lỗi có thể phát sinh trong khi thực hiện kiểm tra thủ công. Đây không phải là một phương pháp chính thức và tận dụng trải nghiệm của người thử nghiệm với ứng dụng.
- Chạy thử test case Hãy đảm bảo tính khả thi của bộ test case của bạn trong khi tiến hành thử nghiệm bằng cách chạy thử chúng một hoặc hai lần trong khi bạn hoàn thiện chúng.
- Review nội bộ Sau khi tạo test case, hãy để đồng nghiệp của bạn review chúng. Đồng nghiệp của bạn có thể phát hiện ra các lỗi trong thiết kế trường hợp thử nghiệm của bạn mà bạn có thể dễ dàng bỏ qua.
Kết luận
Viết kịch bản kiểm thử hiệu quả để kiểm soát được tất cả lỗi có thể xảy ra là không phải là một công việc dễ dàng. Quá trình làm việc bạn sẽ tự đúc rút được thêm những kinh nghiệm cho bản thân. Hy vọng rằng các mẹo trên đây của mình có thể giúp ích thêm được gì đó cho bạn.
Hẹn gặp lại các bạn ở những bài viết tiếp theo!
Happy Testing!