Test Planning

Là một tài liệu mô tả mục tiêu,phạm vi, phương pháp tiếp cận và tập trung vào sự lỗ lực kiểm thử phần mềm. Quá trình chuẩn bị Test Planning là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm.

Cấu trúc chung của một Test planning thường bao gồm các thông tin:

• Tên project
• Danh sách các module cần test
• Ngày bắt đầu, ngày kết thúc
• Danh sách các test case
• Nhân sự tham gia
• Tài nguyên sử dụng
• Kế hoạch thực hiện

Mục đích của test plan là gì?

• Cung cấp hướng dẫn rõ ràng: Một test plan cung cấp một lộ trình chi tiết cho các hoạt động kiểm thử, từ đó giúp các nhà phát triển hệ thống (system developer) định hướng suy nghĩ.
• Cải thiện giao tiếp: Tạo điều kiện giao tiếp hiệu quả giữa các tester, đảm bảo tất cả các bên liên quan hiểu rõ về quá trình này.
• Tiết kiệm thời gian: Những thông tin quan trọng như chiến lược, phạm vi và ước tính kiểm thử đều được ghi lại trong test plan. Vì vậy, điều này giúp nhóm quản lý hệ thống tốn ít thời gian hơn trong việc xem xét và sử dụng lại các thông tin này cho các dự án khác.

Các loại test planning

• Master test planning

Một kế hoạch kiểm thử level cao duy nhất cho một dự án/sản phẩm kết hợp tất cả các kế hoạch kiểm thử khác.

• Testing Level Specific Test Plans

Các kế hoạch cho mỗi mức thử nghiệm:

• Unit Test Plan

• Unit Testing (kiểm thử đơn vị) là một mức kiểm thử phần mềm với mục đích để xác nhận từng unit của phần mềm được phát triển đúng như được thiết kế. Unit testing là mức test nhỏ nhất trong bất kỳ phần mềm nào. các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit. Nó thường có một hoặc vài đầu vào nhưng đầu ra là duy nhất.
• Unit testing được thực hiện bởi lập trình viên và là white box testing. Được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt quá trình phát triển phần mềm.

Mục đích:

• Tăng sự đảm bảo khi có sự thay đổi mã
• Code dễ sử dụng, dễ hiểu có thể tái sử dụng
• Chi phí sửa chữa thấp hơn các giai đoạn sau
• Dễ dàng sửa lỗi hơn

• Integration Test Plan

• Integration Testing (kiểm thử tích hợp) là thực hiện kiểm thử tích hợp 1 nhóm mô đun riêng lẻ với nhau. Một hệ thống phần mềm bao gồm nhiều module được code bởi nhiều người khác nhau. Tích hợp kiểm thử tập trung vào việc truyền dữ liệu giữa các module với nhau.
• Kiểm thử tích hợp được thực hiện để phát hiện các lỗi về giao diện hoặc trong tương tác giữa các thành phần hoặc hệ thống tích hợp.
• Kiểm thử tích hợp thành phần: kiểm tra sự tương tác giữa các thành phần với điều kiện các thành phần đã pass ở phần kiểm thử thành phần trước đó.
• Kiểm thử tích hợp hệ thống 

• kiểm tra sự tương tác giữa các hệ thống con khác nhau và các hệ thống này đã pass ở lần kiểm thử trước đó.

• Được thực hiện bởi developer, một test team chuyên biệt hay một nhóm chuyên developer/kiểm thử viên tích hợp bao gồm cả kiểm thử phi chức năng và được thực hiện sau Unit Testing và trước System Testing.

Mục đích:

• Mục đích để tìm ra lỗi trong quá trình tích hợp các thành phần, các modul lại với nhau

• System Test Plan

• System testing (kiểm thử hệ thống) là thực hiện kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để đảm bảo nó hoạt động đúng yêu cầu.
• Kiểm thử hệ thống là kiểm thử hộp đen và được tập trung vào chức năng của hệ thống. Kiểm tra các chức năng và giao diện, các hành vi của hệ thống một cách hoàn chỉnh đáp ứng đúng với yêu cầu.

