Software Testing - Documentation

• Tài liệu test là các tài liệu cần phát triển trước và trong quá trình kiểm thử.

• Tài liệu kiểm thử phần mềm giúp trong việc ước lượng effort cần thiết, phạm vi kiểm tra, theo dõi yêu cầu, vv. Phần này mô tả một số tài liệu thường được sử dụng liên quan đến kiểm thử phần mềm, ví dụ như:

  • Test Plan
  • Test Scenario
  • Test Case
  • Traceability Matrix

I. Test plan

• Một kế hoạch kiểm thử vạch ra các chiến lược sẽ được sử dụng để kiểm tra một ứng dụng, các resoures sẽ được sử dụng, môi trường kiểm thử, trong đó kiểm tra sẽ được thực hiện, và những hạn chế của việc kiểm tra và tiến độ của các hoạt động kiểm thử. Thường là Quality Assurance Team Lead sẽ chịu trách nhiệm viết một kế hoạch kiểm thử.

• Một kế hoạch kiểm thử bao gồm:

  • Giới thiệu về các tài liệu kế hoạch kiểm thử.
  • Các giả định trong khi kiểm thử các ứng dụng.
  • Danh sách các testcase trong khi kiểm thử ứng dụng.
  • Danh sách các chức năng cần kiểm tra.
  • Những phương pháp cần sử dụng trong khi kiểm thử phần mềm.
  • Danh sách trường hợp đặc biệt cần kiểm tra.
  • Những nguồn lực được phân bố để kiểm thử ứng dụng.
  • Những rủi ro có thể phát sinh trong quá trình kiểm thử.
  • Lịch trình cụ thể cho các task và các mốc quan trọng cần đạt được.

II. Test Scenario

• Kịch bản test được sử dụng để đảm bảo rằng tất cả các luồng quy trình được kiểm tra từ đầu đến cuối. Một ứng dụng có ít nhất một kích bản test cho hàng trăm trường hợp tùy thuộc vào độ lớn và phức tạp của dự án.

• Các từ 'kịch bản thử nghiệm' và 'test' được sử dụng thay thế cho nhau, tuy nhiên một kịch bản thử nghiệm có nhiều bước, trong khi một trường hợp thử nghiệm có một bước duy nhất. Nhìn từ góc độ này, kịch bản thử nghiệm là trường hợp thử nghiệm, nhưng họ bao gồm một số trường hợp thử nghiệm và trình tự mà họ cần phải được thực thi.

III. Testcase

• Testcase bao gồm một tập hợp các bước, điều kiện, và các đầu vào có thể được sử dụng trong khi thực hiện kiểm tra.Có rất nhiều loại test như chức năng, tiêu cực, lỗi, trường hợp kiểm tra hợp lý, trường hợp thử nghiệm vật lý, trường hợp thử nghiệm giao diện người dùng, vv

• Mục đích chính của việc tạo testcase là:

  • Test case sẽ nói lên những bước nào của yêu cầu nên thực hiện để chắc rằng các yêu cầu được thực hiện theo như kế hoạch.

  • Test case giữ gìn các dữ liệu test và các tester luôn luôn biết dữ liệu nào nên sử dụng trước khi test.

  • Test case là kiến thức cơ bản từ yêu cầu. Khi các tester thay đổi các đặc thù của công việc test, hầu như họ sẽ không cần phải chuyển giao lại kiến thức.

  • Test case là cách tốt nhất để chuyển cho các tester mới bằng cách nào để test các yêu cầu.

  • Tình trạng của test case là phải chính xác để QA lead biết cái gì của ứng dụng sẽ được test và cái gì không được test, phần nào nhiều lỗi, và đặc thù nào là ít lỗi sau khi có kết quả test.

• Testcase được viết để theo dõi các phạm vi thử nghiệm của một phần mềm. Nói chung, không có mẫu nào chính thức có thể được sử dụng trong trường hợp kiểm tra văn bản. Tuy nhiên, các thành phần sau đây luôn luôn có sẵn và trong mọi testcase:

  • Testcase ID
  • Module sản phẩm
  • Phiên bản sản phẩm
  • Lịch sử sửa đổi
  • Điều kiện tiên quyết
  • Các bước
  • Kết quả mong đợi
  • Kết quả thực

IV. Traceability Matrix

• Traceability Matrix là một bảng được sử dụng để theo dõi các thay đổi trong chu kì phát triền phần mềm. Nó có thể được dùng để xem những thay đổi hay truy tìm tài liệu về phía trước.

• Mỗi yêu cầu trong tài liệu RTM được liên kết với các trường hợp thử nghiệm liên quan để có thể thực hiện theo các yêu cầu. Hơn nữa, Bug ID cũng được bao gồm và liên kết với các yêu cầu liên quan của nó và trường hợp thử nghiệm. Các mục tiêu chính của ma trận này là:

  • Chắc chắn rằng phần mềm phát triển theo các yêu cầu được nêu ra.
  • Giúp cho việc tìm kiếm nguyên nhân gốc rễ của bug.
  • Giúp trong việc truy tìm các tài liệu được phát triển trong các giai đoạn khác nhau của SDLC.

Nguồn tham khảo: https://www.tutorialspoint.com/software_testing/software_testing_documentation.htm