PHẢI LÀM GÌ KHI LẬP KẾ HOẠCH KIỂM THỬ
Viết một kế hoạch kiểm thử tốt dễ hơn viết một cuốn tiểu thuyết, nhưng cả hai nhiệm vụ đều đòi hỏi một cách tiếp cận có tổ chức và suy nghĩ cẩn thận. Trên thực tế, không giống như một số cuốn tiểu thuyết, một kế hoạch kiểm thử tốt được giữ ngắn gọn và tập trung nên một số người có thể cho rằng viết một kế hoạch kiểm thử tốt là khó hơn. Hãy xem xét một số nhiệm vụ lập kế hoạch cần thực hiện.
Ở cấp độ cao, cần xem xét mục đích mà công việc kiểm thử phục vụ. Xét về nhu cầu tổng thể của tổ chức, mục đích này được gọi khác nhau là nhiệm vụ của nhóm kiểm thử hoặc chính sách kiểm thử của tổ chức. Về dự án cụ thể, hiểu mục đích của kiểm thử có nghĩa là biết câu trả lời cho các câu hỏi như:
- Điều gì nằm trong phạm vi và điều gì nằm ngoài phạm vi của nỗ lực kiểm thử này?
- Mục tiêu kiểm thử là gì?
- Những rủi ro quan trọng của dự án và sản phẩm là gì? (thêm về rủi ro trong Mục 5.5).
- Những hạn chế nào ảnh hưởng đến việc kiểm thử (ví dụ: giới hạn ngân sách, thời hạn cố định….)?
- Điều gì là quan trọng nhất đối với sản phẩm và dự án này?
- Những khía cạnh nào của sản phẩm có thể kiểm thử nhiều hơn (hoặc ít hơn)?
- Lịch trình thực hiện kiểm thử tổng thể là gì và nên quyết định thứ tự chạy các bài kiểm thử cụ thể như thế nào? (Rủi ro về sản phẩm và lập kế hoạch, được thảo luận sau trong chương này, sẽ ảnh hưởng đến câu trả lời cho những câu hỏi này.)
Nên chọn các chiến lược phù hợp với mục đích kiểm thử.
Ngoài ra, bạn cần quyết định cách chia công việc kiểm thử thành nhiều cấp độ khác nhau, như đã thảo luận trong Chương 2 (ví dụ: thành phần, tích hợp, hệ thống và chấp nhận). Nếu quyết định đó đã được đưa ra, bạn cần quyết định cách phù hợp nhất với công việc kiểm thử của mình ở cấp độ mà bạn chịu trách nhiệm với công việc kiểm thử được thực hiện ở các cấp độ kiểm thử khác đó. Trong quá trình phân tích và thiết kế các bài kiểm thử, bạn sẽ muốn giảm khoảng cách và chồng chéo giữa các cấp độ, trong quá trình thực hiện kiểm thử, bạn sẽ muốn phối hợp giữa các cấp độ. Những chi tiết như vậy liên quan đến sự phối hợp giữa các cấp thường được đề cập trong kế hoạch kiểm thử tổng thể.
Ngoài việc tích hợp và phối hợp giữa các cấp độ kiểm thử, bạn cũng nên lập kế hoạch tích hợp và phối hợp tất cả các công việc kiểm thử sẽ được thực hiện với phần còn lại của dự án. Ví dụ: những mục nào phải đạt khi kiểm thử?
Có các vấn đề về nguồn cung đang diễn ra không, chẳng hạn như với các tờ tiền giả (tức tiền giấy mô phỏng) cho một ứng dụng tài chính như máy ATM? Khi nào các lập trình viên sẽ hoàn thành công việc trên hệ thống đang được kiểm thử? Hỗ trợ hoạt động nào là cần thiết cho môi trường kiểm thử? Loại thông tin nào phải được gửi cho nhóm bảo trì khi kết thúc việc kiểm thử?
Nói một cách chi tiết, điều khiến một kế hoạch trở thành một kế hoạch (chứ không phải là một tuyên bố về các nguyên tắc, một danh sách dài các ý tưởng hay hoặc một tập hợp các gợi ý) là tác giả chỉ rõ trong đó ai sẽ làm gì khi nào và (ít nhất là trong một khoảng thời gian nhất định) như thế nào. Nguồn lực được yêu cầu để thực hiện công việc. Đây thường là những quyết định khó khăn đòi hỏi phải xem xét cẩn thận và xây dựng sự đồng thuận trong toàn nhóm, kể cả với người quản lý dự án.
Toàn bộ quá trình kiểm thử (từ lập kế hoạch đến khi kết thúc) tạo ra thông tin, một số trong đó bạn sẽ cần phải ghi lại. Người kiểm thử nên viết các thiết kế, trường hợp và thủ tục kiểm thử chính xác như thế nào? Họ nên để người kiểm thử đánh giá đến mức nào trong quá trình thực hiện kiểm thử và các vấn đề về khả năng tái hiện lại vấn đề kết hợp với các quyết định là gì ? Người kiểm thử có thể sử dụng những loại mẫu nào cho các tài liệu khác nhau mà họ sẽ tạo? Các tài liệu đó liên quan với nhau như thế nào? Nếu bạn có ý định sử dụng các công cụ cho các tác vụ như thiết kế và thực thi kiểm thử (như đã thảo luận trong Chương 6) bạn sẽ cần hiểu cách mà các công cụ đó thu thập tài liệu trong khi thực hiện kế hoạch.
Một số thông tin cần thu thập ở dạng dữ liệu thô và sau đó chắt lọc. Bạn định sử dụng số liệu nào để theo dõi, kiểm soát và quản lý việc kiểm thử? Bạn sẽ sử dụng chỉ số nào trong số đó (và có thể là các chỉ số khác) để báo cáo kết quả của mình? Chúng ta sẽ xem xét kỹ hơn các câu trả lời có thể có cho những câu hỏi đó trong Mục 5.3, nhưng một kế hoạch kiểm thử tốt sẽ cung cấp câu trả lời sớm trong dự án.
Cuối cùng, quay trở lại cấp độ cao hơn, hãy nghĩ xem điều gì sẽ đúng với dự án khi dự án đã sẵn sàng để bắt đầu thực hiện việc kiểm thử. Điều gì sẽ đúng với dự án khi dự án đã sẵn sàng tuyên bố thực hiện kiểm thử? Tại thời điểm nào bạn có thể bắt đầu một cấp độ hoặc giai đoạn kiểm thử cụ thể, bộ kiểm thử hoặc mục tiêu kiểm thử một cách an toàn? Khi nào bạn có thể hoàn thành nó? Các yếu tố cần xem xét trong các quyết định như vậy thường được gọi là “tiêu chí đầu vào” (entry criteria) và “tiêu chí dừng” (exit criteria). Đối với các tiêu chí như vậy, các yếu tố điển hình là:
- Mua và cung cấp: sự sẵn có của nhân viên, công cụ, hệ thống và các vật liệu khác cần thiết.
- Các hạng mục kiểm thử: trạng thái mà các hạng mục được kiểm thử phải có để bắt đầu và kết thúc kiểm thử.
- Lỗi (defect): số lỗi hiện hữu, tỷ lệ đến (arrival rate), số lỗi còn lại và số lỗi đã được xử lý.
- Kiểm thử: chạy bài kiểm thử đã chạy, số bài thành công, thất bại, bị chặn, bỏ qua….
- Phạm vi: các phần của cơ sở kiểm thử, mã phần mềm hoặc cả hai phần đã được kiểm thử và phần nào chưa được kiểm thử.
- Chất lượng: trạng thái của các đặc tính chất lượng quan trọng đối với hệ thống.
- Tiền: chi phí tìm lỗi tiếp theo ở cấp độ kiểm thử hiện tại so với chi phí tìm ra nó ở cấp độ kiểm thử tiếp theo (hoặc ở trong bản thương mại (production)).
- Rủi ro: các kết quả không mong muốn có thể xảy ra do chuyển giao quá sớm (chẳng hạn như các lỗi tiềm ẩn hoặc các phần chưa được kiểm thử) hoặc chuyển giao quá muộn (ví dụ như mất thị phần).
Khi viết tiêu chí dừng (exit criteria), chúng ta phải nhớ rằng một dự án thành công là sự cân bằng giữa chất lượng, ngân sách, tiến độ và tính năng. Điều này thậm chí còn quan trọng hơn khi áp dụng tiêu chí dừng khi kết thúc dự án
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
