Test plan là gì? Cách viết test plan hiệu quả trong 8 bước

Để quá trình kiểm thử đi theo đúng hướng đã định ra thì Test plan có vai trò rất quan trọng. Công việc Kiểm thử đòi hỏi người thực hiện phải có kỹ thuật, kinh nghiệm và tiến hành theo quy trình định trước. Bất kỳ Tester nào cũng cần hiểu rõ khái niệm Test plan và biết cách xây dựng kế hoạch chi tiết và hiệu quả. Theo dõi bài viết sau đây của Testerpro.vn để hiểu rõ hơn nhé!

Test plan là gì?

• Test plan là tài liệu chi tiết mô tả chiến lược kiểm thử, mục tiêu, lịch trình và ước tính cùng khả năng cung cấp các nguồn lực cho kiểm thử (nhân lực, phần mềm, phần cứng). Nói cách khác đây là tài liệu giúp Tester xác định nỗ lực cần thiết để kiểm chứng chất lượng của phần mềm đang được kiểm thử.

• Nó có vai trò như một bản kế hoạch chi tiết để thực hiện các hoạt động kiểm thử phần mềm. Hay quy trình xác định được quản lý và giám sát từng bước bởi Test Manager.

• Test plan là tài liệu bắt buộc đối với bất kỳ quy trình kiểm thử phần mềm nào. Bởi nó chính là chiếc la bàn giúp Tester định hướng đường đi của mình trong suốt quá trình kiểm thử.

Tầm quan trọng của test plan

Việc lập test plan mang đến nhiều lợi ích:

• Giúp những người ngoài nhóm kiểm thử: nhà phát triển, quản lý doanh nghiệp hay khách hàng có thể hiểu chi tiết về quá trình kiểm thử.

• Test plan định hướng suy nghĩ của bạn và nó giống như quyển sách với nội dụng về các quy tắc, điều luật cần phải tuân theo để đạt được hiệu cao trong công việc.

• Các yếu tố quan trọng được lưu lại trong test plan gồm: Test Estimation, Test Scope, Chiến lược test. Vì vậy nó có thể được xem xét lại bởi nhóm quản lý có thể xem xét và tái sử dụng cho các dự án khác.

Cách viết test plan trong 8 bước

Bước 1: Phân tích sản phẩm (Analyze the product)

Đây là bước đầu tiên nhưng rất quan trọng trong quá trình kiểm thử. Việc nghiên cứu và phân tích sản phẩm sẽ hạn chế được tối thiểu những sai xót không đáng có xảy ra. Analyze the product quyết định cho các tiến trình kiếm thử tiếp theo. Để phân tích sản phẩm thì người lập test plan phải trả lời được những câu hỏi sau đây:

• Đối tượng sử dụng sản phẩm này là ai?

• Mục đích của sản phẩm này dùng để làm 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?

Bước 2: Lập chiến lược kiểm thử (Develop Test Strategy)

Define Scope of Testing ( Xác định phạm vi kiểm thử)

Một Scope (phạm vi kiểm thử) đúng sẽ giúp đội nhóm có được những thông tin chính xác về quá trình kiểm thử. Đồng thời họ sẽ biết được những nội dung nào được kiểm thử (in-scope) và những gì không (out of scope).

Phần quy trình xác định phạm vi kiểm thử trong việc xây dựng Test plan gồm 4 giai đoạn:

• Precise customer requirement: Tại đây bạn cần nắm được yêu cầu chính xác của khách hàng

• Project Budget: Tiến hành thiết lập ngân sách dự án.

• Product Specification: Nằm được đặc điểm kỹ thuật sản phẩm

• Skills & talent of your test team: Kỹ năng & tài năng của nhóm kiểm thử của bạn

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

Mỗi testing type được xây dựng để tìm ra một loại Bug cụ thể. Tuy nhiên tất cả các loại kiểm thử đều hướng tới mục tiêu chung là phát hiện sớm các lỗi trước khi phát hành sản phẩm cho khách hàng. Tùy theo loại sản phẩm hay thuộc tính ở giai đoạn test mà người tạo plan sẽ chọn testing type khác nhau.

Là người quản lý kiểm thử thì bạn cần phải cân nhắc mức độ ưu tiên của các loại kiểm thử. Loại kiểm thử nào được tập trung để kiểm thử ứng dụng web hoặc loại nào nên bỏ qua để tiết kiệm chi phí.

Document Risk & Issues (Rủi ro và vấn đề về Tài liệu)

