Trong quá trình tạo ra một sản phẩm phần mềm thành công, có một vấn đề không thể tránh khỏi trong việc tìm kiếm sự cân bằng giữa chất lượng và ngày phát hành sản phẩm phần mềm. Kiểm thử cho phép thu được một sản phẩm đáp ứng được tất cả các yêu cầu. Tuy nhiên, bao gồm của mỗi rủi ro sản phẩm với các trường hợp kiểm thử khác nhau và biên soạn chúng mất quá nhiều thời gian. Quy trình kiểm thử được chuẩn bị đúng cách nên cung cấp một mức chất lượng bắt buộc mà không vượt quá thời gian dự án và ngân sách. Nếu thời gian kiểm thử được ước tính sai, nó có thể dẫn bạn đến việc phân phối sản phẩm muộn hoặc để giảm chất lượng và khả năng cạnh tranh. Ước lượng kiểm thử phần mềm là một quá trình khá phức tạp và thể tích, nhưng không nên đánh giá thấp ý nghĩa của nó đối với việc tạo ra dự án thành công.

Bài viết này chứa các đề xuất về cách thực hiện ước lượng kiểm thử phần mềm, chúng tôi hy vọng, có thể giúp bạn có được ước tính thời gian thực QA thực tế và thực tế hơn cho một dự án mới.

1. Phân chia các nhiệm vụ kiểm thử 1.1. Kế hoạch kiểm thử 1.2. Kế hoạch kiểm thử và các trường hợp kiểm thử 1.3. Cấu hình Môi trường Kiểm thử 1.4. Thực hiện các trường hợp kiểm thử
2. Gỡ lỗi các trường hợp kiểm thử sau lần chạy đầu tiên hoặc thay đổi sản phẩm 2.1. Kiểm thử hồi quy

Phân chia các nhiệm vụ kiểm thử

Theo số liệu thống kê ước tính QA, việc kiểm thử một ứng dụng bảng điều khiển một phần chiếm khoảng 20% thời gian phát triển của nó. Kiểm thử ứng dụng giao diện điều khiển hai phần chiếm 20-30% thời gian phát triển, một ứng dụng với GUI - 30-35%, một ứng dụng phân tán với GUI - 35-50%. Nhưng mỗi dự án và mỗi đội là duy nhất, đó là lý do tại sao ước tính thời gian này khá thô và không bao gồm một số rủi ro.

Để ước tính thời gian kiểm thử chính xác hơn và thực tế hơn, bạn nên sử dụng phương pháp phân chia, tức là bạn nên chia quá trình kiểm thử thành nhiều phần và ước tính thời gian cho từng phần. Theo quy định, quá trình kiểm thử của một sản phẩm mới có thể được chia thành 6 giai đoạn chính:

1. Kế hoạch thực thi.
2. Kế hoạch kiểm thử và phát triển trường hợp kiểm thử.
3. Cấu hình môi trường kiểm thử.
4. Thực hiện các trường hợp kiểm thử.
5. Gỡ lỗi các trường hợp kiểm thử sau lần chạy đầu tiên hoặc sau khi thay đổi sản phẩm.
6. Kiểm thử hồi quy.

Ước tính kế hoạch Kiểm thử

Giai đoạn này, bao gồm hai giai đoạn phụ: nghiên cứu về dự án và đưa ra chiến lược kiểm thử.

Nghiên cứu về dự án có thể được thực hiện theo những cách khác nhau trong các công ty khác nhau và các lệnh: đọc và phân tích tài liệu dự án, cuộc họp ban đầu, thảo luận chi tiết dự án với các nhà quản lý, vv Trung bình, chúng tôi khuyên bạn nên dành một hai ngày làm việc này. Không cần công việc này mất cả ngày làm việc nhưng ước tính 1-2 ngày sẽ cho phép bạn có đủ thời gian trong trường hợp có ý tưởng và câu hỏi mới.

Cần thêm thời gian trong các trường hợp:

