Các kinh nghiệm đơn giản để viết testcase hiệu quả.

Test case là rất quan trọng trong bất kì dự án nào vì đây là bước đầu tiên trong quá trình test và nếu có gì đó sai sót ở bước này sẽ kéo theo hệ quả ở các giai đoạn tiếp theo trong vòng đời test.

Biết cách viết test case tốt là cực kì quan trọng khi bạn làm test và hãy tin tôi, không mất nhiều công sức và thời gian của bạn để viết kịch bản test hiệu quả. Bạn chỉ cần theo các hướng dẫn cơ bản trong khi viết test case hoặc có thể gọi đó là “luyện tập viết test case hiệu quả nhất”.

Trong bài này, tôi sẽ nói về một vài kinh nghiệm đơn giản hiệu quả mà bạn có thể sử dụng cho viết test case.

Viết test case là một hoạt động có sự ảnh hưởng lớn đến giai đoạn test và đóng vai trò quan trọng trong quá trình thực hiện test. Nên viết testcase hiệu quả cũng như có thể sử dụng lại là rất quan trọng, testcase tốt tiết kiệm được nhiều thời gian trong các giai đoạn sau của test nếu như bạn làm đúng ở bước đầu tiên.

Viết test case hiệu quả là một kĩ năng và bạn chỉ có thể có được qua thực hành và hiểu sâu về ứng dụng, cái mà sẽ được viết ở test case.

Kết hợp một vài kinh nghiệm đơn giản mình đưa ra dưới đây sẽ giúp bạn làm chủ được kĩ năng viết test case Trước khi nói đến các kinh nghiệm, chúng ta cùng tìm hiểu ngắn gọn “Test case là gì?”

Một test case đơn giản là một tập hợp các hành động cần được thực hiện để kiểm tra các chức năng riêng biệt trong ứng dụng của bạn khi test. Ở đây là một danh sách 13 kinh nghiệm/ hướng dẫn bạn có thể dùng trong khi thiết kế test để viết test case hiệu quả, dễ hiểu và dễ sử dụng.

Các kinh nghiệm đơn giản để viết testcase hiệu quả

#1. Các quy ước đặt tên

Mặc dù đây là kinh nghiệm đơn giản nhất trong danh sách này (tôi nghĩ vậy), nhưng phần lớn chúng ta không thực hiện nó hiệu quả - Quy ước đặt tên cho test case.

Sẽ luôn là một cách thực hành tốt khi đặt tên test case của bạn theo một cách dễ hiểu cho mọi người khi sử dụng đến test case đó sau này (bao gồm cả bạn).

Kinh nghiệm nhanh: Như là cách tốt nhất, tên test case nên thể hiện được tên của module, hoặc chức năng mà bạn sẽ test trong test case đó

Hãy xem một ví dụ nhé!

Có một dự án là “Online” có chức năng “Login”.

Bây giờ mình muốn viết một test case để kiểm tra xem người dùng có thể đăng nhập vào trang web sử dụng email và mật khẩu không.

Theo đó, thay vì đặt tên test case là TC_01, mình có thể sử dụng quy ước đặt tên cho testcase của mình như bên dưới để nó có một gợi ý ngắn gọn những gì mà test case đó sẽ test.

• TC_01_Online_Login_Success or,
• TC_01_Online_Valid_Case và tương tự thế

Chỉ cần cố gắng làm cho nó có liên quan đến dự án, module, chức năng dưới test case đó.

Đây là một ví dụ đơn giản và bạn có thể đặt tên test case theo bất cứ cách nào phù hợp với bạn nhất.

Cố gắng làm cho chúng dễ hiểu nhất qua việc nhìn test case ID hoặc tên test case.

Hi vọng rằng đây là cách đơn giản. Chúng ta cùng đi tiếp kinh nghiệm tiếp theo nhé!

#2. Miêu tả test case

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ì”?

Những gì cần được kiểm tra, nó cần được kiểm tra trong môi trường test nào, dữ liệu test nào được sử dụng – tất cả thông tin này sẽ nằm ở phần miêu tả test case.

Kinh nghiệm nhanh:

Đưa ra nhiều thông tin nhất có thể trong phần miêu tả test case

