Một vài điểm khác biệt khi tạo Test Plan cho dự án Automation test

Chúng ta đều biết rằng các dự án Automation khác với các dự án test Manual. Mặc dù, các dự án tự động hóa không thực sự tồn tại (hoặc không tồn tại như lý tưởng), cả hai dự án automation và manual được xử lý khác nhau ngay trong bước lên plan. Một dự án mà plan không rõ ràng thì không thể thực hiện đúng; điều này không chỉ ảnh hưởng đến các dự án hiện tại và ảnh hưởng không tốt đến việc đánh giá khả năng cá nhân, mà nó còn có thể dẫn đến việc mất niềm tin của khách hàng, quản lý, làm ảnh hưởng đến kinh doanh.

Trước khi đến tiếp phần sau, tôi muốn lưu ý bài viết này không đi sâu về các vấn đề sau.

1. Ở đây không đi sâu thảo luận về automation frameworks. Các dự án khác nhau sử dụng các framework khác nhau tùy thuộc vào tính chất của AUTs, kiến trúc, độ phức tạp, chuyên môn của nhóm nghiên cứu.
2. Bài viết không bàn về template, format hay cách tạo một test plan document. Chúng ta sẽ giải quyết những vấn đề cần cân nhắc khi tạo các tài liệu trước khi bắt đầu một dự án tự động hóa, phân tích tính khả thi trước khi làm dự án.
3. Đây cũng không đề cập đến một tool cụ thể

Mọi hoạt động trong chu kỳ phát triển phần mềm (SDLC) mất thời gian, công sức, cơ sở hạ tầng và cả tiền.

Đối với một dự án manual testing, các yếu tố phát sinh chi phí là:

• Con người
• Tools – Test/quản lý defect
• Infrastructure – môi trường, cơ sở hạ tầng
• Thời gian
• Đào tạo

Đối với một dự án automation, ngoài các mục nêu trên, nó cần chi phí cho:

• Automation tools
• Add–in để quản lý test tool
• Add-in để hỗ trợ ứng dụng đang được test (Application Under Test- AUT: ví dụ như SAP, oracle etc)
• Thiết lập Framework
• Đào tạo sử dụng một vài tool đặc biệt

Trong hoàn cảnh đó, thành công của một dự án automation phụ thuộc vào cách viết code, bao nhiêu phần code được viết có thể tái sử dụng hoặc với bao nhiêu dòng code thì có thể đạt được kết quả mong muốn? Nếu câu trả lời cho câu hỏi này là "KHÔNG" thì bạn đã lên kế hoạch cho các dự án automation không chính xác.

Thông thường, một test plan có các phần sau.

Các phần trong Test plan của Automation test

# 1: Phạm vi (Scope)

• Chọn những Test case / kịch bản có thể sử dụng lại nhiều lần khi test quay vòng
• Đôi khi test case đơn giản nhất cũng cần rất nhiều giải pháp phức tạp để test tự động. Nếu test case này chỉ dùng 1 lần duy nhất thì rõ ràng là không có ý nghĩa. Cũng vì nó có thể dùng lại nhiều lần nên cần tập trung và bỏ công sức vào đó.
• Automation test không thể thực hiện exploratory testing

# 2: Chiến lược kiểm thử (Test strategy)

• Phần này được coi như là framework trong automation test. Một số framework là rất khó để tạo ra và cũng có hiệu quả nhưng đòi hỏi thời gian, nỗ lực và năng lực. Cố gắng tìm một giải pháp tốt nhất để có thể thực hiện mà không gây nguy hại qua việc sử dụng các nguồn tài nguyên.

• Quyết định cách viết code tốt nhất cho automation test, quy ước đặt tên, địa điểm lưu trữ thiết bị test, format của test result,... để duy trì tính đồng nhất và tăng năng suất.

# 3: Tài nguyên / vai trò và trách nhiệm (Resources/roles and responsibilities)

• Bước đầu tiên là cần hiểu khả năng của nhóm và dự đoán trước phạm vi của automation trong tổng thể. Điều này sẽ giúp chọn một team phù hợp với nhu cầu của cả automation và manual testing. Ngoài ra, chọn những người có thái độ đúng - những người không nghĩ rằng manual testing là dưới tầm của họ.
• Chọn một đội thành thạo với AUT, quản lý test, quản lý defect và và các hoạt động SDLC khác