• Dự án có quy mô khá lớn, có rất nhiều tài liệu. • Công việc với loại dự án này được thực hiện lần đầu tiên và cần thêm thời gian để nghiên cứu. • Các chuyên gia tham gia thảo luận dự án có lịch trình hoạt động khác nhau và được phân tán về mặt địa lý. Trong những trường hợp như vậy, cần thêm thời gian cho tổ chức cuộc họp.

Lập ra chiến lược kiểm thử ngụ ý xác định một số sắc thái quan trọng của công việc trong tương lai:

• Những loại kiểm thử sẽ được thực hiện. • Những loại chuyên gia được yêu cầu cho sự phát triển của kế hoạch kiểm thử và các trường hợp kiểm thử. • Có bao nhiêu chuyên gia sẽ thực hiện kiểm thử dự án và những kỹ năng họ cần có.

Trong thực tiễn của chúng tôi, để xác định các loại và loại yêu cầu và các phương pháp hiệu quả để kiểm thử phần mềm, chúng tôi dựa trên mẫu sẵn sàng, bao gồm tất cả các loại kiểm thử có thể được đề cập.

Tùy thuộc vào loại dự án, yêu cầu chất lượng và các yếu tố khác, mẫu được sửa chữa. Việc tinh chỉnh như vậy mất khoảng một giờ.

Chú ý: Ở giai đoạn này, xác định các chuyên gia cho công việc của dự án sẽ giúp ước tính thời gian chính xác hơn khi chúng ta có thể tính đến các kỹ năng và kinh nghiệm của họ. Nó cũng sẽ giúp đưa vào kế hoạch kiểm thử kỳ nghỉ và ngày nghỉ của họ.

Ước lượng và Phát triển kế hoạch kiểm thử và các trường hợp kiểm thử

Sự phát triển của một kế hoạch kiểm thử và các trường hợp kiểm thử là một quá trình khá mất thời gian và đòi hỏi phải tốn nhiều thời gian. Khi lập kế hoạch, bạn nên dựa vào chiến lược kiểm thử được phát triển trên một giai đoạn trước đó. Chiến lược kiểm thử cho thấy các loại trường hợp kiểm thử nên được tạo ra và nó cũng giúp thiết lập mức độ ưu tiên của chúng.

Trong thực tiễn của chúng tôi, chúng tôi dựa trên nguyên tắc rằng một yêu cầu đối với sản phẩm phải được kiểm thử bởi ít nhất năm trường hợp kiểm thử. Với sự trợ giúp của quy tắc này, chúng tôi có thể ước tính khoảng cách số lượng các trường hợp kiểm thử được yêu cầu và thời gian để tạo ra chúng.

Thời gian cho sự phát triển của kiểm thử phụ thuộc vào sự phức tạp của kế hoạch kiểm thử nhưng trung bình, phát triển của một trường hợp kiểm thử mất 10 phút. Trong trường hợp chung, sự phát triển của một kế hoạch kiểm thử mà không có các trường hợp kiểm thử và xem xét lại có thể mất hai ba ngày. Tương ứng, nếu dự án yêu cầu các trường hợp kiểm thử, bạn nên ước tính thêm thời gian để phát triển. Một số đặc thù của việc lên kế hoạch giai đoạn này:

