Nội dung bài học
Nhưng kế hoạch kiểm tra của bạn nên bao gồm những gì? Bạn thực sự cần phải đi sâu đến mức nào để đảm bảo sản phẩm của bạn được bán chạy và người dùng của bạn nhận được những gì họ mong đợi?
Bài viết này Anh Tester sẽ giới thiệu cho bạn những điều cần biết về việc xác định và ghi lại kế hoạch kiểm thử cũng như chọn các chiến lược thử nghiệm phù hợp để đảm bảo người dùng, nhóm phát triển và các bên liên quan của bạn đều hài lòng.
Test plan là gì? (Kế hoạch kiểm tra là gì)
Test plan là một tài liệu chi tiết phác thảo chiến lược thử nghiệm, mục tiêu, nguồn lực cần thiết, lịch trình và tiêu chí thành công để thử nghiệm một tính năng hoặc phần mềm mới cụ thể.
Tất nhiên, mục tiêu chính là phát hiện ra các khiếm khuyết, lỗi và bất kỳ lỗ hổng nào khác có thể khiến phần mềm không hoạt động như dự định hoặc cung cấp trải nghiệm xấu cho người dùng của bạn. Cụ thể hơn, một kế hoạch thử nghiệm đảm bảo phần mềm của bạn:
- Đáp ứng các yêu cầu đã hướng dẫn thiết kế và phát triển của nó (Nói cách khác, nó có làm những gì nó phải làm khi nó được cho là phải làm không? )
- Phản hồi chính xác tất cả các loại đầu vào
- Đáp ứng các tiêu chuẩn hiệu suất mà bạn đã vạch ra và có thể được sử dụng như dự định
- Có thể được cài đặt và chạy trong tất cả các môi trường dự định
- Đạt được kết quả mà bạn và các bên liên quan của bạn đạt được
Trong khi những tiêu chí này nghe có vẻ giống như các tiêu chí khá đơn giản, nhưng trên thực tế, chúng hiếm khi xảy ra. Vấn đề là "thử nghiệm" có nghĩa là bạn đang thử nghiệm một cách tự nhiên đối với một thứ gì đó. Trong hầu hết các trường hợp, điều này có nghĩa là thông số kỹ thuật và tiêu chí thành công mà bạn đưa ra trong SOW hoặc tài liệu lập kế hoạch của mình. (Nhưng cũng có thể bao gồm những thứ như sản phẩm có thể so sánh, phiên bản trước đây, kỳ vọng của người dùng, tiêu chuẩn hoặc luật).
Gần như không thể kiểm tra mọi tình huống, môi trường hoặc trường hợp sử dụng mà phần mềm của bạn sẽ gặp phải trong vòng đời của nó. Thay vào đó, lỗi phần mềm, lỗi và khiếm khuyết có thể xuất hiện từ:
- Lỗi mã hóa - tức là lỗi
- Khoảng trống yêu cầu - tức là các yêu cầu không được công nhận hoặc bị bỏ qua như các trường hợp cạnh, khả năng mở rộng hoặc thậm chí bảo mật.
- Môi trường thay đổi - tức là phần mềm, phần cứng mới, các thay đổi trong dữ liệu nguồn…
Điều này làm cho việc viết một kế hoạch kiểm tra rõ ràng nhưng toàn diện là một sự cân bằng khó khăn. Bạn muốn bao gồm càng nhiều chi tiết càng tốt để đảm bảo rằng bạn không bỏ sót bất kỳ lỗi rõ ràng nào. Tuy nhiên, bạn cũng không muốn khiến nhóm của mình chìm trong các nhiệm vụ thử nghiệm, trì hoãn việc phát hành hoặc thêm các lỗi mới từ “các bản sửa lỗi” của bạn.
Những nội dung chính trong một test plan?
Mỗi sản phẩm và tính năng sẽ có các tiêu chí, chiến lược và nhu cầu thử nghiệm cụ thể của riêng nó. Ngoài ra, mục tiêu của bài kiểm tra của bạn sẽ thay đổi cách bạn tiếp cận nó. Ví dụ: Kiểm tra sự chấp nhận của người dùng (UAT) hoàn toàn khác với kiểm tra căng thẳng và tải và kế hoạch của bạn sẽ cần được điều chỉnh cho phù hợp với mục tiêu cuối cùng của bạn.
Tuy nhiên, điều này không có nghĩa là bạn muốn bắt đầu lại từ đầu mỗi khi bạn đang thử nghiệm một phần mềm mới. Tạo các mẫu kế hoạch thử nghiệm khác nhau cho các sản phẩm khác nhau là một cách tuyệt vời để nhanh chóng hướng dẫn cách tiếp cận của bạn để thử nghiệm các bản phát hành, cập nhật và tính năng sản phẩm mới.
Vì vậy, bạn nên (hoặc có thể ) bao gồm những gì trong kế hoạch thử nghiệm của mình? Nói chung, có một số lĩnh vực chính bạn sẽ muốn đưa vào kế hoạch kiểm tra của mình, chúng sẽ đóng vai trò là nền tảng của tài liệu kế hoạch kiểm tra của bạn.
1. Mức độ phù hợp: Chính xác thì bạn đang thử nghiệm điều gì?
Như chúng tôi đã nói trước đây, việc tạo một kế hoạch kiểm tra là tất cả về sự cân bằng. Bạn muốn toàn diện, nhưng không áp đảo, có nghĩa là phải biết cụ thể về những gì sẽ (và sẽ không) được đưa vào kế hoạch thử nghiệm.
Sau phần giới thiệu ngắn gọn nêu bật các mục tiêu kế hoạch thử nghiệm , phạm vi cấp cao và lịch trình, bạn cần xác định những gì bạn sẽ hoặc sẽ không thử nghiệm.
Đây là phạm vi kiểm tra của bạn và nó có thể nhanh chóng vượt khỏi tầm tay nếu bạn không dành thời gian để tìm hiểu cụ thể về nó và trả lời cả những gì bạn sẽ kiểm tra và lý do bạn kiểm tra nó.
- Bạn sẽ thực hiện những bài kiểm tra nào?
- Tại sao bạn lại chọn những cái này (chứ không phải cái khác)?
Mọi người cần ở trên cùng một trang với các tiêu chí và phạm vi kiểm tra. Như một phương pháp hay nhất, hãy đảm bảo rằng bạn sử dụng tiêu chuẩn ngành hoặc ít nhất là các tiêu chuẩn và thuật ngữ đã được thống nhất để mô tả các bài kiểm tra của bạn và tại sao chúng được (hoặc không) hoàn thành. Bằng cách này, không có vùng xám hoặc nhầm lẫn về những gì bạn đã thử nghiệm.
2. Phương pháp: Bạn sẽ thực hiện những bài kiểm tra này như thế nào?
Tiếp theo, bạn cần giải thích rõ ràng chiến lược kiểm tra của bạn là gì. Đi vào càng nhiều chi tiết càng tốt.
- Các bài kiểm tra của bạn sẽ tuân theo những quy tắc nào?
- Bạn sẽ thu thập những chỉ số nào và ở cấp độ nào?
- Bạn sẽ thử nghiệm bao nhiêu cấu hình hoặc môi trường khác nhau ?
- Có bất kỳ yêu cầu hoặc thủ tục đặc biệt nào bạn cần để kiểm tra không?
Bạn cũng cần biết khi nào thử nghiệm của bạn đã thành công. Nói cách khác, tiêu chí đạt / không đạt cho mỗi bài kiểm tra là gì?
Đây không phải là tiêu chí duy nhất bạn cần biết. Có một số tình huống phổ biến khác mà bạn cần phác thảo trong kế hoạch kiểm tra của mình, bao gồm:
- Tiêu chí dừng: Khi nào thì có thể dừng thử nghiệm một tính năng và cho rằng tính năng đó “thành công” trong việc thực hiện những gì nó đặt ra?
- Tiêu chí đình chỉ: Khi nào bạn nên tạm dừng một bài kiểm tra? Có ngưỡng lỗi nào mà bạn nên dừng thử nghiệm và bắt đầu tìm kiếm giải pháp không? Các bước để đóng nó lại và ghi lại những gì đã được thực hiện cho đến nay là gì?
- Yêu cầu tiếp tục: Làm thế nào để bạn biết khi nào cần tiếp tục kiểm tra bị tạm dừng? Các bước để xem lại những gì đã được thực hiện và tiếp tục là gì?
Vào thời điểm này, bạn cũng nên liệt kê các giả định và rủi ro của mình. Nói cách khác, bạn giả định điều gì sẽ xảy ra và một số rủi ro bạn sẽ gặp phải trong quá trình thử nghiệm là gì?
Cuối cùng, bạn cần phác thảo nhu cầu tài nguyên và lịch trình cho dự án thử nghiệm của mình. Ai chịu trách nhiệm kiểm tra và những gì các nguồn lực họ cần (cả kỹ thuật và con người)? Việc kiểm tra sẽ diễn ra khi nào và trong bao lâu?
3. Trách nhiệm: Kết quả mong muốn của bạn là gì?
Những gì bạn yêu cầu phân phối thử nghiệm là gì? Điều này có nghĩa là dữ liệu bạn muốn thu thập, cách bạn sẽ biên dịch chúng trong báo cáo cũng như các vấn đề và nhiệm vụ sẽ được chuyển lại cho nhóm phát triển.
Để đảm bảo không có gì bị bỏ sót, mỗi thử nghiệm có thể phân phối nên được giao cho một người cụ thể trong nhóm của bạn trong một phần về vai trò và trách nhiệm.
Điều quan trọng cần nhớ là đây chỉ là một khuôn khổ cơ bản về những gì cần đưa vào một kế hoạch kiểm tra. Theo thời gian, bạn sẽ tạo thư viện mẫu kế hoạch thử nghiệm của riêng mình, sẽ dùng làm hướng dẫn cho các bản phát hành, cập nhật và tính năng sản phẩm mới.
==> Tải xuống Test Plan Template miễn phí
Tìm hiểu: Cách tạo Test Plan cho sản phẩm hoặc tính năng mới
Zalo
Anh Tester
facebook.com/anhtester
Đường dẫu khó chân vẫn cần bước đi
Đời dẫu khổ tâm vẫn cần nghĩ thấu