Mục đích: 

• Mục đích của giai đoạn này là để đánh giá sự hoạt động của hệ thống có đúng theo như tài liệu đặc tả và được thực hiện bởi các tester.

• Acceptance Test Plan

• Kiểm thử chấp nhận chính thức liên quan đến yêu cầu và quy trình kinh doanh để xác định liệu hệ thống có đáp ứng tiêu chí chấp nhận hay không và cho phép người dùng, khách hàng hoặc tổ chức được ủy quyền khác xác định có chấp nhận hệ thống hay không.
• Kiểm thử chấp nhận là mức thứ 4 được thực hiện sau khi hoàn thành kiểm thử hệ thống và trước khi đưa sản phẩm vào sử dụng chính thức. Với mục đích đảm bảo phần mềm đáp ứng đúng yêu cầu của khách hàng. Sản phẩm nhận được sự chấp nhận từ khách hàng/người dùng cuối.

Kiểm thử chấp nhận được chia thành 2 mức khác nhau:

• Kiểm thử alpha: được thực hiện tại nơi phát triển phần mềm bởi những người trong tổ chức nhưng không tham gia phát triển phần mềm.
• Kiểm thử beta: được thực hiện tại bởi khách hàng/ người dùng cuối tại địa điểm của người dùng cuối.

Mục đích: 

• Để đánh giá hệ thống tuân thủ đúng với yêu cầu của khách hàng và có thể chấp nhận hay không chấp nhận để bàn giao sản phẩm

• Testing Type Specific Test Plans

• Kế hoạch Kiểm thử Hiệu năng
• Kế hoạch Kiểm thử bảo mật

Test Planning gồm những gì?

• Phân tích sản phẩm 

Là bước đầu tiên và vô cùng quan trọng trong quá trình lập test plan. Nhằm giảm thiểu tối đa các lỗi không đáng có có thể xảy ra, các tester cần nghiên cứu và phân tích kỹ lưỡng để hiểu rõ các sản phẩm. Để phân tích sản phẩm, các system developer cần trả lời các câu hỏi sau:

• Đối tượng sử dụng sản phẩm này là ai?
• Mục tiêu sử dụng sản phẩm này là gì?
• Sản phẩm này sẽ làm việc ra sao?
• Cần có những phần cứng và phần mềm nào của sản phẩm?

Khi đặt ra các câu hỏi cụ thể như thế, các tester lập test plan có thể thu thập thông tin cần thiết để lập nên một test plan toàn diện và hiệu quả, đảm bảo sản phẩm đáp ứng được yêu cầu của người sử dụng.

• Thiết kế chiến lược kiểm thử

Là một phần không thể thiếu của bất kỳ một test plan nào. Để xây dựng một test plan hiệu, cần tuân theo những bước sau:

• Xác định phạm vi kiểm thử 

Để xác định phạm vi, quy trình gồm 4 giai đoạn:

• Yêu cầu khách hàng chính xác
• Xác định ngân sách dự án
• Đặc điểm kỹ thuật sản phẩm
• Kỹ năng và tài năng của nhóm kiểm thử 

• Xác định loại kiểm thử

Mỗi loại kiểm thử được xây dựng để phát hiện một loại lỗi riêng biệt. Tuy nhiên, tất cả các loại kiểm thử đều có mục tiêu chung là tìm ra lỗi sớm trước khi sản phẩm được phát hành ra thị trường. Người quản lý kiểm thử cần xem xét mức độ ưu tiên của từng loại kiểm thử, tùy theo từng loại sản phẩm hoặc thuộc tính nào đang được kiểm thử trong giai đoạn cụ thể và xác định loại kiểm thử nào muốn tập trung nhằm tiết kiệm chi phí.

• Tài liệu về rủi ro (risk) và vấn đề (issue)

Rủi ro là những sự kiện có xác suất xảy ra rất thấp và có khả năng thua lỗ. Khi rủi ro xảy ra thì nó sẽ trở thành vấn đề.

3. Xác định mục tiêu kiểm thử 

