Làm thế nào để bạn giải thích cho một tester mới vào nghề về cách viết, thực hiện và báo cáo các test case? Đó là một công việc khó khăn.
Để bắt đầu, sẽ có một vài câu để làm rõ về các Test Case và Test Scenario và chúng khác nhau như thế nào và theo thứ tự nào. Bắt đầu từ cuối cùng, chúng ta hãy trả lời câu hỏi "thứ tự nào?"
Test Case được thiết kế để có thể che phủ được sự ảnh hưởng của các mô-đun với nhau ở mức độ cao nhất. Muốn biết được vấn đề đó, bận cần xác định rõ được tính năng của từng mô-đun riêng biệt, cách thức nó hoạt động tương tác với mô-đun khác như thế nào? Ví dụ: Khi test chức năng giỏ hàng của 1 website thương mại điện tử để kiểm tra bạn cũng cần phải xem xét quản lý hàng tồn kho và xác nhận nếu cùng số lượng của sản phẩm mua được khấu trừ từ các cửa hàng. Tương tự như vậy, trong khi thử nghiệm trở lại, chúng ta cần phải kiểm tra ảnh hưởng của nó trên một phần tài chính của ứng dụng cùng với cửa hàng tồn kho.
Test Case là sự mô tả, công thức cho tester, liên hệ giữa việc làm thế nào để test chức năng và làm thế nào để kiểm tra hệ thống hoạt động đúng hay không. Nhìn vào cấu trúc, chúng ta có thể định nghĩa được các loại quan hệ: Test Scenario -> Test Case -> Test Step. Có thể viết như sau:
* Test Step – quy định cụ thể một hành động để thực hiện, và đáp ứng mong đợi của ứng dụng test. Ví dụ:
Hành động: Nhập password vào ô password,
Kết quả mong đợi: password của bạn sẽ hiển thị là *** hoặc ẩn.
* Test Case – là một danh sách các test step. Cũng định nghĩa trạng thái môi trường và có thể liên kiết đến các bug, spec (đặc tả yêu cầu) liên quan,…
* Test Scenario – thường có được trực tiếp từ các đặc tả yêu cầu của khách hàng hoặc user-story. Các công cụ quản lý thường bỏ qua Test Scenario để kết nối với một danh sách các đặc tả yêu cầu. Scenario chứa một danh sách các test case và đôi khi là một chuỗi các Test Case liên kết (thí dụ Test Scenario "Kiểm thử các chức năng gửi email" là kịch bản đặc thù không phụ thuộc vào bất cứ module nào, vì Email được xem là dòng chảy thông tin vô cùng quan trọng đối với bất cứ hệ thống nào).
Như các bạn có thể thấy, sự khác nhau giữa Test Scenario và Test Case là đáng kể, phân biệt hai khái niệm này đôi khi rất mơ hồ.Làm thế nào để đảm bảo chất lượng cho Test Case đã tạo được? Làm thế nào để quản lý vòng đời (life cycle) của nó? Làm thế nào để hoàn thành sớm và khi nào thì Dev cần nó?
1. Template – cần một hoặc nhiều mẫu hoàn thành để viết test case. Chúng ta có thể tạo test case trong MS Word, MS excel hoặc mua template trên mạng, hoặc sử dụng các công cụ phần mềm để viết Test Case chuyên nghiệp, như Jira, RedMine.... Tại TIGO, QA team thường sử dung JIRA và Redmine một cách linh hoạt để đáp ứng yêu cầu về chất lượng.
2. Descriptive và specific – Cần miêu tả tiêu đề ngắn gọn, xúc tích. Nên định nghĩa các mục đích và phạm vi của các hoạt động test một cách rõ ràng. Chúng ta đang viết cho tất cả các tester, chứ không chỉ viết riêng cho chính mình, sử dụng ngôn ngữ đơn giản mà các bên đều hiểu được, thậm chí khách hàng cũng có thể hiểu được. Hạn chế mô tả quá phức tạp sẽ dần đến hiểu nhầm, tốn thời gian truyền tải thông tin qua lai. Nên dùng theo kiểu câu mệnh lệnh, ví dụ, nên ghi là “Nhập abc và nhấn enter” chứ không nên ghi “Tôi đang nhập abc, và sau đó nhấn Enter.”
3. Reusable – Nhiều Test Case giống nhau có thể được sử dụng trong nhiều scenario. Hãy nhớ rằng, khi tạo một hạng mục mới, chúng ta phải tưởng tượng ra một loại use case khác với loại mà chúng ta đang làm. Các bước test cũng có thể được tái sử dụng, vì vậy chúng ta cũng nên chú ý đến tính kế thừa để tận dụng lợi thế kinh nghiệm (experience curve).
4. Atomic – Ác mộng lớn nhất của Tester vật lộn với test thủ công (bằng tay) là Test Case, vì nó quá dài và tồn tại nhiều bước kiểm tra phụ thuộc nhau. Tester phải là người có đam mê và hứng thú với nghề Test, tỉ mỉ với từng Test Case, nếu không sẽ rất dễ "chóng chán" với các công việc kiểm tra đầy ắp số liệu giống như sổ sách của kế toán vậy. Tester có thể phải thực hiện 100 test case và thực hiện trong một ngày, nhưng cũng có thể chỉ có 10 test case và thực hiện trong 1 tuần. Nếu bạn tạo Test Case và kiểm thử định lượng theo các quy trình test chuẩn, bạn có thể nhận được sự tương tác thân thiện từ đồng nghiệp thay vì kiểm thử định tính (là dạng kiểm tra theo quan sát hơn là theo số liệu thực tế).
5. Positive and negative (test trường hợp đúng - happy case và test trường hợp sai - unhappy case) – điều quan trọng là thứ tự của Test Case. Cái nào cần ưu tiên trước, cái nào có trì hoãn? Bạn sẽ làm gì khi project manager (PM) yêu cầu phải tạo ra một số lượng lớn Test Case vào cái ngày mà "sếp'' đã thỏa thận với khách hàng về tiến độ ? Thường các PM chỉ muốn khởi đầu tốt đẹp với các postive Test Case, chạy đúng và đủ, và dữ liệu test cũng rất "đẹp". Người quản lý sẽ đưa lên trước các positive Test Case chỉ để chứng minh với khách hàng là chức năng đó có thực sự tồn tại, phù hợp với đặc tả yêu cầu, sẵn sàng để bàn giao. Là tester, bạn sẽ gửi cho PM các "happy Test Case " càng sớm càng tốt, để bạn có đủ thời gian cho các "unhappy Test Case" còn lại. Cân bằng giữa các happy Test Case và unhappy Test Case sẽ giúp dự án "trôi" tốt hơn.
6. Refactor – nếu bạn đã sẵn sàng kết thúc công việc thì chúng ta phải nhớ rằng các ứng dụng thì thay đổi và các thay đổi trong test case sẽ làm theo trình tự này (theo 8 bước này). Chúng ta nên tạo version, bắt chước cách thay đổi version number (1.0 -> 1.1 ->…). Quản lý test (ví dụ QC leader) sẽ ước lượng chúng ta sẽ làm có bao nhiêu version và chúng ta nên quan tâm về tập hợp các Test Case hiện tại của chúng ta.
7. Test data (dữ liệu dùng để test) – đây là những điều quan trọng song song với việc thực hiện test đúng thì chúng ta phải cung cấp một số data, thường thì (nếu nó quá phức tạp để mô tả trong tài liệu này) được đính kèm bằng một file khác. Chúng ta cần phải phân tích cho dù nó dễ cung cấp test data hay dễ thêm vào các bước test thích hợp.
8. Setup and tear down (sắp xếp và tỉa tót lại Test Case) – nếu Test Case yêu cầu phải có cấu hình, phải gọi một chức năng nào đó cụ thể, chúng ta cần xem xét quay lui về bước đầu tiên (zero step). Giống như Unit Test (whitebox) hoặc test tự động, các Test Case cũng cần dọn dẹp trong bước cuối cùng.
Câu hỏi thường gặp
Dưới đây là một số câu hỏi thường gặp liên quan đến vấn đề thiết kế test case.
Test case gồm những gì?
Test case thường bao gồm những thành phần chính sau:
1. Test case ID: Để dễ dàng xác định và phân biệt test case với nhau
2. Test summary: Để mô tả tóm tắt trường hợp cần kiểm thử. Còn gọi là test objective.
3. Test precondition: Điều kiện tiên quyết, điều kiện cần để test case này chạy được
4. Test steps: Các bước thực hiện test case
5. Expected result: Kết quả mong đợi, điều bạn muốn chương trình thực hiện
Làm sao để viết test case bao phủ tốt?
Test case bao phủ tốt là phải bao gồm các loại test case cho UI (nếu có – vì giả sử bạn đang test API thì làm gì có UI mà bắt buộc phải có test case cho UI), test case cho các trường hợp happy case (positive case), và negative case (unhappy case). Và quan trọng hơn hết, tập test case của bạn phải bao phủ mọi nghiệp vụ, chức năng cần thiết theo mô tả yêu cầu.
Dự án nào cần viết test case?
Dù bạn đang tham gia dự án gia công phần mềm (outsourcing) hay công ty phát triển phần mềm (hay gọi là công ty product) thì việc viết test case và mức độ chi tiết của test case sẽ khác nhau. Tuy nhiên, chí ít cũng nên viết checklist để bảo đảm các chức năng chính sẽ/đã được kiểm thử, và phần mềm đã bao phủ (cover) hết các yêu cầu đã mô tả.
Có cần phải viết test case không?
Không phải dự án nào cũng có đủ thời gian để viết test case. Thông thường thì trong khi Lập trình viên (dev) đang lập trình (phát triển) thì tester (QC) sẽ có thời gian để viết test case.
Nhưng cũng có nhiều trường hợp, dự án không hoàn toàn viết mới mà sẽ cải tiến, nâng cấp hệ thống cũ, thì thời gian lập trình thường sẽ hoàn thành trước thời gian viết test case. Và nhiều lúc cần gấp thì vẫn có thể test (kiểm thử) trước khi viết test case.
Không viết test case có được không?
Việc có viết test case hay không sẽ phụ thuộc vào từng trường hợp cụ thể. Phụ thuộc vào ngữ cảnh, tình hình thực tế của dự án mà tester cân nhắc nên test trước rồi viết test case hay là viết test case trước rồi test. Ngoài ra, mọi việc còn phụ thuộc vào quyết định của Khách hàng, QC/Tester Leader và Project Leader/Manager nữa.
