Cách tạo Test plan cho sản phẩm hoặc tính năng mới

Cách tạo test plan cho sản phẩm hoặc tính năng mới

Nếu bạn đã hiểu Test plan là gì, hẳn là bạn sẽ muốn biết cách tạo test plan hoàn chỉnh cho sản phẩm hoặc tính năng mới. Hãy cùng CODII tìm hiểu 5 bước cần thiết cho một test plan hoàn chỉnh.

1. Phân tích sản phẩm hoặc tính năng bạn đang thử nghiệm

Bạn cần phải hiểu rõ về sản phẩm hoặc tính năng trước khi có thể bắt đầu tạo test plan cho sản phẩm hoặc tính năng đó. Ví dụ: giả sử bạn vừa trải qua quá trình thiết kế lại trang web và muốn kiểm tra nó trước khi ra mắt. Bạn sẽ cần những thông tin gì?

Cách tạo test plan đơn giản qua 5 bước

  • Nói chuyện với designer và developer để hiểu phạm vi, mục tiêu và chức năng của trang web.
  • Xem lại tài liệu của dự án (chẳng hạn như Scope Of Work, đề xuất dự án hoặc các task trong công cụ quản lý dự án của bạn).
  • Thực hiện hướng dẫn về sản phẩm (product walkthrough) để hiểu chức năng, user flow và các hạn chế.

Bước này là những gì cung cấp cho bạn bối cảnh để viết phần giới thiệu và mục tiêu cho test plan của bạn và bắt đầu lập kế hoạch các nguồn lực bạn cần để hoàn thành nó.

2. Thiết kế test strategy và các cách tiếp cận mà bạn sẽ sử dụng 

Tiếp theo, đã đến lúc quyết định phạm vi test plan của bạn. Những gì được bao gồm trong phạm vi thử nghiệm của bạn sẽ phụ thuộc vào một số yếu tố ngoài sản phẩm hoặc tính năng. Bạn cần phải tìm hiểu kỹ và suy nghĩ về:

  • Yêu cầu của khách hàng: Người dùng của bạn sẽ sử dụng gì nhiều nhất?
  • Ngân sách và timeline: Bạn có bao nhiêu thời gian và nguồn lực để hoàn thành kiểm thử?
  • Thông số kỹ thuật của sản phẩm: Những phần quan trọng nhất của tính năng này cần được kiểm thử là gì?
  • Khả năng của nhóm: Bạn có chuyên môn kỹ thuật cần thiết để hoàn thành mọi trường hợp kiểm thử không?

Đối với ví dụ thiết kế lại trang web ở trên, chúng mình có thể nói rằng chức năng, trải nghiệm người dùng (UX) và quy trình thanh toán nằm trong phạm vi kiểm thử. Trong khi đó, kiểm thử hiệu suất và cơ sở dữ liệu nằm ngoài phạm vi này.

Bạn cũng có thể giải quyết chúng theo các phương pháp kiểm thử thường được sử dụng, chẳng hạn như:

  • Kiểm thử đơn vị: Kiểm tra phần nhỏ nhất của phần mềm hoặc một tính năng cụ thể.
  • Kiểm thử API: Kiểm thử API của ứng dụng trong nhiều tình huống.
  • Kiểm thử tích hợp: Kiểm thử các mô-đun hoặc tính năng phần mềm như một nhóm.
  • Kiểm thử hệ thống: Kiểm thử toàn bộ hệ thống tích hợp so với các yêu cầu của nó.
  • Kiểm thử cài đặt: Kiểm thử quá trình cài đặt/gỡ cài đặt mà khách hàng của bạn sẽ trải qua.
  • Kiểm thử khả năng tương thích: Kiểm thử phần mềm của bạn trên các phần cứng, hệ điều hành và môi trường khác nhau.
  • Kiểm thử tải: Kiểm thử hiệu suất phần mềm của bạn khi khối lượng công việc tăng lên (hoặc vượt quá điều kiện bình thường).

Quyết định những gì cần kiểm thử và tài liệu hóa chiến lược kiểm thử của bạn là một trong những phần quan trọng nhất trong test plan của bạn. Đừng vội vàng hoàn thành nó một cách nhanh chóng. Hãy dành thời gian để thực sự hiểu các mục tiêu và nhu cầu của bạn, và cân bằng chúng với các nguồn lực bạn có.

3. Xác định các mục tiêu kiểm thử và tiêu chí đạt/không đạt

Một điều quan trọng trong cách tạo test plan là bạn cần xác định được khi nào bài test của bạn được “hoàn thành”. Nói một cách đơn giản, bạn cần xác định được những tiêu chí nào sẽ được coi là đạt chuẩn và tiêu chí nào không.

Cần xác định tiêu chí đạt/không đạt cho các tiêu chí test

Để làm điều này, bạn sẽ muốn xác định các chỉ số hệ thống riêng lẻ mà bạn đang kiểm tra và quyết định từng chỉ số cần đạt được gì. Ví dụ: nếu bạn đang thực hiện kiểm tra hiệu suất, bạn có thể xem xét các chỉ số như:

  • Thời gian phản hồi: Tổng thời gian để gửi yêu cầu và nhận phản hồi.
  • Thời gian chờ: Mất bao lâu để nhận được byte đầu tiên sau khi một yêu cầu được gửi đi.
  • Thời gian tải trung bình: Lượng thời gian trung bình cần để hoàn thành một yêu cầu.
  • Thời gian phản hồi cao điểm: Khoảng thời gian dài nhất cần để thực hiện một yêu cầu.
  • Yêu cầu mỗi giây: Có thể xử lý bao nhiêu yêu cầu.
  • Giao dịch thực hiện thành công/không thành công: Tổng số yêu cầu thành công hoặc không thành công.
  • Sử dụng bộ nhớ: Cần bao nhiêu bộ nhớ để xử lý yêu cầu.

Hãy nhớ rằng, quá trình kiểm thử có thể kéo dài và lặp lại mãi mãi. Vì vậy, bạn cần quyết định tiêu chí “đủ tốt” để đưa phần mềm của bạn đến tay người dùng.

4. Lập kế hoạch cho môi trường thử nghiệm

Kết quả của test plan sẽ phụ thuộc nhiều vào tính năng bạn đang thử nghiệm cũng như môi trường bạn đang thử nghiệm nó. Là một phần của phạm vi kiểm thử, bạn cần xác định phần cứng, phần mềm, hệ điều hành và thiết bị nào sẽ được kiểm thử.

5. Thực hiện test plan và theo dõi tiến độ trong công cụ quản lý dự án 

Khi đã có test plan, bạn cần tuân theo một quy trình cụ thể. Hãy coi đây là Vòng đời của Kiểm thử Phần mềm (Software Testing Life Cycle). Tương tự như Vòng đời phát triển phần mềm, STLC tuân theo từng giai đoạn thử nghiệm và thường có các bước như sau:

  • Yêu cầu / Đánh giá thiết kế
  • Lập kế hoạch kiểm thử
  • Thiết kế thử nghiệm
  • Thiết lập môi trường kiểm thử
  • Thực hiện kiểm thử 
  • Báo cáo kiểm thử

Bài viết này đã giúp bạn hình dung qua về test plan cách tạo test plan. Nếu bạn đã sẵn sàng, hãy bắt tay vào tạo một test plan hoàn chỉnh theo tiêu chuẩn IEEE 829 nhé!



Tìm hiểu về kiểm thử chấp nhận người dùng (UAT)
Kiểm thử chấp nhận người dùng là gì, giai đoạn nào cần kiểm thử UAT, hãy cùng CODII tìm hiểu sau bài viết dưới đây