Risk là sự kiện có xác suất xảy ra trong tương lai rất thấp và có khả năng thua lỗ. Khi Risk xảy ra thì nó sẽ trở thành issue. Ở QA Test Plan thì bạn sẽ ghi lại những rủi ro đó:

Tạo Test Logistics

Ở Test Logistics thì người quản lý kiểm thử cần trả lời các câu hỏi:

• Who will test ? (Ai là người thực hiện kiểm thử): Để lựa chọn được thành viên phù hợp bạn cần xem xét năng lực của họ có đáp ứng được điều kiện cho nhiệm vụ cùng ước tính ngân sách dự án. Chọn sai thành viên cho nhiệm vụ sẽ gây ra các dự án thất bại hay chậm trễ.  Người thực hiện kiểm thử cần có những kỹ năng sau: hiểu được quan điểm của khách, mong muốn chất lượng tốt. Chú ý đến các chi tiết và có sự hợp tác. Trong dự án thì người chịu trách nhiệm kiểm thử là Tester và dựa trên ngân sách dự án thì bạn có thể chọn thành viên trong nội bộ hoặc outsource Tester.

• When will the test occur? (Khi nào sẽ thực hiện kiểm thử): Các hoạt động kiểm thử cần phải được kết hợp với các hoạt động phát triển liên quan. Bạn hãy bắt đầu kiểm thử khi các mục yêu cầu thỏa mãn 3 yếu tố: tài liệu kiểm thử, nhân lực cùng môi trường Test.

Bước 3: Xác định mục tiêu kiểm thử (Define Test Objective)

• Test Objective (Đối tượng kiểm thử) là mục tiêu tổng thể của toàn bộ dự án. Đó là tìm ra càng nhiều lỗi của phần mềm càng nhiều càng tốt để đảm bảo rằng phần mềm không có lỗi trước khi phát hành. Việc xác định đúng mục tiêu sẽ giúp cho việc kiểm thử sản phẩm diễn ra nhanh chóng và suôn sẻ hơn.

• Nếu muốn xác định Test Objective thì bạn cần liệt kê các tính năng phần mềm (functionality, performance, GUI…) có thể cần kiểm thử. Từ đó xác định mục tiêu, mục đích của kiểm thử dựa trên các tính năng trên.

Bước 4: Xác định tiêu chí kiểm thử (Define Test Criteria)

Tiêu chuẩn hoặc quy tắc để quá trình kiểm thử sản phẩm diễn ra đúng chuẩn đó chính là Test Criteria (Tiêu chí kiểm thử). Gồm có 2 loại tiêu chí chính:

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

Đây là tiêu chí phát hiện ra bugs trong quá trình kiểm thử. Nếu trong quá trình test xuất hiện Suspension Criteria thì chu kỳ kiểm thử hoạt động sẽ bị ngưng lại cho đến khi các tiêu chí được xử lý.

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

Nhằm mục đích 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ử. Exit Criteria là kết quả được hướng tới là mục tiêu của test để chuyển sang giai đoạn phát triển tiếp theo.  Cách thức giúp xác định tiêu chí kết thúc của test dựa trên 2 tỷ lệ:

• Run rate là tỉ số giữa số trường hợp đã kiểm thử trên tổng số trường hợp kiểm thử trên kế hoạch. Chỉ số này bắt buộc là 100%

• Còn Pass rate là tỷ số giữa số các trường hợp kiểm thử pass trên số trường hợp được thực hiện kiểm thử. Yếu tố này phụ thuộc vào phạm vi dự án và Pass rate càng cao càng tốt.

Bước 5: Hoạch định nguồn lực (Resource Planning)

Ở bất cứ dự án nào thì việc hoạch định nguồn lực là điều cần thiết bởi nguồn lực luôn có giới hạn và riêng biệt dựa theo từng Project. Các nhà quản lý kiểm thử nên liệt kê và xác định rõ nhân lực cùng tài nguyên hệ thống cho dự án để lên kế hoạch để chạy, hoàn thành dự án hợp lý.

Bước 6: Lập kế hoạch môi trường kiểm thử (Plan Test Environment)

Test Environment là một thiết lập của phần mềm và phần cứng để nhóm test sẽ tiến hành các trường hợp kiểm thử. Môi trường test bao gồm: người dùng cuối, môi trường kinh doanh, môi trường chạy UI, máy chủ,… Để thiết lập Test Environment thì bạn cần có sự hợp tác chặt chẽ giữa Test Team và Development Team. Môi trường kiểm thử lý tưởng sẽ cho phép Tester giám sát mọi biến động của phần mềm trong điều kiện sử dụng thực tế.

