TEST PLAN LÀ GÌ

1. Test Plan là gì?

Test Plan là một tài liệu chi tiết phác thảo chiến lược kiểm thử, Mục tiêu kiểm thử, tài nguyên (nhân lực, phần mềm, phần cứng) cần thiết để kiểm thử, schedule kiểm thử, Dự toán kiểm thử và deliver. Test Plan đóng vai trò là một kế hoạch chi tiết để tiến hành các hoạt động kiểm thử phần mềm như một quy trình xác định, được giám sát và kiểm soát từng bước bởi Test Manager.Bạn đang xem: Test plan là gì? có vai trò như thế nào?

Hãy bắt đầu với kịch bản sau : Trong một cuộc họp, bạn muốn thảo luận về Test Plan với các thành viên trong nhóm, nhưng họ không quan tâm.

Bạn đang xem: Test plan là gì


*

Trong trường hợp như vậy, bạn sẽ làm gì? Chọn câu trả lời của bạn theo hình bên dưới:

*

A) Tôi là Manager hãy làm mọi thứ như tôi nói

B) OK, để tôi giải thích tại sao chúng ta cần lập Test Plan

2. Tầm quan trọng của Test Plan

Lập Test Plan có nhiều lợi ích

Test Plan giúp chúng ta xác định effort cần thiết để xác nhận chất lượng của ứng dụng đang kiểm thửGiúp những người ngoài nhóm kiểm thử như nhà phát triển, quản lý doanh nghiệp, khách hàng hiểu chi tiết về kiểm thử.Tes Plan hướng dẫn suy nghĩ của chúng ta. Nó giống như một cuốn sách quy tắc, cần phải được tuân theo.Các khía cạnh quan trọng như Test Estimation, Test Scope, Chiến lược test được ghi lại trong Test Plan, do đó, nhóm quản lý có thể xem xét và sử dụng lại cho các dự án khác.


*

3. Làm thế nào để lập Test Plan

Như bạn đã biết thì lập Test Plan là nhiệm vụ quan trọng nhất của Quy trình quản lý kiểm thử. Thực hiện theo 7 bước dưới đây để tạo một kế hoạch kiểm tra theo IEEE 829

Analyze the product - Phân tích sản phẩmDesign the Test Strategy - Lập chiến lược kiểm thửDefine the Test Objectives - Xác định mục tiêu kiểm thửDefine Test Criteria - Xác định tiêu chí kiểm thửResource Planning - Hoạch định nguồn lựcPlan Test Environment - Kế hoạch môi trường kiểm thửSchedule & Estimation - Lịch trình & Dự toánDetermine Test Deliverables - Quyết định deliver sản phẩn


*

Step 1_Phân tích sản phẩm (Analyze the product)

Làm thế nào để có thể kiểm thử một sản phẩm mà không có bất kỳ thông tin về nó? Câu trả lời là không thể. Bạn phải tìm hiểu kỹ một sản phẩm trước khi kiểm thử nó. Sản phẩm đang được kiểm thử là trang web ngân hàng Guru99. Bạn nên nghiên cứu khách hàng và người dùng cuối để biết nhu cầu và mong đợi của họ từ ứng dụng

Who will use the website? (Ai sẽ sử dụng trang web?)What is it used for? (Nó được dùng để làm gì?)How will it work? (Nó sẽ làm việc như thế nào?)What are software/ hardware the product uses? (Phần mềm / phần cứng sản phẩm sử dụng là gì?)

Bạn có thể sử dụng phương pháp sau để phân tích trang web


*

Bạn nên xem qua trang web này và xem xét tài liệu sản phẩm. Đánh giá tài liệu sản phẩm giúp bạn hiểu tất cả các tính năng của trang web cũng như cách sử dụng nó. Nếu bạn không rõ ràng về bất kỳ mục nào, bạn có thể confirm với khách hàng, nhà phát triển, nhà thiết kế để có thêm thông tin.

