Mọi người tranh cãi về test case nhiều lắm, từ khắp muôn nơi, mình không đủ trình độ và cũng không muốn tham gia vào. Vậy nên bạn có ý kiến về test case mà khác mình thì ý kiến của bạn không hề sai và đừng mang ý kiến đó ra để mà phản biện mình nha, mình không có nhu cầu trao đổi xem ai đúng ai sai.

Các vấn đề của test case gồm những thứ sau:

• Nó để làm gì? có quan trọng không? có nhất thiết phải có không?
• Viết test case có gọi là làm test?
• Dùng phần mềm nào để viết test case?
• Cách viết test case như thế nào? cần có những thông tin nào?
• Viết test case nên viết dạng checklist hay viết kiểu details?
• Quản lý test case manual và automation như thế nào?

Và sau đây là các suy nghĩ của cá nhân mình:

Test case để làm gì? có quan trọng không? có nhất thiết phải có không?

• Test case là sự thể hiện suy nghĩ của bản thân về 1 tính năng của sản phẩm. Đầu mình không thể nhớ được hết các chi tiết, nên tốt nhất là thể hiện nó ở trên giấy.
• Test case quan trọng nếu như bạn làm các dự án dài, tính thời gian từ hàng năm trở lên. Nó là 1 dạng document sẽ cứu nguy rất nhiều lần cho bạn, bạn đừng xem nhẹ nó. Mình có rất nhiều lần tự tin với trí nhớ, nghĩ rằng tính năng này mình làm từ trong ra ngoài, không thể quên được. Sau 1 năm thì cái đọng lại chỉ là tên của tính năng đó. =))))
• Ngoài ra, bên mình liên tục phải thực hiện các đợt Audit (kiểm soát chất lượng) với các khách hàng. Họ yêu cầu rất kỹ về tài liệu, thể hiện cách mình thực hiện test, các evidence chứng minh mình đã test theo các requirment. Nói chung là bắt buộc phải có test case.
• Dự án outsource ngắn thì bạn cũng chả cần maintain gì, deliver là xong + vấn đề cắt cost thì mình thấy bạn có thể viết dạng ngắn gọn là được.

Viết test case có gọi là làm test?

• Nhiều người nói test case không phải là test. Mình thì “yeah, whatever”. Mình chả quan tâm đến mấy thứ định nghĩa đó. Mình chỉ biết rằng làm test là làm rất nhiều các hoạt động khác nhau, và test case là thứ giúp mình làm có hệ thống hơn.

Dùng phần mềm nào để viết test case?

• Câu trả lời là không quan trọng, miễn là phù hợp với dự án và team tester là được. Có thể là dạng excel (nếu có license), dạng google sheet (nếu công ty cho phép), confluence page (nếu sử dụng), hoặc có kiểu phần mềm khác.
• Vấn đề là bạn sử dụng tool mà công ty cho phép. Công ty mình cho dùng cả 3 dạng trên nên mình chọn confluence page, để tất cả docs của dự án được tập trung vào 1 chỗ.

Cách viết test case như thế nào? cần có những thông tin nào?

• Ôi ngày xưa, mình thấy có bạn chỉ trích là mọi người ếch biết viết test case, test case đúng là phải viết đúng chuẩn IEEE abcxyz gì đó. Mình chưa bao giờ tìm hiểu cái chuẩn đó luôn. Vì mình viết khá linh tinh, chả có chuẩn gì cả. Phương châm của mình là đủ thông tin cần thiết, thế thôi.
• Thế nào là đủ thông tin cần thiết?
  • ID: để sau đếm xem có bn cases. Vì trong confluence page không có chức năng count giống như excel nên phải đếm tay, tốt nhất điền ID thì đếm nhanh hơn.
  • Case name: 1 câu ngắn gọn về thứ mình định check. Ví dụ: Login with external authentication.
  • Steps + Data test: chức năng mới hoàn toàn mình sẽ viết cẩn thận. Chức năng cũ mình viết đại khái, hoặc không viết.
  • Expected result: viết dạng expect chung chung hoặc chi tiết tùy case.
  • Actual result: Chủ yếu để add evidence, ảnh hoặc video.
  • Pass/Fail: điền kết quả test (Pass để màu green, Fail để màu red).
  • Note: điền [ngày, giờ, tên người thực hiện test] và điền link đến jira ticket nếu case fail.

Form đầy đủ của mình thế này, tuy nhiên có những lúc mình cần phải check bug ở trên jira, mình có thể list luôn test case trong comment, chỉ với 4 cột:

• Case name
• Expected result
• Actual result
• Pass/Fail

Viết test case nên viết dạng checklist hay viết kiểu details?

• Tính năng mới thì mình viết kiểu details. Mình có thời gian nghiền ngẫm requirement, technical design nên mình có thể viết được bản chi tiết. Và chính cái bản chi tiết này sẽ là 1 dạng extension của requirement kia, nó thể hiện cách user sử dụng tính năng đấy.
• Test bug mình viết kiểu checklist thôi, vì cả dev và test đều hiểu tính năng đó, không cần viết dài dòng.

Quản lý test case manual và automation như thế nào?

• Mình có file riêng, không gộp 2 thằng đó vì người làm thường là khác nhau.
• Tuy nhiên nếu project chỉ có mình bạn thì bạn dùng 1 file cho cả 2 thằng cũng được, chỉ cần thêm 1 cột đánh dấu xem case này có automation không là ok.

Chốt lại:

Viết test case thế nào là tùy ở từng team, có lúc cần viết đầy đủ, có khi chỉ cần ghi đơn giản, miễn sao cả người viết và người đọc đều hiểu là được… Hết.