Kỹ thuật kiểm thử dựa vào checklist (checklist-based testing) không hẳn là một trào lưu mới trong kiểm thử phần mềm, nhưng gần đây ngày càng nhiều người nhận ra những lợi ích mà chúng mang lại. Bài viết này giới thiệu về: Thế nào kiểm thử dựa vào checklist, Lợi ích và thách thức mà loại kiểm thử này mang lại, Cách thức xây dựng một checklist thông qua một ví dụ thực thế. Nào hãy bắt đầu tìm hiểu cùng mình nhé.
Kiểm Thử Dựa Vào Checklist Là Gì?
Kiểm thử dựa vào checklist là một kỹ thuật kiểm thử phần mềm dựa vào kinh nghiệm của kỹ sư kiểm thử để thiết kế ra một danh sách những đầu mục cần kiểm tra. Với sự trợ giúp của kỹ thuật này, người kiểm thử có thể thiết kế, tạo mới, và tiến hành kiểm tra để bao quát mọi điều kiện thử nghiệm có trong checklist.
Lợi Ích Của Việc Sử Dụng Checklist
Kỹ thuật kiểm thử dựa vào checklist được sử dụng rộng rãi bởi các kỹ sư có nhiều kinh nghiệm bởi tính tiện lợi và năng suất của nó. Một số lợi ích tiêu biểu cần được kể đến như:
- Tiết kiệm được thời gian, công sức: Việc tạo ra checklist tốn ít thời gian hơn rất nhiều so với việc thiết kế tài liệu test case chi tiết. Do đó, đối với những dự án có deadline ngắn, cần kiểm tra sản phẩm gấp thì kỹ thuật kiểm thử này tỏ ra vô cùng hiệu quả.
- Có thể tái sử dụng lại nhiều lần: Kiểm thử viên có thể tái sử dụng checklist trong những giai đoạn tiếp theo của quy trình kiểm thử hoặc dựa vào checklist có sẵn để mở rộng dựa theo kinh nghiệm cá nhân, hoặc khi sản phẩm có sự cập nhật, cải tiến, nâng cấp.
- Hiệu quả trong việc kiểm tra luồng hoạt động sản phẩm: Kiểm thử dựa trên checklist tỏ ra rất hiệu quả khi bạn cần thực hiện kiểm tra luồng hoạt động của sản phầm từ đầu tới cuối (end-to-end testing) để bao quát toàn bộ tính năng của sản phẩm. Sử dụng kỹ thuật thiết kế kiểm thử này sau khi chạy bộ thử nghiệm chính (main test suites) sẽ giúp xác định các lỗi nghiêm trọng tiềm ẩn và giảm thiểu khả năng bỏ sót các thử nghiệm quan trọng.
- Sử dụng như tài liệu training sản phẩm: Checklist cũng có thể là một cách tuyệt vời để giới thiệu cho các kỹ sư QA mới về quy trình kiểm thử cũng như bản thân sản phẩm. Do đó, công ty sẽ tiết kiệm được nguồn lực cho đào tạo và có thể đưa các kỹ sư mới làm việc dự án thực tế được nhanh hơn.
Thách Thức Khi Sử Dụng Checklist
Cũng như bất kỳ kỹ thuật kiểm thử nào, bên cạnh những lợi ích của việc sử dụng checklist mang lại, nó cũng đi kèm với một số rủi ro tiềm ẩn. Khi bạn đang nghĩ đến việc đưa checklist vào quy trình kiểm thử của mình, hãy xem xét một số thách thức sau đây:
- Nhiều cách hiểu khác nhau với cùng một checklist: Checklist được viết dựa vào kinh nghiệm và sự hiểu biết của tác giả, do đó có thể cùng một bộ checklist nhưng có thể có nhiều cách tiếp cận khác nhau. Một checklist phức tạp, nâng cao có thể tạo ra các đầu ra khác nhau trong những lần sử dụng.
- Cần được cập nhật thường xuyên: Cùng với sự cập nhật, cải tiến thường xuyên của phần mềm, để bao quát được đầy đủ các tính năng mới của sản phẩm thì các checklist cũng cần được thường xuyên cập nhật.
- Không áp dụng được đại trà: Kỹ thuật thiết kế kiểm thử này không phải lúc nào cũng có thể sử dụng được trong kiểm thử phần mềm và không phải lúc nào cũng phù hợp trong mọi giai đoạn của vòng đời phát triển phần mềm. Đối với các thành phần, chức năng hệ thống phức tạp sẽ rất khó thậm chí không thể minh hoạ, áp dụng checklist để kiểm tra được.
Xây Dựng Checklist Như Thế Nào?
Khi phân tích các tính năng của sản phẩm cần được kiểm thử, các kiểm thử viên sẽ tạo ra một checklist mới hoặc sẽ mở rộng từ checklist đã có. Thông thường, những checklist này được tạo dựa trên kinh nghiệm của kiểm thử viên cũng như kiến thức về sản phẩm như sản phẩm đó như thế nào, có những tính năng gì, điều gì khiến cho sản phẩm ngừng hoạt động… và những hiểu biết về tầm quan trọng của sản phẩm đối với người dùng cuối (end user).
Checklist có thể được tạo để hỗ trợ những loại kiểm thử khác, bao gồm cả kiểm thử chức năng và kiểm thử phi chức năng. Để xây dựng checklist, kiểm thử viên có thể sử dụng chính sản phẩm, cũng như toàn bộ những loại tài liệu sẵn có về sản phầm, bao gồm:
- Tài liệu đặc tả (BRS, SRS)
- Tiêu chí chấp nhận (Acceptance Criteria) được mô tả trong User story
- Checklist cấp cao (High-level checklist)
- Các tiêu chuẩn ISO và IEEE
Từ những thông tin tìm hiểu, kiển thức về sản phẩm và bằng kinh nghiệm của mình, kiểm thử viên sẽ chuyển chúng thành checklist mới hoặc thêm vào checklist đã có sẵn.
Ví Dụ Minh Họa
Để hiểu sâu hơn về kỹ thuật kiểm thử này, mình sẽ đưa ra một ví dụ nhỏ về chính một trang trong website này để các bạn có thể hình dung một cách trực quan hơn https://testviewpoint.com/contact.
| ID | Mục lớn | Mục nhỏ | Kết quả test |
|---|---|---|---|
| 1 | Kiểm tra giao diện | ||
| 1.1 | Nội dung hiển thị phải chính xác không có bất kỳ lỗi chính tả hoặc ngữ pháp nào | ||
| 1.2 | Đảm bảo mỗi phần tử giao diện người dùng xuất hiện đúng màu sắc, kích thước, hình dạng và vị trí | Tiêu đề | |
| “Your name” textbox | |||
| “Your mail” textbox | |||
| “Subject” textbox | |||
| “Your message (optional)” textbox | |||
| 1.3 | Các thay đổi được thực hiện trên một màn hình không ảnh hưởng đến bố cục trên một kích thước màn hình khác | ||
| 1.4 | Trang web xuất hiện giống nhau trên mọi trình duyệt, hệ điều hành hoặc thiết bị | ||
| 1.5 | Kiểm tra xem có thành phần nào bị ẩn hoặc trùng lặp với bất kỳ thành phần giao diện người dùng nào khác không | ||
| 2 | Kiểm tra chức năng | ||
| 2.1 | Kiểm tra các trường bắt buộc | ||
| 2.2 | Kiểm tra điều hướng (navigation) | ||
| 2.3 | Kiểm tra các liên kết trong trang | ||
| 2.4 | Kiểm tra pop-up hoặc message xác nhận | Message hiển thị khi gửi thành công | |
| Message hiển thị khi gửi thất bại | |||
| Xảy ra lỗi validation | |||
| Nội dung gửi bị coi là thư rác | |||
| Nhập vào một trường với độ dài lớn hơn độ dài tối đa cho phép | |||
| Nhập vào một trường với độ dài ngắn hơn độ dài tối thiểu cho phép | |||
| Địa chỉ mail không hợp lệ | |||
| 2.5 | JavaScript đang hoạt động bình thường trong tất cả các trình duyệt | ||
Kết Luận
Kỹ thuật kiểm thử dựa vào checklist là một phương pháp tuyệt vời giúp bạn có thể vận dụng kinh nghiệm kiểm thử cũng như kiếm thức của mình về sản phẩm để thiết kế danh sách các bài kiểm tra cho sản phẩm, đồng thời cũng sẽ rút ngắn được thời gian chuẩn bị cho quá trình kiểm thử của mình. Tuy nhiên, giống như bất kỳ kỹ thuật thiết kế thử nghiệm nào khác, nó cũng có những ưu điểm và nhược điểm riêng. Do đó, chúng ta nên xem xét chúng như một kỹ thuật bổ sung chứ không phải là một phương pháp kiểm tra độc lập. Hãy bắt đầu bằng cách chuẩn bị tất cả các tiêu chí kiểm tra sẵn có để tận dụng tối đa kỹ thuật này nhé.