Các bước khi thực hiện testing 1 dự án phần mềm: Test Plan

Trong bài viết trước, chúng ta đã cùng nhau tìm hiểu về Test Design - 1 trong những bước cần làm rõ khi thực hiện kiểm thử 1 dự án phần mềm. Bài viết này, chúng ta cùng tìm hiểu về 1 trong những bước quan trọng cần có trong quá trình kiểm thử: Test Plan 1. Test plan là gì? Test plan là kế hoạch thực hiện của việc Kiểm thử trong Project plan và dựa vào Project plan để xây dựng

2. Tại sao phải viết test plan?

• Để định hướng suy nghĩ
• Là phương tiện giao tiếp của nhóm test với đội dự án và là công cụ giao việc trong nhóm test
• Hỗ trợ quản lý và điều chỉnh khi có thay đổi

3. Các loại test plan

• Master test plan: Một kế hoạch kiểm thử level cao duy nhất cho một dự án/sản phẩm kết hợp tất cả các kế hoạch kiểm thử khác.
• Testing Level Specific Test Plans: Các kế hoạch cho mỗi mức thử nghiệm:
  • Unit Test Plan
  • Integration Test Plan
  • System Test Plan
  • Acceptance Test Plan
• Testing Type Specific Test Plans:
  • Kiểm thử Hiệu năng
  • Kiểm thử An ninh

4. Mục tiêu cần đạt được

• Xác định được các yêu cầu
• Tăng hiệu quả làm việc nhóm
• Xác định loại test
• Xác định chiến lược test
• Chỉ rõ trách nhiệm
• Xác định deadline
• Thời điểm dừng test
• Cập nhật liên tục

5. Template của Test plan Format và nội dung của Test plan khác nhau tùy thuộc vào các quy trình, tiêu chuẩn và các công cụ quản lý kiểm tra đang được thực hiện. Tuy nhiên, định dạng sau, dựa trên tiêu chuẩn IEEE cho tài liệu kiểm thử phần mềm, cung cấp một bản tóm tắt về Test plan

a. Số nhận dạng kế hoạch kiểm tra: Cung cấp một nhận dạng duy nhất cho tài liệu. (Tuân theo Hệ thống Quản lý Cấu hình nếu bạn có.)

b. Giới thiệu:

• Cung cấp tổng quan về kế hoạch kiểm tra.
• Chỉ định các mục tiêu / mục đích.
• Chỉ định bất kỳ hạn chế.

c. Tài liệu tham khảo:

• Liệt kê các tài liệu có liên quan, có liên kết tới chúng nếu có, bao gồm những điều sau:
  • Kế hoạch Dự án
  • Kế hoạch Quản lý Cấu hình

d. Các mục Kiểm thử

• Liệt kê các mục kiểm tra (phần mềm/sản phẩm) và các phiên bản của chúng.

e. Các tính năng cần được kiểm tra:

• Liệt kê các tính năng của phần mềm/sản phẩm cần kiểm thử
• Cung cấp tài liệu tham khảo cho Requirements và/hoặc Thông số kỹ thuật thiết kế của các tính năng cần được kiểm tra

f. Các tính năng không được kiểm tra:

• Liệt kê các tính năng của phần mềm/sản phẩm sẽ không được kiểm tra.
• Chỉ định lý do các tính năng này sẽ không được kiểm tra.

g. Tiếp cận:

• Đề cập đến cách tiếp cận tổng thể để thử nghiệm.
• Chỉ định mức kiểm tra [nếu đó là Kế hoạch Thử nghiệm Chính], các loại thử nghiệm, và các phương pháp thử [Hướng dẫn / Tự động; Hộp trắng / Hộp Đen / Hộp Xám]

h. Tiêu chí Pass/Fail :

• Chỉ định các tiêu chí sẽ được sử dụng để xác định xem mỗi mục kiểm tra (phần mềm / sản phẩm) đã vượt qua hay không.

i. Tiêu chí Suspension và yêu cầu Resumption:

• Chỉ định các tiêu chí sẽ được sử dụng để tạm ngừng hoạt động thử nghiệm.
• Chỉ định các hoạt động thử nghiệm phải được làm lại khi thử nghiệm được tiếp tục.

k. Test Deliverables: Liệt kê các sản phẩm thử nghiệm và các liên kết tới chúng nếu có, bao gồm:

• Test Plan
• Test Cases
• Test Scripts
• Defect/Enhancement Logs
• Test Reports

l. Môi trường thử nghiệm:

• Chỉ định các thuộc tính của môi trường kiểm tra: phần cứng, phần mềm, mạng, vv
• Liệt kê bất kỳ công cụ kiểm tra hoặc các công cụ liên quan.

