.st0{fill:#FFFFFF;}

7 bộ Test Plan mẫu dành cho Test Manager 

 May 8, 2019

By  

Test Plan là gì?

Test plan chính là tài liệu tổng quan về việc kiểm thử 1 project đặc tả: phạm vi dự án, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực cần có, các tính năng cần được test và không cần phải test, các công cụ và môi trường test cần có. Test plan là cơ sở để test các sản phẩm/ phần mềm trong một dự án.

Các loại Test plan

  • Master Test Plan
  • Testing Level Specific Test Plan
  • Testing Type Specific Test Plan

Các định dạng và nội dung của test plan là khác nhau tùy vào các quy trình , tiêu chuẩn và các công cụ quản lý lỗi. Tuy nhiên định dạng sau dựa trên tiêu chuẩn IEEE cho test plan cung cấp một cách đầy đủ và tóm tắt những gì nên đưa và có thể đưa vào.

test plan

Một số mục trong Test plan

Test plan cung cấp cái nhìn tổng quan nhất khi kiểm thử 1 project. Sau đây là 1 số hạng mục thường có trong một Test plan, đôi khi số lượng mục cần xác định còn phụ thuộc vào quy mô dự án:

  • Tiêu đề
  • Version release
  • Lưu lại quá trình hiệu chỉnh tài liệu như tác giả, ngày cập nhật, duyệt
  • Mục lục
  • Mục đích của tài liệu, ý kiến chung
  • Mục tiêu của chi phí kiểm thử (test)
  • Giới thiệu tổng quan về sản phẩm
  • Danh sách tài liệu liên quan như spec, tài liệu thiết kế, các kế hoạch test khác,…
  • Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ
  • Nguồn gốc của các sự thay đổi
  • Assumptions and dependencies
  • Phân tích rủi ro của dự án
  • Các vấn đề ưu tiên và tập trung test
  • Phạm vi và giới hạn test -Test phác thảo – phân tích cách tiếp cận theo loại test, tính năng, chức năng, quy trình, hệ thống, mô đun, v.v … khi áp dụng
  • Phân tích giá trị tương đương đầu vào, phân tích giá trị biên, các trường hợp lỗi
  • Môi trường test – Phần cứng, hệ điều hành, phần mềm yêu cầu khác, cấu hình dữ liệu, giao diện với các hệ thống khác
  • Phân tích tính hợp lệ của môi trường test – sự khác nhau giữa các hệ thống test – product và ảnh hưởng của chúng đối với tính hợp lệ của việc test.
  • Các vấn đề thiết lập môi trường và cấu hình
  • Quá trình chạy phần mềm
  • Kiểm tra yêu cầu thiết lập dữ liệu
  • Yêu cầu thiết lập cơ sở dữ liệu
  • Test tự động – giải thích và tổng quan
  • Các công cụ test được sử dụng, bao gồm các version, bản vá lỗi…
  • Các qui trình bảo trì và quản lý version của test script/test code
  • Theo dõi và giải quyết vấn đề – Các công cụ và qui trình
  • Các thước đo về test sản phẩm được sử dụng
  • Báo cáo các yêu cầu và khả năng giao test
  • Điều kiện đầu vào và đầu ra của phần mềm
  • Giai đoạn và điều kiện test ban đầu
  • Điều kiện dừng test và test lại
  • Sự bố trí nhân sự
  • Những người cần training trước khi tham gia
  • Nơi test
  • Các tổ chức test bên ngoài sẽ sử dụng và mục đích, trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợp tác của họ
  • Các vấn đề độc quyền thích hợp, phân loại, bảo mật và bản quyền.
  • Các vấn đề mở
  • Phụ lục – bảng chú giải, các từ viết tắt …

Những câu hỏi trong khi tạo Test plan

Câu hỏi 1: End user muốn gì?

  • Để Tester có thể chắc chắn rằng phần mềm thực hiện được những gì như mong muốn, Tester phải hiểu được “phần mềm được định nghĩa làm gì?”. Trong những ngày phát triền đầu tiên, điều này thực sự cần xác định các chức năng quan trọng là gì. Nhưng ngày này, End user thường có rất nhiều yêu cầu. Có rất nhiều yếu tố khác nhau để thiết kế được một phần mềm thành công và Tester cần phải quan tâm đến những điều này ngay đầu để tạo ra được những test case cần thiết.
  • Điều này thực sự quan trọng trong pha kiểm thử chấp nhận người dùng (UAT), khi khách hàng thực thử nghiệm, tiếp xúc với phần mềm. Theo chuyên gia ngành Scott Barber, mục tiêu của UAT có thể tóm tắt lại bằng câu hỏi đơn giản: “Những người sử dụng hệ thống có đồng ý rằng chúng tôi đã đáp ứng đúng các yêu cầu chúng tôi đưa ra chưa?”
  • Nếu Tester không nhận thức điều này đầu tiên, ta sẽ không thể tạo ra được những test case trả lời được câu hỏi này.

Câu hỏi 2: Kiểm thử có bao nhiêu thời gian?

  • Một người quản lý kiểm thử phải biết rằng mình đang cố gắng để đặt được điều gì và phải tích cực tham gia vào quá trình xây dựng timeline cho 1 dự án. Điều này khó hơn việc chỉ yêu cầu deadline chính xác nhiều. Thay vào đó, nó liên quan đến sự xem xét thận trọng đối với những gì có thể thực hiện thành công được trong một khoảng thời gian nhất định. Nhanh chóng để đạt được thời gian lý tưởng đưa ra thị trường, nhưng điều đó không mang nghĩa là công việc quản lý QA làm qua loa.
  • Một trong những lợi ích của xu hướng Agile là nó có thể loại bỏ các nhược điểm của mô hình truyền thống. Phương pháp phát triền gồm nhiều thứ hơn, có nghĩa là Tester liên quan nhiều hơn đến quá trình đưa ra quyết định, một trong số đó là thiết lập được một timeline của project. Khi mà Tester biết tốn các bước xây dựng tốn bao nhiêu thời gian, chúng ta có thể phản ứng nhanh hơn trong mô hình Agile, hay có thể điều chỉnh sách lược để làm quen quy trình nhanh. Ví dụ các phương pháp luận kiểm thử Agile có thể đảm bảo rằng mọi iteration mới được kiểm tra đúng cách.

Câu hỏi 3: Công cụ nào phù hợp với việc kiểm thử?

  • Câu hỏi cuối cùng cũng không kém phần quan trọng. Tester cần kiểm tra những công cụ có sẵn/phù hợp để giúp Tester đảm bảo được đầy đủ yêu cầu của người dùng trong khoảng thời gian xây dựng Project. Ví dụ, trong môi trường Agile hoặc tích hợp liên tục, Tester sẽ cần một công cụ quản lý kiểm thử vừa có được Dashboard đơn giản dễ hiểu vừa có hỗ trợ theo dõi trong thời gian thực. Điều này giúp mọi người luôn đồng bộ tình hình trong mọi thời điểm.
  • Tự động tích hợp cũng cực kỳ có ích, vì nó cho phép tự động hóa các test case có thể tốn thời gian và gây ra nhiều lỗi con người được lặp đi lặp lại liên tục. Các test hồi quy đặc biệt là những ứng viên lý tưởng của việc tự động hóa. Những cases này sẽ được chạy với mỗi iteration mới để chắc chắn không có gì bị ảnh hưởng gây lỗi trong quá trình build bởi những thay đổi gần nhất.

Vui lòng download bộ Test Plan mẫu được chúng tôi tổng hợp lại bên dưới, nếu bạn muốn đóng góp bộ Test Plan của bạn, hãy liên hệ qua email: [email protected].

related posts:




{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}