#4: Công cụ (Tools)

Chọn automation tool dựa trên các quy tắc sau đây:

• Nếu tool test không phải miễn phí thì công ty đã có giấy phép cho tool đó chưa
• Có thể tìm các tool open source nhưng cần lựa chọn
• Các thành viên trong nhóm biết về tool này hoặc đã dùng chưa, nếu không thì có cần đưa thêm người mới vào team không hay cần training cho người cũ

# 5: Lịch trình (Schedules)

• Bao gồm thời gian cho code và kiểm tra các kịch bản tự động hóa (automation scripts)
• Duy trì các kịch bản một cách thường xuyên, kịp thời. Nếu bạn tạo một đoạn code mà bạn sẽ không sử dụng trong 6 tháng tới hoặc lâu hơn, thì cần bảo trì để giảm khả năng bị failure

# 6: Môi trường (Environment)

• Các môi trường mà AUT sẽ chạy và automation tool mà bạn muốn sử dụng phải tương thích. Đây là một trong những yếu tố được cân nhắc khi chọn tool.

# 7: Phân phối (Deliverables)

• Bạn tạo test scripts, tuy nhiên, không phải ai cũng hiểu về tự động hóa / ngôn ngữ lập trình. Vì vậy cần có kế hoạch tạo ra một tài liệu "Hướng dẫn" để giúp người sử dụng hiện tại và tương lai để có thể hiểu được kịch bản này ngay cả khi không có bạn.
• Bao gồm các comment trong kịch bản.

# 8: Các rủi ro (Risks)

• Nếu bạn sẽ đề xuất một giải pháp tự động hóa, hãy chắc chắn để chọn được tool hiệu quả và chi phí phù hợp để đảm bảo rằng việc thực hiện automation không trở thành gánh nặng của dự án. Điều quan trọng cần phải xác định rằng lợi ích thu được khi đầu tư automation không nhìn thấy ngay lập tức nhưng có thể được nhìn thấy trong thời gian dài. Vì vậy, nếu bạn đề xuất việc tự động hóa hệ thống, chọn tool có các tính chất như
  • Duy trì ổn định và không cần bảo trì quá nhiều
  • Có phạm vi cho dãy hồi quy lớn
  • Không cần phải can thiệp quá nhiều bằng tay, không phụ thuộc vào trực giác của con người

# 9: dữ liệu test (Test data)

• Đi vào xem xét các khía cạnh bảo mật của dữ liệu
• Không đưa trực tiếp data test vào script. Điều này có thể gây ra lỗi trong quá trình sửa đổi, bảo trì.
• Dữ liệu test cần rất cụ thể. Đối với bước test thủ công- 'nhập tên’, theo yêu cầu có thể nhập tên bất kỳ gồm 5 ký tự. Trong khi test, có thể gõ "Swati" hoặc "Seela" hay bất cứ tên nào khác. Nhưng đối với automation test không thể làm giả định như vậy, cần phải nhập vào giá trị chính xác

# 10: Báo cáo / kết quả (Reports/results)

• Kết quả thực hiện Script cũng có tính kỹ thuật và có thể không phải mọi người trong team đều hiểu được. Plan nên viết chi tiết kết quả thực hiện trong file document hoặc file excel như một biện pháp bổ sung
• Framework documents, review results, defect reports, status.. cần có trong report

Đôi khi không dễ dàng để đề xuất khách hàng / quản lý mua các automation tool. Tuy nhiên, khi mục tiêu cuối cùng của automation test là để tối đa hóa lợi nhuận thì hoàn toàn phù hợp với mục tiêu của quản lý / khách hàng. Điều này sẽ đảm bảo rằng không chỉ chúng ta có thể thực hiện tự động hóa trong dự án mà nó còn nhận được sự đồng thuận, hợp tác và hứng thú của nhiều bên liên quan.

Lên kế hoạch và phân tích kỹ lưỡng về tất cả các yếu tố được liệt kê ở trên có thể giúp chúng ta thấy được nhiều lợi ích của automation test và các yếu tố cần thiết khi tìm kiếm một tool test

Nguồn: http://www.softwaretestinghelp.com/automation-test-palnning/