Step 2_Xây dựng chiến lược kiếm thử (Develop Test Strategy) Test Strategy (Chiến lược kiểm thử) là một bước quan trọng trong việc lập Test Plan. Tài liệu Test Strategy, là tài liệu high-level, thường được phát triển bởi Test Manager.

Tài liệu này định nghĩa:

Mục tiêu kiểm thử của dự án và các phương tiện để đạt được chúng

Xác định effort và chi phí kiểm thử. Quay lại dự án của bạn, bạn cần phát triển Test Strategy để kiểm thử trang web ngân hàng đó. Bạn nên làm theo các bước dưới đây :

Step 2.1_Định nghĩa phạm vi của kiểm thử (Define Scope of Testing)

Trước khi bắt đầu bất kỳ hoạt động kiểm thử nào, phải biết phạm vi kiểm thử. Bạn phải suy nghĩ kỹ về nó.

Xác định scope của dự án kiểm thử của bạn là rất quan trọng đối với tất cả các bên liên quan. Một scope chính xác giúp bạn

Step 2.2_Xác định loại kiểm thử (Identify Testing Type)

Testing Type là một quy trình kiểm thử tiêu chuẩn mang lại kết quả kiểm thử dự kiến.

Mỗi Testing Type được xây dựng để xác định một loại lỗi sản phẩm cụ thể. Nhưng, tất cả các Testing Type đều nhằm đạt được một mục tiêu chung. Phát hiện sớm tất cả các lỗi trước khi phát hành sản phẩm cho khách hàng.

Các Testing Type thường được sử dụng được mô tả như hình dưới đây :


Có rất nhiều Testing Type để kiểm thử sản phẩm phần mềm. Nhóm của bạn không thể có đủ effort để xử lý tất cả các loại kiểm thử. Nếu là Test Manager, bạn phải đặt mức độ ưu tiên của các Testing Type.

Testing Type nào nên được tập trung để kiểm thử ứng dụng web?

Testing Type nào nên được bỏ qua để tiết kiệm chi phí?

Bây giờ hãy thực hành với dự án của bạn. Sản phẩm bạn muốn kiểm tra là banking website. Những loại thử nghiệm nào bạn nên tập trung trong trường hợp này? Chọn tất cả những gì áp dụng A) Unit Testing B) API Testing C) Integration Testing D) System Testing E) Install/Uninstall Testing F) Agile testing

Step 2.3_Tạo và lưu trữ tài liệu về Risk & Issues (Document Risk & Issues)

Risk là sự kiện không chắc chắn xảy ra trong tương lai nhưng có xác suất xảy ra và có khả năng thua lỗ. Khi Risk thực sự xảy ra, nó sẽ trở thành issue.

Trong bài viết phân tích Risk và Solution, bạn đã tìm hiểu về phân tích Risk chi tiết và xác định các Risk tiềm ẩn trong dự án.

Trong QA Test Plan, bạn sẽ ghi lại những Risk đó


Step 2.4_Tạo Test Logistics

Trong Test Logistics, Test Manager cần trả lời các câu hỏi sau:

Ai sẽ là người thực hiện kiểm thử (Who will test) ?

Bạn có thể không biết tên chính xác của Tester, nhưng phân loại Tester có thể được xác định.

Để chọn thành viên phù hợp với task cụ thể, bạn phải xem xét nếu khả năng của họ có đủ điều kiện cho task hay không, cũng như ước tính ngân sách dự án. Lựa chọn thành viên sai cho task có thể gây ra các dự án thất bại hay chậm trễ.

Người có các kỹ năng sau là lý tưởng nhất để thực hiện kiểm thử phần mềm:

Trong dự án của bạn, thành viên người mà sẽ chịu trách nhiệm thực hiện kiểm thử là Tester. Dựa trên ngân sách dự án, bạn có thể chọn thành viên trong nội bộ hoặc thuê người ngoài làm Tester.

Xem thêm: Cách Sử Dụng Endnote X7, Tài Liệu Huong Dan Endnote X7, Trích Dẫn Tài Liệu Bằng Endnote X7

Khi nào sẽ thực hiện kiểm thử (When will the test occur) ?