m. Ước tính:

• Cung cấp một bản tóm tắt các ước tính thử nghiệm (chi phí hoặc nỗ lực) và/hoặc cung cấp liên kết tới dự toán chi tiết.

n. Lịch trình:

• Cung cấp bản tóm tắt lịch trình, chỉ định các cột mốc kiểm tra quan trọng, và / hoặc cung cấp liên kết đến lịch biểu chi tiết.

o. Nhu cầu Nhân viên và Đào tạo:

• Chỉ định nhu cầu nhân sự theo vai trò và các kỹ năng cần thiết.
• Xác định đào tạo là cần thiết để cung cấp những kỹ năng đó, nếu chưa có.

p. Trách nhiệm:

• Liệt kê trách nhiệm của mỗi nhóm/vai trò/cá nhân.

q. Rủi ro:

• Liệt kê những rủi ro đã được xác định.
• Chỉ rõ kế hoạch giảm nhẹ và kế hoạch dự phòng cho mỗi rủi ro.

u. Giả định và phụ thuộc:

• Liệt kê các giả định đã được đưa ra trong quá trình chuẩn bị kế hoạch này.
• Liệt kê các phụ thuộc.

v. Phê duyệt:

• Chỉ định tên và vai trò của tất cả những người phải phê duyệt kế hoạch.
• Cung cấp không gian chữ ký và ngày tháng. (Nếu tài liệu được in)

Lưu ý:

• Lập kế hoạch súc tích. Tránh sự thừa và dư thừa. Nếu bạn nghĩ rằng bạn không cần một phần đã được đề cập trong mẫu ở trên, hãy tiếp tục và xóa phần đó trong kế hoạch kiểm tra của bạn.
• Hãy cụ thể. Ví dụ: khi bạn chỉ định một hệ điều hành như một thuộc tính của một môi trường thử nghiệm, cũng đề cập đến Hệ điều hành Phiên bản / Phiên bản, không chỉ tên của Hệ điều hành.
• Hãy sử dụng danh sách và bảng nếu có thể. Tránh các đoạn văn dài.
• Có kế hoạch kiểm tra xem xét một số lần trước khi cơ sở nó hoặc gửi nó để phê duyệt. Chất lượng của kế hoạch kiểm tra của bạn nói lên số lượng về chất lượng của bài kiểm tra mà bạn hoặc nhóm của bạn sẽ thực hiện.
• Cập nhật kế hoạch khi cần thiết. Một tài liệu đã lỗi thời và không sử dụng bị lỗi và tệ hơn là không có tài liệu ở nơi đầu tiên.

6. Các vấn đề gây ảnh hưởng đến việc kiểm thử a. Functional testing – kiểm thử chức năng

• Function testing – kiểm thử chức năng
• User interface testing – kiểm thử giao diện người sử dụng
• Data & database integrity testing – kiểm thử DL & tích hợp DL
• Business cycle testing – kiểm thử chu trình nghiệp vụ

b. Performance testing – kiểm thử hiệu xuất

• Performance profiling
• Load testing
• Stress testing
• Volume testing

c. Security & Access control testing – kiểm thử bảo mật & kiểm soát truy cập d. Regression testing – kiểm thử hồi qui

7. Môi trường kiểm thử Tuỳ vào mỗi giai đoạn Unit test, Intergration test, System test, acceptance test sẽ ứng với môi trường kiểm thử nhất định. Từ đó xác định các yếu tố để xây dựng môi trường kiểm thử, sử dụng như môi trường thật hay tạo môi trường giả lập gần giống với môi trường chạy thật của chương trình.

• Khi test chạy chương trình bằng bản dịch hay chạy trên code. Thông thường, các giai đoạn System test, Acceptance test phải chạy trên bản dịch
• Với CSDL thì thông thường, từ Intergration test, ta phải thiết lập CSDL riêng và thiết lập các thông số cho CSDL gần giống hoặc giống hệt như khi chương trình sẽ chạy thật.
• Điều kiện về mạng: sẽ sử dụng mạng LAN hay Dial up… Thông thường, khi Unit test, có thể sử dụng mạng LAN nhưng khi System test trở đi thì nên sử dụng hệ thống đường truyền giống như hoặc gần giống như môi trường chạy thật.
• Mô hình sẽ cài đặt chương trình test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất

Kết luận: Test plan có vai trò quan trọng trong việc giúp hỗ trợ quản lý và điều chỉnh kế hoạch kiểm thử khi có thay đổi và là công cụ giao việc trong nhóm test. Sau khi tạo Test plan, đội kiểm thử sẽ bắt tay vào việc tạo Testcase. Việc tạo testcase xin được trình bày ở bài viết sau