Chủ yếu bạn sẽ tìm ra các thông tin như bên dưới trong một miêu tả test case được viết tốt:

• Test được thực hiện/ hành vi được kiểm tra
• Điều kiện cần có trước và các giả định (nếu có sự phụ thuộc)
• Dữ liệu test được sử dụng
• Chi tiết môi trường test (nếu có thể dùng được)
• Bất kì công cụ test nào được sử dụng cho test.

Giả định và điều kiện cần, và dữ liệu test sẽ được đề cập ở bên dưới.

#3. Giả định và điều kiện cần có trước

Khi viết test case, bạn nên kiểm tra tất cả các giả định có thể dùng cho một test case, theo bất kì điều kiện có trước nào đó mà bạn sẽ gặp trước khi test được thực hiện.

Dưới đây là chi tiết bạn nên biết trong phần này:

• Bất kì sự phụ thuộc nào đó vào dữ liệu người dùng (ví dụ: người dùng nên đăng nhập vào hệ thống, trang nào người dùng nên bắt đầu…)
• Sự phụ vào môi trường test
• Các cài đặt đặc biệt cần thực hiện trước khi test
• Phụ thuộc vào các test case khác – test case cần thực hiện trước hoặc sau một vài test case khác.

Kinh nghiệm nhanh:

Chắc chắn rằng bạn sẽ thêm các thông tin nhiều nhất có thể cho bất kì điều kiện nào gặp phải trước khi chạy test case Danh sách này không phải là toàn bộ và các danh mục mình liệt kê chỉ là một ví dụ của những gì bạn có thể thêm vào trong phần này

#4. Dữ liệu đầu vào của test

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 – chuẩn bị dữ liệu test tốn phần lớn thời gian trong quy trình test. Thỉnh thoảng cần bạn tạo lại dữ liệu test vì tạo mới dữ liệu có thể tốn ít thời gian hơn so với việc xác định nó.

Để dễ dàng hơn khi là một tester, bất cứ nơi nào có thể, bạn có thể đưa dữ liệu test được sử dụng cho test case vào trong miêu tả test case hoặc với đặc tả bước của test case. Điều này tiết kiệm rất nhiều thời gian trong thời gian dài vì bạn sẽ không phải tìm dữ liệu test mới mỗi khi bạn cần thực hiện test.

Một vài lời gợi ý:

• Trong nhiều trường hợp bạn biết ở đâu dữ liệu test các thể được sử dụng lại nhiều lần, bạn có thể đề cập dữ liệu test chính xác được sử dụng cho test
• Nếu test chỉ liên quan đến một vài giá trị được kiểm tra, bạn có thể chọn để chỉ rõ khoảng giá trị hoặc mô tả giá trị nào được test cho trường nào. Bạn cũng có thể thực hiện việc này cho các trường hợp phủ định.
• Test với mỗi giá trị là không thực tế nên bạn có thể chọn một vài giá trị từ phân vùng cho giá trị bao phủ tốt cho test case của bạn.
• Bạn có thể quyết định chỉ ra kiểu dữ liệu test được yêu cầu và không phải là dữ liệu test thật. Cách này áp dụng cho các dự án mà dữ liệu test thay đổi khi nhiều nhóm sử dụng nó và có thể không có trạng thái giống nhau trong lần sử dụng tiếp theo – chỉ ra kiểu hay trạng thái của dữ liệu người dùng được sử dụng hỗ trợ nhiều cho người chạy test case sau đó.

#5. Bảo đảm tất cả các điểm cần kiểm tra trong các bước thiết kế test

Một phần quan trọng khác của test case viết tốt là các bước kiểm tra testcase được xác định có thể đảm bảo được tất cả các điểm chức năng khi test.

Kinh nghiệm nhanh:

Các bước thiết kế test không nên chỉ đảm bảo luồng chức năng mà còn cả mỗi điểm kiểm tra cần phải test.

Bằng việc so sánh các bước test case của bạn với tài liệu (yêu cầu dự án, use case, câu chuyện người dùng hoặc bản đồ tiến trình) được đưa ra cho dự án của bạn, bạn có thể chắc chắn rằng test case có thể đảm bảo được các điểm cần kiểm tra.