Các hoạt động kiểm thử phải được kết hợp với các hoạt động phát triển liên quan. Bạn sẽ bắt đầu kiểm thử khi bạn có tất cả các mục yêu cầu được hiển thị trong hình dưới đây :

Các thành phần của hệ thống sẽ được kiểm thử (phần cứng, phần mềm, phần mềm trung gian, v.v.) được định nghĩa là "in scope (trong phạm vi)"Các thành phần của hệ thống sẽ không được kiểm thử cũng cần được xác định rõ ràng là "out of scope (ngoài phạm vi)".

Cung cấp cho mọi người một sự chắc chắn và thông tin chính xác về kiểm thử mà các bạn đang làm

Tất cả các thành viên dự án sẽ có một sự hiểu biết rõ ràng về những gì được kiểm thử và những gì không

Làm thế nào để xác định scope kiểm thử của dự án ?

Để xác định scope, bạn phải :

Bây giờ nên xác định rõ ràng "in scope" và "out of scope" của kiểm thử.

Theo thông số kỹ thuật yêu cầu phần mềm, dự án Guru99 Bank chỉ tập trung vào kiểm thử tất cả các chức năng và giao diện bên ngoài của trang web Guru99 Bank (in scope)Kiểm thử nonfunctional như stress, performance hoặc logical database sẽ không được kiểm thử (out of scope) 

Vấn đề khó khăn khi xác định scope của dự án

Khách hàng muốn bạn kiểm thử API. Nhưng ngân sách dự án không cho phép làm như vậy. Trong trường hợp như vậy bạn sẽ làm gì?

Trong trường hợp như vậy, bạn cần thuyết phục khách hàng rằng API Test là extra work và sẽ tiêu tốn resources đáng kể. Cung cấp cho họ dữ liệu hỗ trợ về lập luận của bạn. Nói với họ nếu API Test là "in-scope" thì budget sẽ tăng thêm số tiền XYZ.

Khách hàng đồng ý và theo đó các phạm vi mới, ngoài phạm vi các mục là :

Precise customer requirement (Nắm được yêu cầu chính xác của khách hàng)Project Budget (Ngân sách dự án)Product Specification (Đặc điểm kỹ thuật sản phẩm)Skills & talent of your test team (Kỹ năng & trình độ của nhóm kiểm thử của bạn)Các mục in-scope : Functional Testing, API TestCác mục out of scope : Database Testing, hardware và bất kỳ giao diện bên ngoài nào khácAi sẽ là người thực hiện kiểm thử (Who will test)?Khi nào sẽ thực hiện kiểm thử (When will the test occur)?Khả năng hiểu quan điểm của khách hàngMong muốn chất lượng tốtChú ý đến chi tiếtTinh thần hợp tác tốt

Step 3_Xác định đối tượng kiểm thử (Define Test Objective)

Test Objective (Đối tượng kiểm thử) là mục tiêu tổng thể và thành tích của việc thực hiện kiểm thử. Test Objective là tìm ra càng nhiều lỗi phần mềm càng tốt; đảm bảo rằng phần mềm được kiểm tra không có lỗi trước khi phát hành.

Để xác định Test Objective, bạn nên thực hiện 2 bước sau :

Liệt kê tất cả các tính năng phần mềm (functionality, performance, GUI…) có thể cần kiểm thử.Xác định mục tiêu hoặc mục đích của kiểm thử dựa trên các tính năng trên

Hãy áp dụng các bước này để tìm Test Objective của dự án kiểm thử Guru99 Bank của bạn

Bạn có thể chọn phương thức ‘TOP-DOWN" để tìm các tính năng của trang web có thể cần kiểm thử. Trong phương pháp này, bạn chia nhỏ ứng dụng đang kiểm thử thành component và sub-component.

Trong chủ đề trước, bạn đã phân tích các thông số kỹ thuật yêu cầu và duyệt qua trang web, do đó bạn có thể tạo Mind-Map để tìm các tính năng của trang web như sau :

