ƯỚC TÍNH LOẠI KIỂM THỬ LIÊN QUAN VÀ CHI PHÍ
Công việc kiểm thử được thực hiện thường có thể được coi là một tiểu dự án trong dự án lớn hơn. Vì vậy, chúng ta có thể điều chỉnh các kỹ thuật ước tính cơ bản để kiểm thử. Chúng ta có thể bắt đầu với cấu trúc phân chia công việc xác định các giai đoạn, hoạt động và nhiệm vụ.
Bắt đầu từ mức cao nhất, có thể chia dự án kiểm thử thành các giai đoạn bằng cách sử dụng quy trình kiểm thử cơ bản được xác định trong Syllabus của ISTQB: lập kế hoạch và kiểm soát; phân tích và thiết kế; triển khai, chấp hành; đánh giá tiêu chí dừng và báo cáo; và các hoạt động kết thúc kiểm thử. Trong mỗi giai đoạn, chúng ta xác định các hoạt động và trong mỗi hoạt động, xác định các nhiệm vụ (task) và có thể là các nhiệm vụ con (subtask).
Để xác định các hoạt động và nhiệm vụ, chúng ta làm xuôi (forward) và làm ngược (backward). Khi nói làm xuôi, nghĩa là chúng ta bắt đầu với các hoạt động lập kế hoạch và sau đó di chuyển về phía trước từng bước một, và hỏi, “Bây giờ, điều gì sẽ xảy ra tiếp theo?”
Làm ngược có nghĩa là xem xét các rủi ro mà đã xác định trong quá trình phân tích rủi ro (chúng ta sẽ thảo luận trong Mục 5.5). Đối với những rủi ro mà bạn định giải quyết thông qua kiểm thử, hãy tự hỏi: “Vậy, những hoạt động và nhiệm vụ nào được yêu cầu trong mỗi giai đoạn để thực hiện việc kiểm thử này?” Hãy xem một ví dụ về cách bạn có thể làm ngược.
Giả sử rằng bạn đã xác định hiệu năng (performance) là một lĩnh vực rủi ro chính đối với sản phẩm của mình. Vì vậy, kiểm thử hiệu năng là một hoạt động trong giai đoạn thực hiện kiểm thử. Giờ đây, bạn ước tính các tác vụ liên quan đến việc chạy kiểm thử hiệu năng, thời gian thực hiện các tác vụ đó và số lần bạn cần chạy kiểm thử hiệu năng.
Những bài kiểm thử đó không phải tự nhiên mà xuất hiện: phải có ai đó phát triển chúng. Vì vậy, phát triển kiểm thử hiệu năng đòi hỏi các hoạt động trong phân tích, thiết kế và thực hiện kiểm thử. Bây giờ, bạn ước tính các tác vụ liên quan đến việc phát triển kiểm thử hiệu năng, chẳng hạn như viết kịch bản kiểm thử và tạo dữ liệu kiểm thử. Thông thường, kiểm thử hiệu năng cần được chạy trong môi trường kiểm thử đặc biệt được thiết kế giống như môi thật (production) hoặc môi trường hoạt động (field test), ít nhất là trong những cách có thể ảnh hưởng đến thời gian phản hồi và sử dụng tài nguyên cũng như kiểm thử hiệu năng cần các công cụ đặc biệt để tạo tải (load) và kiểm tra phản hồi (response). Vì vậy, việc mua lại và cấu hình môi trường kiểm thử hiệu năng là một hoạt động trong giai đoạn triển khai kiểm thử. Giờ đây, bạn ước tính các tác vụ liên quan đến việc mua và đặt cấu hình môi trường kiểm thử như vậy, chẳng hạn như mô phỏng hiệu năng dựa trên thiết kế môi trường production để tìm kiếm các vấn đề nút thắt cổ chai tiềm ẩn, tìm kiếm đúng phần cứng, phần mềm và công cụ phù hợp cũng như thiết lập phần cứng, phần mềm và công cụ.
Không phải ai cũng biết cách sử dụng các công cụ kiểm thử hiệu năng hoặc thiết kế các bài kiểm thử hiệu năng. Vì vậy, đào tạo hoặc bố trí nhân viên kiểm thử hiệu năng là một hoạt động trong giai đoạn lập kế hoạch kiểm thử. Tùy thuộc vào cách tiếp cận định thực hiện, bạn ước tính thời gian cần thiết để xác định và thuê một chuyên gia kiểm thử hiệu năng hoặc đào tạo một hoặc nhiều người trong tổ chức để thực hiện công việc.
Cuối cùng, trong nhiều trường hợp, một kế hoạch kiểm thử chi tiết được viết để kiểm thử hiệu năng, do sự khác biệt của nó so với các loại kiểm thử khác. Vì vậy, lập kế hoạch kiểm thử hiệu năng là một hoạt động trong giai đoạn lập kế hoạch kiểm thử. Bây giờ bạn ước tính thời gian cần thiết để soạn thảo, xem xét và hoàn thiện kế hoạch kiểm thử hiệu năng.
Khi bạn đang tạo cấu trúc phân chia công việc của mình, hãy nhớ rằng bạn sẽ muốn sử dụng nó cho cả ước tính (lúc đầu) cũng như giám sát và kiểm soát (khi dự án tiếp tục). Để đảm bảo tính chính xác của ước tính và kiểm soát chính xác, hãy đảm bảo rằng công việc được chia nhỏ đủ mịn. Điều này có nghĩa là các nhiệm vụ nên có thời lượng ngắn, chẳng hạn từ một đến ba ngày. Nếu chúng dài hơn nhiều (chẳng hạn như hai tuần) thì bạn sẽ gặp rủi ro rằng các nhiệm vụ phụ dài và phức tạp đang “ẩn nấp” trong nhiệm vụ lớn hơn chỉ được phát hiện sau đó. Điều này có thể dẫn đến những bất ngờ khó chịu trong dự án
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
