Business Analyst cần học gì: thiết kế test case

Tại sao thiết kế test case lại là điều Business Analyst cần học

Khi là 1 BA phần mềm (Software Business Analyst) sẽ có không ít lần bạn phải thực hiện kiểm thử (test) sản phẩm phần mềm như một người dùng cuối bất chấp trong đội dự án có kiểm thử viên (tester) hay không, điều lo lắng là làm sao có thể kiểm thử phủ đủ kín các trường hợp mà không qua tốn công sức? Để thực hiện được việc này bạn sẽ phải nắm được nguyên tắc thiết kế trường hợp kiểm thử (design test case) của giới tester.

Có những công ty phần mềm không có vị trí tester. Họ chuyển giao phần Unit Test thành các Automation Test và chuyển giao nhiệm vụ test các reuirement này sang BA

Mục tiêu bài viết nhằm hướng dẫn người đọc là BA phần mềm hiểu về cách thiết kế test case nhằm tối ưu công sức khi test phần mềm mà vẫn đảm bảo phủ kín các trường hợp cần test, giúp BA có thể chủ động đảm bảo mục tiêu của dự án được hoàn thành ngay cả khi thiếu nguồn lực tester trong dự án.

Cấu trúc của 1 test case

Một test case gồm 3 phần:

• Đầu vào (Inputs): Đây là dữ liệu đầu vào được nhập để test, bao gồm các điều kiện môi trường.
• Đầu ra (Output): Kết quả tạo ra để xác định test pass/không pass
• Thứ tự thực hiện (Order of executions) thứ tự các bước để thực hiện test với inputs và tạo ra outputs.

Khi thực hiện test theo “Thứ tự thực hiện” với dữ liệu đúng như “Đầu vào” mà tạo ra kết quả đúng như mô tả ở “Đầu ra” thì test case này pass, ngược lại là failed.

Chuỗi test case

Chuỗi test case là một loạt các test case được thực hiện theo dạng nối tiếp hoặc độc lập với nhau, một chuỗi test case là pass nếu tất cả các outputs đều cùng đúng, ngược lại là failed.

Có 2 loại chuỗi test case:

• Nối tiếp (Cascading) chuỗi các test case nối tiếp nhau liên tục, đầu ra của test case này là đầu vào của test case khác. Ví dụ 3 test case sau: 1. Mở trình duyệt và truy cập trang chủ → 2. Đăng nhập vào site → 3. Đổi tên user.
• Độc lập (Independent): các test case độc lập không liên quan.

Các phương pháp test

Có 3 phương pháp chính, theo thứ tự từ trên xuống dưới càng đòi hỏi kiến thức về lập trình sâu hơn.

• Hộp đen (Black box testing): không cần kiến thức về bên trong hệ thống, chỉ cần có kiến thức cơ bản về yêu cầu phần mềm nên rất phù hợp với BA.
• Hộp xám (Gray box testing): cần phải nhìn vào các đoạn code bên trong hệ thống nên phù hợp với developer hơn là BA.
• Hộp trắng (White box testing): test dựa trên code và hệ thống, nên phương pháp này phù hợp với developer với kiểm thử đơn vị.

Như vậy nếu là 1 BA muốn test phần mềm sẽ cần tìm hiểu sâu hơn các phương pháp test dạng hộp đen.

Kiểm thử hộp đen là gì (Black box testing)

Thực hiện kiểm thử hộp đen là dựa trên các yêu cầu đã được nắm rõ và cần áp dụng phương pháp này ở tất cả các cấp, đặc biệt BA cần test sâu ở giai đoạn nghiệm thu (User Acceptance Test).

Phương pháp này có nhược điểm là không bao giờ có thể chắc chắn về số lượng test case cần thiết để kiểm tra tất cả các tình huống có thể vì có thể số lượng quá lớn; tuy nhiên quá ít test case sẽ không phủ được hết tình huống, quá thừa test case thì lãng phí công sức kiểm thử.

Bù lại phương pháp này có ưu điểm về hiệu quả hơn nhiều so với việc tạo ra test case ngẫu nhiên. Ngoài ra các test case này được lưu trữ và tái sử dụng và làm mịn dần trong xuyên suốt vòng đời của dự án.

Vì vậy thiết kế test case (Test case design) là một kỹ năng có mục đích là thiết kế hiệu quả tương đối một tập hợp test case, không quá nhiều mà cũng không quá ít nhằm giúp người BA có thể thực hiện được kiểm thử với ít công sức nhất mà có thể phủ kín một cách vừa đủ các trường hợp nhằm đảm bảo chất lượng phần mềm khi chuyển giao.

Các phương pháp design test case theo black box

• Equivalence Partitioning (Phân đoạn tương đương)
• Boundary Value Analysis (Phân tích giá trị biên)
• Decision Table (Bảng quyết định)
• State Transition Testing (Chuyển trạng thái)
• Exploratory Testing (Khám phá)
• Error Guessing (Đoán mò lỗi)