• Nếu một chuyên gia chuẩn bị kế hoạch kiểm thử và các trường hợp kiểm thử lần đầu tiên, bạn nên ước tính thời gian nhiều hơn đối với chuyên gia giàu kinh nghiệm hơn. • Nếu dự án sử dụng công nghệ mới cho đội, bạn nên tính đến thời gian nghiên cứu của mình. Tùy thuộc vào độ phức tạp của công nghệ và về trình độ của các chuyên gia sẽ thực hiện nhiệm vụ này, thời gian nghiên cứu bổ sung có thể từ một ngày đến vài tuần. Bạn không nên bỏ qua nó bằng bất kỳ phương tiện nào. Nếu kế hoạch kiểm thử được chuẩn bị mà không tính đến các chi tiết dự án cụ thể, nó sẽ làm tăng thời gian để thay đổi nó ở giai đoạn kiểm thử và ở mức tồi tệ nhất để giảm chất lượng sản phẩm. • Tùy thuộc vào loại kiểm thử và dự án, bạn có thể cần thời gian để tạo ra dữ liệu kiểm thử. Cũng nên tính đến giai đoạn này. • Thứ tự phát triển của các trường hợp kiểm thử phải tương ứng với thứ tự hoạt động của chúng. Có thể có hai biến thể cho ưu tiên kiểm thử: • Trước tiên, bạn nên chạy kiểm thử bao gồm các mô-đun ưu tiên đầu tiên và các tính năng của dự án. • Trước tiên, bạn nên chạy kiểm thử cho các mô-đun dự án đã sẵn sàng để kiểm thử.

Tùy thuộc vào thứ tự của bài kiểm thử đang chạy, bạn nên chuẩn bị thứ tự tạo kế hoạch kiểm thử và các trường hợp kiểm thử. Nó cũng có thể ảnh hưởng đến ước lượng cuối cùng.

• Nếu công ty có kinh nghiệm trong việc kiểm thử các dự án tương tự, sau đó sử dụng kế hoạch kiểm thử và các trường hợp kiểm thử cũ làm cơ sở sẽ cắt giảm thời gian ước tính. • Thời gian để rà soát các kế hoạch kiểm thử đã chuẩn bị và các trường hợp kiểm thử cần được phân bổ cho cả những người cũ và mới được tạo ra. Khi lập kế hoạch lần này, bạn nên tính đến khối lượng công việc và lịch trình cá nhân của các chuyên gia sẽ thực hiện việc xem xét lại. • Chuyên gia giàu kinh nghiệm lập kế hoạch kiểm thử và các trường hợp kiểm thử càng nhiều thì thời gian để xem xét và thay đổi thêm là cần thiết.

Cấu hình Môi trường Kiểm thử

Thời gian, bắt buộc cho giai đoạn này, phụ thuộc vào các yếu tố sau:

• Có cần phải mua thiết bị hay không? Khi cần mở rộng phòng kiểm thử, thời gian cần được lên kế hoạch với tính cụ thể và khả năng của công ty. Nếu thiết bị được bán và công ty có thể mua nó ngay lập tức, thời gian sẽ được cắt giảm đáng kể so với trường hợp thiết bị cụ thể phải được giao hàng của khách hàng nước ngoài hoặc khi công ty không có khả năng đó vào lúc này. • Thời gian cài đặt và cấu hình môi trường kiểm thử phụ thuộc vào trình độ của chuyên gia và kinh nghiệm làm việc với các môi trường kiểm thử tương tự. Nếu công ty có một bộ phận đặc biệt cho các nhiệm vụ đó, sẽ cần ít thời gian hơn so với trường hợp các chuyên gia QA sẽ thực hiện công việc này.

Thời gian để cài đặt và cấu hình của môi trường kiểm thử trực tiếp phụ thuộc vào sự phức tạp của người cuối cùng. Thông thường, phải mất từ một giờ đến một ngày để cấu hình môi trường kiểm thử cho dự án cỡ trung bình hoạt động với các hệ điều hành phổ biến và không đòi hỏi các giải pháp hệ thống phức tạp. Trong trường hợp khác, ước tính thời gian bổ sung được yêu cầu tùy thuộc vào đặc thù nhiệm vụ.

Thực thi các trường hợp kiểm thử

Trong thực tế của chúng tôi, chúng tôi sử dụng các quy tắc mà việc thực hiện một trong những trường hợp kiểm thử lấy của chuyên gia QA khoảng 5 phút. Kế hoạch kiểm thử chứa các trường hợp kiểm thử phức tạp và quy mô khác nhau: một số trường hợp kiểm thử có thể được thực hiện trong 1 phút, các trường hợp khác - trong 10 phút. Kết quả là, thời gian trung bình của kiểm thử là 5 phút.