Mục tiêu hay mục đích của kiểm thử là mục tiêu tổng thể của dự án. Đó là cố gắng tìm ra càng nhiều lỗi của phần mềm thì càng tốt nhằm đảm bảo phần mềm hoạt động hiệu quả, không xảy ra lỗi khi phát hành đến tay người dùng. Ngoài ra, việc xác định đúng mục đích sẽ giúp quá trình kiểm thử diễn ra suôn sẻ và tiết kiệm thời gian.

4. Xác định tiêu chí kiểm thử

Tiêu chí kiểm thử là một tiêu chuẩn hoặc quy tắc mà một quy trình kiểm thử lấy đó làm chuẩn mực để dựa vào. Tiêu chí kiểm thử gồm 2 loại chính:

• Tiêu chí đình chỉ (Suspension Criteria)

Nếu các tiêu chí đình chỉ được đáp ứng, điều này có nghĩa là quy trình kiểm thử sẽ bị đình chỉ hoạt động cho đến khi các tiêu chí được giải quyết.

• Tiêu chí thoát (Exit Criteria)

Tiêu chí thoát biểu thị sự hoàn thành thành công của giai đoạn kiểm thử và là kết quả cần được đáp ứng trước khi tiếp tục giai đoạn phát triển tiếp theo.

Một vài phương pháp xác định tiêu chí thoát gồm:

• Tốc độ chạy (Run rate): là tỷ lệ giữa số trường hợp kiểm thử đã được thực hiện trên tổng số trường hợp kiểm thử của đặc tả kiểm thử
• Tỷ lệ vượt qua (Pass rate): là tỷ lệ giữa các số trường hợp kiểm thử thông qua trên tổng số các trường hợp kiểm thử được thực hiện.

Bài viết khác

Notion

  Là một ứng dụng quản lý công việc đa năng, hỗ trợ người dùng trong việc ghi chú, theo dõi nhiệm vụ, quản lý dự án, xây dựng wiki và lưu trữ cơ sở dữ liệu trong cùng một nền tảng. Là một ứng dụng viết ghi chú, nhưng nếu biết cách sử dụng, […]

Đọc thêm

Security Testing

Hay còn gọi là Kiểm thử bảo mật, là một trong những phần quan trọng trong phát triển phần mềm, nhằm đảm bảo các hệ thống và ứng dụng trong một tổ chức không có bất kỳ sơ hở nào có thể gây ra các tổn thất về an toàn bảo mật. Kiểm thử bảo […]

Đọc thêm

Non-Functional Testing

Hay còn gọi là Kiểm thử phi chức năng, là kỹ thuật kiểm thử tập trung vào việc đánh giá các khía cạnh phi chức năng của hệ thống. Nó kiểm tra các tham số không được kiểm tra trong Function Testing (kiểm thử chức năng), chẳng hạn như hiệu suất, khả năng sử dụng, […]

Đọc thêm

Unit Testing

Hay còn gọi là Kiểm thử đơn vị, là một loại kiểm thử phần mềm tập trung vào việc kiểm tra các thành phần hoặc “đơn vị” nhỏ nhất và riêng biệt của mã nguồn. Một đơn vị có thể là một hàm (function), một phương thức (method), một lớp (class) hoặc một module. Mục […]

Đọc thêm

Smoke Testing

Hay còn gọi là Kiểm thử khói, là một loại kiểm thử phần mềm nhanh chóng, tập trung vào việc xác minh các chức năng cốt lõi và quan trọng nhất của ứng dụng có hoạt động ổn định hay không. Mục đích chính là để kiểm tra xem bản dựng (build) mới của phần […]

Đọc thêm

Functional Testing

Hay còn gọi là kiểm thử chức năng, là kỹ thuật kiểm tra phần mềm dựa trên từng chức năng để đảm bảo hệ thống đáp ứng đúng yêu cầu đã đặt ra. Đây là dạng kiểm thử hộp đen, trong đó tester không cần quan tâm đến mã nguồn mà chỉ so sánh chức […]

Đọc thêm