Trong phạm vi bài viết này sẽ tập trung nói đến các phương pháp Error Guessing, Exploratory, Equivalence Partitioning và Decision Table.

Exploratory Testing

Cho chuyên gia hoặc đại diện người sử dụng vào test, cũng không cần phải xem các mô tả, yêu cầu, business rules của phần mềm. Bằng cách này có thể nhanh chóng tìm ra các bug có ảnh hưởng nghiêm trọng.

Error Guessing

Error guessing dựa theo kinh nghiệm test, chẳng có luật cụ thể nào cả mà hoàn toàn dựa vào kinh nghiệm của BA, thường người có kinh nghiệm sẽ gom thành các lỗi phổ biến hay gặp. Ví dụ:

• Nhập form với các ô text trống.
• Nhập form với giá trị invalid như cố ý nhập ký tự vào trường số.

Equivalence Partitioning

Là một phương pháp được sử dụng rất rộng rãi để giảm số lượng các test case có thể được yêu cầu để kiểm tra một hệ thống. Ý tưởng là phân chia tất cả các yếu tố đầu vào có thể thành các partition (phân đoạn). Các partition này đại diện cho một loạt các đầu vào hoạt động chính xác theo cùng một cách trong hệ thống. Lý giải cho phương pháp này là do bản chất người lập trình tốt thường vẫn sử dụng partition để tiết kiệm code, tiết kiệm công sức.

Xét ví dụ minh họa như hình dưới: form nhập liệu có 1 text box cho phép nhập số nguyên từ 1 đến 5. Sẽ là lãng phí nếu làm tất cả 7 test case với các input từ 0 đến 6. Chỉ cần 3 test case với 3 partition tương ứng là đủ.

Khi áp dụng phương pháp này sẽ phải chấp nhận xác suất rủi ro có những trường hợp không phủ được được, nhưng có thể đó không phải là trường hợp quan trọng hoặc ít xảy ra.

Decision table

Hãy xem xét ví dụ một chức năng đăng nhập với 2 text box username và password, quy tắc của chức năng như sau:

• Nếu nhập đúng username và password thì chức năng sẽ thông báo đăng nhập thành công.
• Nếu sai username hoặc password thông báo đăng nhập không thành công.

Một người thiết kế test case thiếu kinh nghiệm sẽ tổ hợp các trường hợp lại và liệt kê tổng cộng 4 test case phải thực hiện như sau

• Nhập đúng username, đúng password
• Nhập đúng username, sai password
• Nhập sai username, đúng password
• Nhập sai username, sai password

Nếu theo phương pháp bảng quyết định, sẽ rút gọn chỉ cần 3 test case như sau là được, nhờ đó tiết kiệm giảm bớt 25% công sức để thực hiện test.

• Nhập đúng user name và password.
• Nhập sai user name
• Nhập đúng user name, sai password

Bảng quyết định được vẽ ra như sau, trong đó Test case 4 và Test case 2 bản chất đã được thực hiện cùng lúc vì chỉ cần nhập sai username là đủ để nhận thông báo đăng nhập không thành công bất luận là password có nhập dúng hay không.

Mới chỉ một chức năng với 2 ô text box mà đã tiết kiệm được 25% công sức thì với một hệ thống phần mềm phức tạp, BA sẽ tiết kiệm được công sức rất nhiều thay vì phải lo lắng phủ kín tất cả mọi trường hợp.

Hãy thử xem xét ví dụ khác với chức năng đăng ký phức tạp hơn có 4 text box với quy tắc như sau

• 4 text box trên đều required.
• Password phải bằng retype password.

Nếu không áp dụng bảng quyết định, BA sẽ phủ tất cả trường hợp bằng cách tổ hợp tất cả các trường hợp đúng/sai của các text box, tổng cộng sẽ có 2⁴ = 16 trường hợp. Tuy nhiên nếu vẽ ra bảng quyết định BA sẽ thấy thực tế chỉ cần 5 trường hợp như dưới đây là đủ, tiết kiệm đến 60% công sức thực hiện test:

• Nhập đủ email, username, password, retype-password bằng password.
• Nhập trống email
• Nhập đủ email, trống username
• Nhập đủ email, username, trống password
• Nhập đủ email, username, password, retype-password khác với password

Tổng kết

Như vậy, trong vai trò là một BA của dự án phần mềm, nếu phải thực hiện nghiệm thu (User Acceptance Test) thì hoàn toàn có thể xác định được các test case cần thực hiện một cách tiết kiệm công sức nhất mà vẫn đảm bảo phủ được các trường hợp quan trọng và cần thiết nhất, qua đó tối ưu được năng suất làm việc. Đó là mục đích của kỹ năng thiết kế test case, đặc biệt là test hộp đen không đòi hỏi người BA phải có kiến thức lập trình hay hệ thống.

Nếu bạn là một IT Business Analyst, ưa thích làm sản phẩm quốc tế trong lĩnh vực bán lẻ - thương mại điện tử! Tham gia Tuyển dụng Business Analyst, môi trường làm việc từ xa, địa điểm tự do, quản lý linh hoạt theo Agile.

‍