Bước 7: Lập lịch trình và dự toán (Schedule & Estimation)

Ở bước này bạn cần thiết lập project schedule vững chắc trong Test Planning. Bạn có thể phân chia cả quá trình thành những nhiệm vụ (task) nhỏ. Để Test Manager dễ dàng phân bổ thời gian cùng nhiệm chi tiết cho từng task theo dõi tiến độ dự án và kiểm soát chi phí. Để tạo project schedule, người quản lý kiểm thử cần các yếu tố đầu vào gồm:

• Employee và project deadline: Thể hiện ở ngày làm việc, deadline của dự án cùng tài nguyên sẵn có là những yếu tố ảnh hưởng đến lịch trình.

• Project estimation (Dự toán công trình): Dựa vào estimation, Test Manager sẽ biết được thời gian hoàn thành dự án để xây dựng project schedule phù hợp.

• Project Risk(Rủi ro dự án): Việc hiểu được rủi ro giúp Test Manager thêm đủ thời gian vào project schedule để đưa ra phương án xử lý hiệu quả

Bước 8: Xác định phân phối thử nghiệm (Determine Test Deliverables)

Sản phẩm hoàn chỉnh đã trải qua quá trình kiểm thử là có thể phát hành. Khi tiến hành kiểm thử phần mềm thì các phân phối thử nghiệm là danh sách tất cả các tài liệu, công cụ. Cùng các hiện vật được khai thác để phát triển và dùng để hỗ trợ quá trình Test. Các loại thử nghiệm có thể phát hành gồm:

• Phân phối trước khi thử nghiệm gồm tài liệu kế hoạch kiểm tra và bộ thử nghiệm các trường hợp thử nghiệm.

• Phân phối trong quá trình test: tập lệnh thử nghiệm, dữ liệu test, ma trận truy xuất nguồn gốc cùng nhật ký thực thi và lỗi.

• Phân phối sau thử nghiệm: Kết quả thử nghiệm và báo cáo, quy trình cài đặt, ghi chú phát hành, báo cáo sai xót.

Ví dụ về testplan mẫu

Giới thiệu

Test plan được tạo để truyền đạt phương pháp kiểm thử cho các thành viên trong nhóm. Nó bao gồm các mục tiêu, phạm vi, lịch trình, rủi ro và cách tiếp cận. Tài liệu này sẽ xác định rõ ràng những sản phẩm kiểm thử sẽ là gì và những gì được coi là trong và ngoài phạm vi.

1.1 Mục tiêu

Test Case Tamer là một công cụ quản lý kiểm thử dựa trên web được sử dụng để tạo và lưu trữ các bài kiểm thử cũng như kết quả thực hiện. Công cụ này là một sản phẩm mới được viết bằng Ruby on Rails sử dụng cơ sở dữ liệu MySQL. Nhóm kiểm thử chịu trách nhiệm kiểm thử sản phẩm và đảm bảo nó đáp ứng nhu cầu. Nhóm kiểm thử đóng vài trò vừa là khách hàng vừa là tester trong dự án này.

Giai đoạn 1 của dự án sẽ cung cấp TCT (Test Case Tamer) với chức năng tạo và lưu trữ các bài kiểm thử thủ công. Điều này sẽ cho phép nhóm kiểm thử đầu chuyển các kiểm thử sang hệ thống mới. 

1.2 Thành viên tham gia

Mục tiêu

Giai đoạn ban đầu sẽ bao gồm tất cả các yêu cầu ‘phải có’. Tất cả những yêu cầu này và bất kỳ yêu cầu nào khác được đưa vào đều phải được kiểm thử. Vào cuối Giai đoạn 1, tester phải :

• Tạo kiểm thử thủ công với các bước cần thiết
• Lưu trữ
• Truy xuất và có khả năng xem lại khi chạy kiểm thử
• Nhập kết quả và nhận xét phù hợp
• Xem kết quả

Khi nhóm làm việc với sản phẩm, họ sẽ xác định nhu cầu cho giai đoạn thứ hai.
Load testing sẽ không được coi là một phần của dự án này vì cơ sở người dùng đã được biết và không phải là vấn đề.
Viết lại, di chuyển hoặc chuyển các test case hiện có từ các tài liệu Word không được coi là một phần của dự án này.

Giả định và vấn đề

3.1 Giả định

Phần này liệt kê các giả định cụ thể cho dự án này.

• Việc phân phối sản phẩm ở định dạng mà nhóm kiểm thử có thể thực hiện nó trong CVS.