Hình này thể hiện tất cả các tính năng mà trang web của Guru99 có thể có.

Dựa trên các tính năng trên, bạn có thể xác định Test Objective của dự án Guru99 như sau :

Kiểm tra xem liệu chức năng của trang web Gur99 (Account, Deposit…) có hoạt động như mong đợi mà không có bất kỳ error hoặc bug nào trong môi trường business thực không ?Kiểm tra xem giao diện bên ngoài của trang web như UI có hoạt động như mong đợi và đáp ứng nhu cầu của khách hàng không ?Xác minh usability của trang web. Những chức năng đó có thuận tiện cho người dùng hay không?

Step 4_Xác định tiêu chí kiểm thử (Define Test Criteria)

Test Criteria (Tiêu chí kiểm thử) là một tiêu chuẩn hoặc quy tắc mà theo đó một quy trình kiểm thử hoặc đánh giá kiểm thử có thể được dựa trên. Có 2 loại Test Criteria như sau :

Tiêu chí đình chỉ kiểm thử (Suspension Criteria)

Xác định các tiêu chí đình chỉ kiểm thử quan trọng cho một bài kiểm thử. Nếu các tiêu chí đình chỉ kiểm thử được đáp ứng trong quá trình kiểm thử, chu kỳ kiểm thử hoạt động sẽ bị đình chỉ cho đến khi các tiêu chí được giải quyết.

Tiêu chí kết thúc kiểm thử (Exit Criteria)

Tiêu chí kết thúc kiểm thử xác định các tiêu chí thể hiện sự hoàn thành thành công của giai đoạn kiểm thử. Các tiêu chí kết thúc kiểm thử là kết quả được nhắm đến là mục tiêu của thử nghiệm và là cần thiết trước khi tiến hành giai đoạn phát triển tiếp theo. Ví dụ: 95% của tất cả các trường hợp kiểm thử quan trọng phải Pass. Một số phương pháp xác định tiêu chí kết thúc kiểm thử là bằng cách xác định run rate và pass rate được nhắm mục tiêu.

Run rate là tỷ lệ giữa số các trường hợp kiểm thử được thực hiện / tổng số trường hợp kiểm thử của đặc tả kiểm thử. Ví dụ: đặc tả kỹ thuật kiểm tra có tổng số 120 TCs, nhưng Tester chỉ thực hiện 100 TCs, vì vậy Run rate là 100/120 = 0,83 (83%)Pass rate là tỷ lệ giữa số lượng các trường hợp kiểm thử pass / Số lượng các trường hợp kiểm thử được thực hiện. Ví dụ: trong hơn 100 TCs được thực thi, có 80 TCs đã pass, do đó, Pass rate là 80/100 = 0,8 (80%) 

Dữ liệu này có thể được lấy trong các tài liệu Test Metric.

Run rate bắt buộc là 100% trừ khi có lý do rõ ràng.

Pass rate phụ thuộc vào phạm vi dự án, nhưng đạt được Pass rate cao là một mục tiêu.

Ví dụ: Nhóm của bạn đã thực hiện các kiểm thử. Họ báo cáo kết quả kiểm thử cho bạn và họ muốn bạn xác nhận Exit Criteria.

Trong trường hợp trên, Run rate là bắt buộc là 100%, nhưng nhóm kiểm thử chỉ hoàn thành 90% các trường hợp kiểm thử. Điều đó có nghĩa là Run rate không được thỏa mãn, vì vậy KHÔNG xác nhận Exit Criteria

Step 5_Lập kế hoạch resource (Resource Planning)

Resource plan là một bản tóm tắt chi tiết của tất cả các loại tài nguyên cần thiết để hoàn thành nhiệm vụ của dự án. Resource có thể là con người, thiết bị và vật liệu cần thiết để hoàn thành một dự án

Việc lập Resource plan là yếu tố quan trọng của việc lập Test Plan vì giúp xác định số lượng Resource (nhân viên, thiết bị…) được sử dụng cho dự án. Do đó, Test Manager có thể lập lịch trình & dự toán chính xác cho dự án.