Kinh nghiệm thêm:

Nếu bạn làm việc trong mô hình test nhanh, bạn có thể lựa chọn không đảm bảo mỗi test đơn lẻ như là một test case. Thay vì thế bạn có thể đảm bảo một vài bước kiểm tra trong quá trình test khám phá.

#6 Đính kèm các tài liệu liên quan

Như đã đề cập ở phần trên, bất kì khi nào có thể bạn nên đính kèm tài liệu liên quan vào test case của bạn.

Nếu sự thay đổi mà bạn đang test không quá lớn, bạn có thể cân nhắc đề cập trong từng bước test.

Nhưng nếu nó bao gồm một phần đặc biệt trên màn hình, rất khó để để cập trong từng bước test, hãy đính kèm tài liệu đặc tả hoặc thiết kế màn hình tới các bước cụ thể đó.

#7. Kết quả mong đợi

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 như là đầu ra của bước kiểm tra đó.

Nên trong khi viết test case, chỉ ra cụ thể trang nào, màn hình nào bạn mong đợi xuất hiện khi test và bất kì thay đổi nào bạn mong đợi như là đầu ra được tạo ở phần back-end của hệ thống hoặc cơ sở dữ liệu (ví dụ: một sự tạo mới nên được thêm vào bảng dữ liệu).

Bạn có thể đính kèm màn hình hoặc tài liệu đặc tả tới các bước liên quan chỉ ra hệ thống nên làm việc như đã được đưa ra trong tài liệu để làm mọi thứ đơn giản hơn.

#8. Chia các test case chức năng đặc biệt trong một nhóm

Để viết test case hiệu quả, bạn nên cân nhắc việc chia test case của bạn thành các nhóm nhỏ theo nhóm các trình tự đặc biệt như cách xử lý của trình duyệt, kiểm tra cookie, test tính khả dụng, web service, kiểm tra điều kiện lỗi.

Nếu bạn cố gắng để viết testcase hiệu quả, bạn nên viết những test case chức năng riêng.

Ví dụ: Test case để kiểm tra điều kiện lỗi nên được viết riêng với test case chức năng và nên có các bước kiểm tra thông báo lỗi.

Kinh nghiệm nhanh:

Nếu trong khi viết các kịch bản vào cùng một nhóm, các chức năng đặc thù có nhiều sự kết hợp điều kiện đầu vào, bạn có thể chia thành các nhóm nhỏ hơn.

Ví dụ: Nếu bạn cần kiểm tra xem chức năng đăng nhập cho ứng dụng nào đó với dữ liệu đầu vào không đúng, bạn có thể chia việc test chức năng đăng nhập sai thành các nhóm sau:

o Kiểm tra email-id không đúng

o Kiểm tra mật khẩu không đúng

o Kiểm tra trường email-id rỗng…

#9. Dễ đọc và dễ hiểu

Bất kì dự án nào bạn làm việc, khi thiết kế test case, bạn nên luôn suy nghĩ rằng test case sẽ không được thực hiện bởi người thiết kế. Vì vậy, test case nên dễ hiểu và dễ đọc, chi tiết.

Bộ test case mà chỉ dễ hiểu với người thiết kế nó thì ở đâu cũng có. Tưởng tượng trường hợp mà người viết tất cả test case nghỉ vì lý do nào đó và bạn có một nhóm mới làm việc thực hiện test case đó, toàn bộ công sức dùng cho giai đoạn thiết kế sẽ đổ xuống sông.

Nếu bạn là người rời tổ chức, bạn không thể tham gia được nhưng nếu bạn vẫn ở công ty và chỉ chuyển qua nhóm khác, bạn có thể phải dành hết thời gian để giải thích những gì bạn viết.

Nên tốt hơn hãy làm nó đúng ngay lần đầu tiên.

Bạn nên tập trung vào viết test case:

• Đơn giản và dễ hiểu với mọi người (bao gồm bạn)
• Rõ ràng, chi tiết, bạn không phải đang viết bài luận (nếu bạn thấy test case có nhiều bước thì nên tách thành test case mới).
• Đảm bảo đủ các trường hợp.