3.2 Rủi ro

Các rủi ro sau đây đã được xác định và hành động thích hợp được xác định để giảm thiểu tác động của chúng đối với dự án. Tác động (hoặc mức độ nghiêm trọng) của rủi ro dựa trên việc dự án sẽ bị ảnh hưởng như thế nào nếu xảy ra. Trigger là cột mốc hoặc sự kiện nào sẽ khiến rủi ro trở thành vấn đề cần xử lý.

	Rủi ro	Mức độ	Trigger	Kế hoạch giảm thiểu
1	Scope Creep – khi tester trở nên quen thuộc hơn với công cụ, họ sẽ muốn có nhiều chức năng hơn	Cao	Delay ngày thực hiện	Mỗi lần lặp lại, chức năng sẽ được giám sát chặt chẽ. Các ưu tiên sẽ được thiết lập và thảo luận bởi các bên liên quan. Vì trình điều khiển là chức năng chứ không phải thời gian, nên có thể cần phải lùi ngày.
2	Các thay đổi đối với chức năng có thể phủ nhận các bài kiểm thử đã được viết và chúng ta có thể mất các test case đã viết	Cao – đúng tiến độ và chất lượng	Mất hết test case	Xuất dữ liệu trước khi nâng cấp, giảm thiểu khi cần thiết và nhập lại sau khi nâng cấp.
3	Không thể cung cấp sản phẩm hàng tuần vì nhà phát triển làm việc ngoài trang web	Trung bình	Sản phẩm không được giao đúng tiến độ
4

Phương pháp kiểm thử

Dự án đang sử dụng một cách tiếp cận linh hoạt, với các lần lặp lại hàng tuần. Vào cuối mỗi tuần, các yêu cầu được xác định cho lần lặp đó sẽ được chuyển đến nhóm và sẽ được kiểm thử.

Exploratory testing phá sẽ đóng vai trò quan trọng trong quá trình kiểm thử vì nhóm chưa bao giờ sử dụng loại công cụ này và sẽ học hỏi trong quá trình thực hiện. Các kiểm thử cho chức năng theo kế hoạch sẽ được tạo và thêm vào TCT khi chúng ta nhận được các lần lặp lại của sản phẩm.

Test Automation

Kiểm thử đơn vị tự động là một phần của quá trình phát triển, nhưng không có kiểm thử chức năng tự động nào được lên kế hoạch tại thời điểm này.

Môi trường kiểm thử

Cần có một máy chủ mới cho máy chủ web, ứng dụng và cơ sở dữ liệu.

Cột mốc / Sản phẩm bàn giao

6.1 Test Schedule

Nhiệm vụ	Bắt đầu	Kết thúc	Nỗ lực	Nhận xét
Kế hoạch kiểm thử
Xem lại tài liệu yêu cầu			2đ
Tạo ước tính kiểm thử ban đầu			1đ
Nhân viên và đào tạo tài liệu kiểm thử mới
Lần đầu tiên triển khai môi trường kiểm thử QA
Kiểm thử chức năng – Lặp lại lần 1
Lặp lại lần 2 – Triển khai môi trường kiểm thử QA
Kiểm thử chức năng – Lặp lại lần 2
Kiểm thử hệ thống
Kiểm thử hồi quy – Regression Testing
UAT
Giải quyết các lỗi cuối và kiểm thử bản build cuối cùng
Triển khai vào môi trường Staging
Kiểm thử hiệu năng
Phát hành để sản xuất

6.2 Bàn giao

Bàn giao	Tới	Ngày
Test Plan	Quản lý dự án, QA Director, Nhóm kiểm thử
Traceability Matrix – Ma trận truy xuất nguồn gốc	Quản lý dự án, QA Director
Kết quả kiểm thử	Quản lý dự án
Báo cáo tình trạng kiểm thử	QA manager, QA Director
Số liệu	Tất cả thành viên trong nhóm

 

Đến đây thì bạn đọc đã hiểu rõ hơn về test plan và cách thức xây dựng kế hoạch thử nghiệm hiệu quả. Hy vọng rằng bài viết đã cung cấp những thông tin hữu ích và thiết thực để hiểu rõ hơn về nghề nghiệp bạn đang theo đuổi. Nếu có bất cứ vấn đề gì thắc mắc hãy để lại bình luận phía dưới, Testerpro sẽ giải đáp ngay lập tức. 

Nhận ngay ưu đãi lên đến 20 % học phí khi đăng ký Khóa học tester trong tháng này!