Các tiêu chí của một Test Automation Framework tốt

Good Test Automation Framework Checklist

• Các phương thức hoặc class có thể sử dụng lại - Tạo các phương thức có thể sử dụng lại ở nhiều chổ tránh trùng lặp. Đừng lặp lại một thứ gì đó mà bản chất như nhau rải rác ở nhiều bài kiểm tra hay một nơi nào đó (class page, class test,...) sau này có sửa là buộc sửa ở nhiều nơi thì không nên. Tạo dạng Common class ý.
• Xây dựng một Thư viện code: để giải quyết vấn đề bên trên thì mình nên xây dựng một thư viện chứa tất cả các thành phần có thể sử dụng lại và các kết nối bên ngoài như cơ sở dữ liệu, chức năng chung, chức năng ứng dụng, v.v. Và khi mình dùng chỉ nên dùng các thư viện đã triển khai đó. Ở tất cả các class nào cần là phải gọi các thư viện này ra mà dùng chứ không viết lại. Rất tiện bảo trì.
• Tiêu chuẩn mã hóa: Các tiêu chuẩn về kịch bản, cách viết, cách chạy phải luôn được duy trì trong khuôn khổ framework, nghĩa là sẽ không nên chạy test case theo nhiều kiểu riêng lẻ (khởi tạo, vị trí, kết xuất thông tin,...) để giúp duy trì tính đồng nhất của mã code và giúp người kiểm thử, nhà phát triển phần mềm hay training cho người mới họ cũng dễ hiểu hơn, dễ dùng hơn.
• Khả năng mở rộng và Bảo trì: Một khuôn khổ tự động hóa thử nghiệm lý tưởng (good framework) phải hỗ trợ đều đặn tất cả các cải tiến mới cho ứng dụng phần mềm (nhiều kiểu xử lý handle này kia) và cho phép sửa đổi các tính năng hiện có. Ví dụ: Tạo một thư viện có thể tái sử dụng lại như nói ở trên, điều này sẽ giúp cải thiện các tính năng của ứng dụng với mức tối ưu hơn.
• Thiết kế theo hướng dữ liệu - Dữ liệu thử nghiệm như URL / Tên người dùng hay Mật khẩu và các giá trị input nên được khai báo trong Properties File hoặc tệp Excel. Đừng ghi nó ra ở nhiều nơi.
• Xử lý tập lệnh và dữ liệu riêng biệt: Tập lệnh kiểm tra tự động phải được tách biệt rõ ràng với kho dữ liệu đầu vào (ví dụ: XML, Excel, Properties, TXT hoặc Cơ sở dữ liệu,...) để không cần sửa đổi code khi dữ liệu phải thay đổi cho nhiều giá trị đầu vào.
• Sử dụng Wait loại Chờ đợi rõ ràng (Explicit Wait) - Luồng thời gian trì hoãn ở mọi nơi trong các tình huống thử nghiệm cũng làm giảm hiệu suất. Vì vậy hãy cố gắng sử dụng các chờ đợi rõ ràng. Tức nhiên vẫn kết hợp với chờ đợi ngầm định khi cần để ổn định hơn (Implicit Wait)
• Tên biến phải có nghĩa đầy đủ.
• Quy ước đặt tên tốt cho lớp trang và đặt tên lớp thử nghiệm.
• Cố gắng sử dụng API công khai (library sẵn có) thay vì tạo nhiều tệp tiện ích xử lý thủ công.
• Báo cáo (Report) - Không in kết quả bằng System.out.println mà hãy sử dụng cơ chế Report/ghi Log.
• Hỗ trợ thực thi kiểm tra không cần hiển thị UI trên trình duyệt khi cần thiết. (headless)
• Đừng làm cứng các đường dẫn tuyệt đối khi được sử dụng trong framework, mà hãy dùng các tệp để Config chung và bỏ vào một thư mục liên quan sau đó gọi ra dùng để dễ bảo trì về sau.
• Dữ liệu nên đọc từ các kịch bản thử nghiệm (Test case class) chứ không phải trong các lớp trang (Page class).
• Cố gắng giảm các vòng lặp chương trình không cần thiết trong mã.
• Framework nên tổ chức thành các gói (package) được xác định rõ ràng. Ví dụ:
  • Pages - Nơi khai báo/ định nghĩa các lớp trang.
  • TestCases - Nơi khai báo/ định nghĩa các class test để thực thi kiểm tra.
  • Utils - Nơi khai báo của các lớp tiện ích. Như lớp báo cáo và đọc tệp.
  • ..v.v..Và các package hay class khác tùy vào độ lớn của framework.
• Ghi nhật ký khi có sự cố hoặc thông tin gì đó cần lưu lại khi chạy test. (Log file)
• Hỗ trợ trình điều khiển dạng multi để chạy trên nhiều trình duyệt khác nhau.
• Các bài kiểm tra phải độc lập khi thực thi. (sau muốn chạy song song cũng dễ)
• Báo cáo chi tiết về việc thực hiện thử nghiệm và thành công hoặc không thành công (pass/fail)
• Sử dụng các mẫu thiết kế với nguyên tắc tương ứng (TestNG, Serenity, Cucumber, NUnit, Specflow,...)
• Sử dụng BDD để viết Gherkin - Nhưng điều này thường không bắt buộc luôn luôn phải dùng.
• Ảnh chụp màn hình về lỗi (video record càng tốt) - Giúp dễ dàng kiểm tra lỗi. Đính kèm vào report hoặc rời trong thư mục mở rộng.
• Sử dụng quản lý phụ thuộc như Maven cho Java, Nuget cho .Net, PIP cho Python,...
• Phiên bản Script / Framework: Các phiên bản của framework hoặc tập lệnh code nên được duy trì trong kho lưu trữ cục bộ hoặc công cụ tạo phiên bản, điều này sẽ giúp dễ dàng theo dõi các thay đổi đối với mã code trong framework.
• Ghi chú code trong các class thư viện hoặc class chung để xử lý nào đó mà nó mang tính ổn định hoặc bắt buộc phải có khi chạy test để người khác khi đọc code có thể hiểu nhanh hơn rõ ràng hơn. 
• Tài liệu về triển khai khung thử nghiệm (docs)