Nên tăng thời gian cho một trường hợp kiểm thử lên đến 10 phút nếu việc kiểm thử được thực hiện bởi chuyên gia kiểm định chất lượng thiếu kinh nghiệm. Vì vậy, chúng ta có thể tính đến các rủi ro tồn tại nếu không có kinh nghiệm làm việc cần thiết.

Một trong những khó khăn chính của việc lập kế hoạch cho giai đoạn này là bạn không thể dự đoán chính xác số lượng lỗi sẽ được tìm thấy trong khi kiểm thử và sự phức tạp của quá trình tái hiện lỗi. Trung bình, viết một báo cáo về một lỗi mất 10-15 phút. Càng tìm ra càng nhiều lỗi thì càng có nhiều thời gian cho các báo cáo về mỗi lỗi. Nếu lỗi quá phức tạp, nó không đủ thậm chí vài giờ để tìm ra vị trí chính xác của nó. Có nhiều phương pháp cho phép bạn ước tính số lượng lỗi có thể xảy ra trong mỗi phiên bản sản phẩm tiếp theo. Thật khó để xác định chính xác số lượng lỗi trong phiên bản mới mặc dù.

Để không để kiểm thử vượt quá thời gian dự kiến, bạn nên bao gồm thời gian cho các rủi ro khác nhau trong lịch trình. Thời gian bổ sung để chuẩn bị một số báo cáo về lỗi tìm thấy và cũng thời gian cho việc định vị các lỗi phức tạp nhất sẽ được đưa vào các rủi ro kiểm thử chung. Theo kỹ thuật ước tính kiểm thử của chúng tôi, chúng tôi khuyên bạn nên thêm khoảng 20-25% thời gian cho các trường hợp đó vào ước tính cuối cùng của bạn.

Dù sao, bạn nên theo cảm giác của bạn. Nếu kiểm thử phiên bản sản phẩm được ước tính trong 10 giờ và bản địa hóa của một lỗi tìm thấy mất hơn 2-3 giờ, bạn nên trì hoãn nó cho đến khi kết thúc giai đoạn kiểm thử (nếu lỗi không phải là quá quan trọng hoặc ngăn chặn ). Sau khi kết thúc giai đoạn kiểm thử, nếu còn thời gian bạn có thể quay trở lại làm việc với lỗi này. Trong trường hợp này, bạn cung cấp sự hiện diện của tất cả các kết quả kiểm thử bắt buộc mà không cần đưa dự án ra khỏi lịch trình.

Gỡ lỗi các trường hợp kiểm thử sau lần chạy đầu tiên hoặc thay đổi sản phẩm

Giai đoạn này của công việc mất khoảng 10-15% thời gian là cần thiết cho việc tạo ra các kế hoạch kiểm thử và các trường hợp kiểm thử.

Thời gian yêu cầu cũng phụ thuộc trực tiếp vào thời gian đã được phân bổ để xem lại kế hoạch kiểm thử và các trường hợp kiểm thử ngay sau khi chuẩn bị. Nếu quá trình xem xét đã đủ kỹ lưỡng, thời gian để sửa lại sau khi chạy có thể giảm xuống. Nhưng thời gian để xem xét phải được tính đến một cách đầy đủ.

Kiểm thử hồi quy

Khi thực hiện kiểm thử hồi quy cho các phiên bản sản phẩm mới, bạn nên tính đến các sắc thái sau:

• Loại kiểm thử nào là cần thiết trong giai đoạn này? Có cần phải thực hiện kiểm thử đầy đủ hay không chỉ là smoke testing cho phiên bản sản phẩm trung gian? • Số lượng các trường hợp kiểm thử trong kế hoạch kiểm thử có thể được thay đổi sau khi sửa chữa.