#10. Kiểm tra lại

Test case đóng một vai trò quan trọng trong vòng đời test, chắc chắc rằng chúng đúng và hợp với chuẩn, trở nên rất cần thiết – đó là khi quá trình kiểm tra lại cần thực hiện.

Kinh nghiệm nhanh:

Kiểm tra lại test case có thể thực hiện giữa những người test ngang hàng, người phân tích nghiệp vụ chức năng, lập trình viên, chủ sản phẩm hoặc các bên liên quan.

Dù thế nào bạn cần chú ý một vài điều kiện cần có trước khi bắt đầu kiểm tra lại vì quá trình kiểm tra lại cũng có thể gây hại.

#11. Có thể sử dụng lại

Bạn nên viết test case với suy nghĩ rằng chúng có thể được sử dụng lại trong tương lai cho các dự án khác, nhóm khác.

Trước khi viết test case cho dự án của bạn, luôn cố gắng và kiểm tra xem có test case nào được viết rồi. Điều này thực sự tiết kiệm được nhiều thời gian.

Nếu bạn dành một chút thời gian với nhóm khác để tìm ra test case đã có rồi, bạn thật may mắn – bạn sẽ không phải lặp lại bất kì test case nào vì thế sẽ tránh được việc dư thừa trong quản lý test của bạn.

Cũng như thế, nếu bạn có test case sẵn có được viết trước đó ở cùng module, bạn nên chỉnh sửa chúng thay vì viết mới để bạn luôn có được test case mới đã sửa.

Điều này có thể không dùng được nếu như dự án của bạn là dự án mới, dù thế nào, bạn có thể cố gắng để viết test case theo cách chúng có thể được sử dụng cho dự án nào đó trong tương lai.

Cũng vậy, nếu bạn cần một test case cụ thể để thực hiện test case khác, bạn có thể đơn giản gọi đến test case đã tồn tại trong phần điều kiện trước hoặc ở bước thiết kế test.

#12. Bảo trì và thay đổi

Điều này đã được nói nhiều ở phần trên (#11).

Là cực kì quan trọng để chắc chắn rằng test case luôn được cập nhật theo những thay đổi mới trong ứng dụng mà chúng sử dụng.

Kinh nghiệm nhanh:

Luôn chú ý cập nhật test case đã tồn tại trước đó trước khi bạn bắt đầu viết test case mới.

Tóm lại quan điểm của mình về khả năng sử dụng lại, trong trường hợp có bất kì sự thay đổi nào tới chức năng đã tồn tại, bạn phải cập nhật test case đã tồn tại thay vì viết mới để tránh việc dư thừa. Điều này cũng chắc chắn rằng bạn luôn có test case đã cập nhật theo ứng dụng của bạn.

#13. Điều kiện ra

Điều kiện ra cơ bản đặc tả các kết quả bạn cần kiểm tra sau khi thực hiện test.

Ngoài ra điều kiện ra cũng được sử dụng để đưa ra hướng dẫn phục hồi lại hệ thống với trạng thái gốc cho nó không ảnh hưởng đến việc test sau này.

Ví dụ: Điều này khá hiệu quả nếu bạn đề cập những thay đổi được tạo ra tới tập dữ liệu test cho nó, được sử dụng cho testcase sau này cho cùng chức năng.

Kết luận:

Một nhiệm vụ lớn để viết test case hiệu quả với tất các các chi tiết được yêu cầu trong đó, miễn là bạn chắc chắn suy nghĩ về phía người dùng, biết ứng dụng cuối, và theo các cách thực hành viết test case mà mình nói ở trên, bạn sẽ làm tốt. Trong danh sách này, mình đã chỉ ra hết các kinh nghiệm hiệu quả và đơn giản mà bạn có thể ứng dụng khi bạn thiết kế test case. Mình thực sự hi vọng điều đó có thể giúp ích cho bạn Bây giờ bạn đã biết cách viết test case vậy hãy quay lại thiết kế test case hiệu quả nhất và ứng dụng trong quá trình test.

Tài liệu được dịch từ nguồn: http://quicksoftwaretesting.com/test-case-writing-tips