I. Lướt một vòng google

Vì có quá nhiều bài báo viết về chủ đề này mà không đi tường tận rõ ràng nên các bạn testers tìm hiểu mãi, ngược xuôi vẫn chưa biết Automation test là gì. Mình viết bài này để hi vọng rằng các bạn có cái nhìn tổng quát và hình dung được công việc của mỗi phần.

Làm Automation test là làm gì? scope đến đâu.

Trước viết bài này, mình có lướt qua google, tìm 1 số bài tiếng việt thì thấy kết quả thế này:

Đại đa số đều nói về:

• Manual và Automation khác nhau thế nào
• Automation thì có lợi, hại gì
• Và cuối cùng coi Automation Test là UI Automation Test (oh men). Đúng nhưng không đủ

Ví dụ:

II. Automation Test thực sự là gì? Ai sẽ làm gì

Vậy thì hiểu thế nào là đúng và đủ? Mình sẽ base trên bài này để nói, tuy nhiên sẽ đơn giản hóa mô hình để các bạn dễ hiểu hơn.

Disclaimer: Bài này sẽ nói Automation Test nhưng các bạn cũng có thể hiểu là Automation Check, để đỡ cái nhau về thuật ngữ.

Mình xin lấy 1 hệ thống đơn giản như trên mô hình để giới thiệu các bạn 3-4 kiểu test automation ( tất nhiên là còn các kiểu automation test khác).

1. Unit Test

• Đối tượng là Unit, vậy Unit là cái gì, nó có thể là Method / Class tùy từng team quyết định, nhưng thông thường sẽ là method. Unit Test thông thường đi cùng với phương pháp TDD và các framework xUnit truyền thống của các ngôn ngữ.
• Người viết là developer, ai cũng biết và chả ai quan tâm, cuối cùng là chả mấy khi nó xuất hiện trong dự án. Bây giờ mọi thứ đang thay đổi, các công ty đã chú ý đến CI/CD và việc viết Unit Test là bắt buộc.
• Unit Test với Back-end có vẻ dễ hiểu, còn Front-end thì sao, nó test cái gì? Nó là 1 loại test UI (như nhập sai định dạng email –> show lỗi, nhập đúng định dạng email –> enable button submit…) nhưng focus vào từng action đơn lẻ, chứ không phải là cả 1 flow dài như UI Automation. Ngày này, việc ngày càng có nhiều framework front-end thì việc viết test dạng này được support rất nhiều, cụ thể là bao nhiêu thì mình không biết. =)))) sorry, mình là tester. Tất nhiên, việc này cũng phụ thuộc vào application đang làm là dạng server-side rendering hay client-side rendering. Nếu là dạng Server-side rendering thì việc viết Unit test cho Front-end gần như là không thể, ta nên dùng Selenium xử lý ở kiểu test UI Automation.

2. Narrow Integration test

Thông thường người ta chỉ viết đến Integration Test, nhưng mình lại tách làm 2 loại Integration là Narrow (nhỏ) và Broad (lớn) vì chia scope thế để mọi người đỡ hiểu nhầm.

• Đối tượng test là việc liên kết của 2 thành phần khác nhau. Theo định nghĩa thì thành phần ở đây có thể là Class / Package / Submodule / Module / System. Mình thấy thật sự là quá phức tạp. Agrrrr. Theo bản thân mình, chỉ nên tính việc connect giữa 2 modules. Ví dụ:
  • Giữa code logic và database
  • Giữa code logic và file system
  • Giữa code logic và hệ thống external service.
  • ….

• Người viết là Developer, các test integration cũng không quá phức tạp, gồm 2 loại testcase:
  • Happy cases: chứng minh là việc kết hợp 2 thành phần hoạt động ngon lành với nhiều loại valid inputs.
  • Edge cases: với input invalid thì module bên ngoài sẽ trả ra lỗi và code logic phải handle được error đó.

• Thông thường nếu dùng framework thì những thứ này hầu hết do framework xử lý, nhưng chúng ta vẫn nên viết ít nhất là happy cases, vì để bug lọt lên test level cao hơn thì cost có thể lớn hơn.

Đây là 2 samples của Integration Test của App với DB và App với External Service.

3. Broad Integration Test / API Test / End-to-End Test (no UI)

Thuật ngữ Integration Test là cho chúng ta rất nhiều hiểu nhầm và tranh luận, đấy là lý do mà Google đã bỏ qua luôn nhưng thuật ngữ này mà dùng Small / Medium / Large Test. Còn mình thì vẫn cố dùng vì hầu như mọi người vẫn quen với những cái đó hơn.

Gói gọn lại: Theo mình có 3 tên gọi cho kiểu test này và nó được coi là high-level test vì nó test khi tất cả các thành phần (trừ UI) work cùng với nhau.

• Đối tượng test là business logic của phía Back-end nhưng dưới góc độ kỹ thuật, đó là việc bạn sử dụng các protocol như HTTP để thực hiện việc test.
• Người viết là Automation Tester, đôi khi là Developer (nếu rảnh) :v
• Về chi tiết, test cái gì, test thế nào, mình đã có chia sẻ trong:
  • API ebook
  • Series API Testing với Postman.
  • Series API Testing với Rest-Assured

4. UI AUtomation Test

Có lẽ vì hầu hết testers đều trải qua giai đoạn manual, viết test cases theo dạng acceptance test, có nghĩa là hướng từ phía người dùng sử dụng sản phẩm như thế nào, nên khi học về automation test, mọi người thường hướng về sử dụng selenium để có thể automate được những test case mà đã được viết trên excel. Điều này có thể nằm trong suy nghĩ của rất nhiều người từ PM, dev, tester, BA … nên mới xảy ra tình trạng như ở phía đầu bài mình có nói, nhầm tưởng Automation test là UI Automation Test.

Việc sử dụng với số lượng bao nhiêu test case, tỷ lệ với những loại test khác thế nào đều là chủ đề mọi người thường bàn tới, nhưng đại đa số đều hi vọng giới hạn số lượng test case loại này ở mức nhỏ nhất có thể. Dẫn chứng google nói không với more End-to-End test, microsoft thay đổi tỉ lệ các level test.

• Đối tượng test là toàn bộ hệ thống, business logic dưới góc độ của End-User, giả lập người dùng sử dụng sản phẩm, có thể là web, native mobile app hoặc main-frame app…
• Người viết là Automation Tester.
• Cách thức thực hiện và sample, mình đã viết ở 2 series:
  • Selenium Basic
  • Selenium Advance

III. Tổng kết

Chốt lại, về mặt định nghĩa, tất cả những loại test nào run tự động và tự động check kết quả thì gọi là Automation Test, nên nó sẽ có rất nhiều loại với nhiều thuật ngữ khác nhau. Tuy nhiên để đơn giản hóa, mình chỉ nêu ra 4 loại như trên. Hi vọng, sau bài này các bạn có cái nhìn rõ hơn về làm Automation Test là làm gì và nhiệm vụ của Dev và Test trong đó.