Khi kiểm thử được thực hiện bởi một và cùng một chuyên gia duy nhất, thời gian để chạy các bài kiểm thử có thể giảm xuống vì các bài kiểm thử sẽ không mới đối với người đó.

Nếu dự án hỗ trợ một số hệ điều hành, có một sự cần thiết để kiểm thử công việc trên tất cả các hệ điều hành yêu cầu của đặc tả. Khi sản phẩm có kiến trúc máy khách - máy chủ, cũng rất quan trọng để chạy kiểm thử trên các thống kết hợp khác nhau. Thường không thể kiểm thử tất cả các kết hợp vì cần có thời gian tuyệt vời và không thể kết hợp với tổng thời gian phát triển.

Trong những trường hợp như vậy, điều quan trọng là bao gồm ma trận tổ hợp hệ thống càng nhiều càng tốt. Ví dụ, nếu một ứng dụng hỗ trợ năm hệ thống khác nhau cho phía máy chủ và năm hệ thống cho phía khách hàng, bạn nên chọn các tổ hợp bao gồm tất cả các hệ thống này mà không cần lặp lại. Điều này có nghĩa là bạn nên tránh biến thể khi client XP SP3 được kiểm thử với tất cả các hệ thống có thể cho phía máy chủ hoặc ngược lại. Bạn chỉ cần cố gắng để lo hết mỗi hệ thống trong các kết hợp kiểm thử.

Nếu phiên bản sản phẩm là trung gian, việc kiểm thử đầy đủ sẽ được thực hiện trên một số hệ thống quan trọng nhất đối với người dùng. Smoke testing phải được thực hiện trên phần còn lại của hệ thống. Khi tính đến các ưu tiên về hệ thống cho sản phẩm của bạn, bạn có thể điền vào ma trận càng hiệu quả càng tốt và thực hiện việc kiểm thử trong một khoảng thời gian giới hạn.

Khi ma trận của hệ thống kết hợp thực tế cho giai đoạn phát triển này được chuẩn bị, rất dễ để ước tính tổng thời gian cho việc kiểm thử phiên bản sử dụng kỹ thuật ước tính như vậy:

T = (T (A) * K (A) + T (F) * K (F) + T (S) * K (S)) * 1,25,

Trong đó T () - thời gian để hoàn thành kiểm thử trên một cấu hình; K () - số cấu hình để truyền; A – acceptance testing; S - smoke testing; F - kiểm thử đầy đủ.

Kết luận

Thật khó để chỉ ra các kỹ thuật ước tính chính xác trong kiểm thử phần mềm vì QA là một quá trình phức tạp có nguy cơ cao và luôn có một số sai lệch trong tất cả các ước tính của nó. Đó là lý do tại sao kết hợp các kỹ thuật và phương pháp ước lượng kiểm thử phần mềm khác nhau có tính đến các chi tiết cụ thể của dự án và nhóm kiểm thử với sự hiểu biết về các yếu tố ảnh hưởng đến chi phí, thời gian và tài nguyên như kiến thức nhóm hoặc mô hình phát triển dự án nhanh.

Phương pháp mà chúng tôi đề xuất bạn sẽ giúp bạn đưa ra ước tính cơ bản cho việc kiểm thử sản phẩm của bạn; việc tính toán tất cả các chi tiết cụ thể sẽ giúp tăng độ chính xác của ước tính và làm cho nó trở nên thực tế càng tốt.

Vì vậy, công thức chung cho ước tính kiểm thử là như sau (mẫu ước tính của chúng tôi):

T = T (tìm hiểu yêu cầu + chiến lược kiểm thử) + T (chuẩn bị tài liệu kiểm thử) + T (chuẩn bị môi trường kiểm thử) + T (lần chạy đầu tiên + cập nhật tài liệu kiểm thử) + T (kiểm thử hồi quy).

Bài viết được dịch lại từ nguồn: https://www.apriorit.com/qa-blog/197-testing-time-estimation