Got It Test Automation đã nâng cao hiệu suất kiểm thử như thế nào?

(Bài viết bởi Quý Lê và Thắng Trần — Test Automation Engineer và Software Engineer tại Got It Vietnam)

Test Automation chắc hẳn không còn là một khái niệm xa lạ trong lĩnh vực kiểm thử. Tuy nhiên, việc áp dụng test automation một cách triệt để và thực sự hiệu quả vào quá trình phát triển phần mềm lại không phải một câu đố “dễ xơi” đối với nhiều công ty, đặc biệt là startup.

Nhưng hiển nhiên, chỉ chọn việc dễ không phải là điều một startup nên làm. Got It đã huy động rất nhiều tài nguyên để quyết tâm biến bài toán chưa có lời giải này thành một công cụ giúp thay đổi hoàn toàn quá trình phát triển sản phẩm. Ở bài viết sau đây, hãy cùng tìm hiểu chặng đường “thai nghén” hệ thống kiểm thử tự động (Test Automation) ở Got It, để xem:

– Test Automation là một bài toán khó như thế nào?

– Đội ngũ Got It đã gặp những khó khăn gì khi xây dựng hệ thống kiểm thử tự động?

– Hệ thống này đã dẫn đến sự thay đổi như thế nào ở Got It?

Got It Test Automation đã được “thai nghén” như thế nào?

Chất lượng sản phẩm và hiệu suất làm việc trong các hoạt động kiểm thử luôn là một vấn đề trăn trở của nhiều công ty công nghệ, bao gồm cả Got It. Test Automation là một trong số những giải pháp khả thi nhất để khắc phục những vấn đề trên.

Có thể ví việc xây dựng hệ thống kiểm thử tự động giống như một cuộc cách mạng nông nghiệp, nơi QA (Quality Assurance) là những người nông dân chuyển từ lao động chân tay với “con trâu đi trước cái cày theo sau” sang tận dụng sức mạnh của máy móc, công nghệ.

Nhu cầu về việc xây dựng một hệ thống kiểm thử tự động được nhen nhóm từ một số bài toán cụ thể mà Got It đã gặp phải:

1. Ở Got It thời kỳ đầu, quy trình phát triển sản phẩm diễn ra theo mô hình Agile (ảnh trên), các release sẽ được phát hành liên tục. Qua mỗi lần như vậy, các tính năng của sản phẩm sẽ ngày một nhiều lên để phục vụ cho business của công ty. Đi kèm với đó, việc thực hiện kiểm thử hồi quy (một bước bắt buộc phải làm để đảm bảo chất lượng sản phẩm) trước khi phát hành một release mới ngày càng làm tiêu tốn nhiều thời gian của team QA.
2. Với đặc thù là sản phẩm hỏi đáp với chuyên gia, để có thể thực hiện kiểm thử một phiên làm việc giữa chuyên gia và người hỏi, QA cần thực hiện khá nhiều bước lặp lại cho mỗi kịch bản (Signup/Login, post question, claim question…).
3. Việc chỉ viết unit test chưa đủ đảm bảo được độ phủ, cũng như bảo đảm tất cả các chức năng hoạt động bình thường từ phía Engineer.

Từ đây, nhiệm vụ xây dựng hệ thống kiểm thử tự động theo hướng End-to-End Testing* để hỗ trợ các công việc kiểm thử của QA được hình thành với sự triển khai trực tiếp bởi các kĩ sư Got It. Đó cũng là cách team Automation Test cùng với hệ thống kiểm thử tự động — Got It Test Automation Framework ra đời.

(*End-to-End Testing: một phương pháp kiểm thử xác định sản phẩm được phát triển có tuân thủ yêu cầu đề ra hay không qua việc thực thi các kịch bản hoàn chỉnh mô phỏng chính xác hành động các tác nhân lên sản phẩm.)

Test Automation Platform có thể coi là một sản phẩm mà Got It phát triển dành cho nội bộ công ty. Cũng giống như bao sản phẩm đã và đang được Got It xây dựng, nó được trau chuốt và cải tiến liên tục nhằm đảm bảo sự tin cậy và khả năng áp dụng vào thực tế.

Qua không ít lần trầy trượt, phải tạm dừng, đập đi xây lại, tái cấu trúc hệ thống kiểm thử tự động, cho đến nay, Automation Test đã trở thành một phần không thể thiếu trong quá trình phát triển sản phẩm, cụ thể hơn là các giai đoạn kiểm thử sản phẩm của Got It. Bộ công cụ kiểm thử tự động đã và đang đảm bảo các mục tiêu sau:

Công nghệ nào được sử dụng cho Test Automation ở Got It?

Ở thời điểm hiện tại, có rất nhiều công cụ tự động hoá đã được phát triển, cùng rất nhiều tài liệu, khóa học cung cấp kiến thức về tự động hoá. Tuy nhiên, việc lựa chọn công nghệ phù hợp với nhu cầu và điều kiện thực tế của công ty mới thực sự là bài toán hóc búa.

Với tiêu chí xây dựng một hệ thống có thể được mở rộng và phát triển bởi nhiều vị trí, lại không quá phức tạp để team QA có thể tiếp cận và vận hành, dưới đây là cách mà Got It lựa chọn các công nghệ cho hệ thống kiểm thử tự động của mình.

Đầu tiên là việc lựa chọn ngôn ngữ lập trình. Hiện nay đa số các ngôn ngữ lập trình bậc cao đều có thể được sử dụng để cài đặt các đoạn mã phục vụ kiểm thử tự động như Java, Javascripts, C#, PHP, v.v.. Got It đã quyết định lựa chọn Python làm ngôn ngữ lập trình chính được sử dụng trong hệ thống với các lý do sau:

1. Python có cú pháp đơn giản, rất phù hợp để các thành viên của nhóm manual QA dễ dàng tiếp cận và nhanh chóng làm chủ.

2. Python cũng là một ngôn ngữ được sử dụng phổ biến ở Got It, đặc biệt là với các vị trí Backend Engineer.

Như đã đề cập, Got It tiếp cận Test Automation theo hướng End-to-End Testing, nghĩa là các kịch bản kiểm thử được thiết kế nhằm đảm bảo tính đúng đắn cho các tính năng của hệ thống so với yêu cầu thiết kế. Vậy, có thể hiểu là Test Automation sẽ phải mô phỏng chính xác các hành động mà QA thực hiện trong các kịch bản kiểm thử thủ công, cộng với đặc thù các sản phẩm hiện có của Got It đa số trên nền tảng web.

Không quá khó khăn hay bất ngờ để Got It lựa chọn sử dụng Selenium WebDriver bởi sự phổ biến và mạnh mẽ mà nó đem lại. Selenium WebDriver cung cấp các giao diện lập trình mà thông qua các lời gọi hàm, chúng ta có thể dễ dàng điều khiển được trình duyệt và mô phỏng lại các hành động thông thường mà kiểm thử thủ công cần làm trong việc kiểm thử ứng dụng web.

Với ngôn ngữ lập trình và công cụ kiểm thử tự động được lựa chọn ở trên, có thể nói việc tiến hành viết test tự động hoàn toàn có thể thực hiện được. Tuy nhiên với một hệ thống lớn gồm nhiều tính năng như các sản phẩm của Got It, nếu chỉ tập hợp một nhóm người viết test mà không tuân theo một quy trình thống nhất hay các quy tắc chung thì hệ thống kiểm thử tự động kiểu này thật sự khó để có thể hoạt động.

Từ đó, việc xây dựng kiến trúc cho hệ thống kiểm thử tự động dựa trên nền tảng của một Testing Framework là điều hết sức cần thiết. Bằng việc định nghĩa tập quy tắc, giao thức và thủ tục trong việc tạo, tổ chức và thực thi các trường hợp kiểm thử, các công việc liên quan đến kiểm thử tự động sẽ được diễn ra một cách tuần tự và thống nhất, đảm đảo được khả năng mở rộng và bảo trì.

Framework đầu tiên mà Got It lựa chọn là Pytest bởi sự đơn giản, dễ cài đặt và mở rộng. Thời gian ban đầu công việc diễn ra khá suôn sẻ, các bạn Engineer tham gia triển khai các kịch bản kiểm thử mà team QA cung cấp một cách nhanh chóng cho sản phẩm PhotoStudy.

Tuy nhiên khi đưa vào hoạt động, vấn đề về Documentation xảy ra khi các QA rất khó để hiểu các đoạn mã được cài đặt bởi Engineer. Hơn nữa, khi một Engineer mới tham gia vào viết test, rất khó để có thể xác định nên hiện thêm, sửa hay xóa code hiện tại của hệ thống cho đúng nhu cầu của QA (vì các kịch bản kiểm thử của team QA được định nghĩa một kiểu khác).

Từ đó, nhu cầu về việc sử dụng một ngôn ngữ đặc tả thống nhất chung được đặt ra. Và rồi Behave đã xuất hiện và giải quyết triệt để vấn đề này. Behave là thể hiện của việc áp dụng kĩ thuật phát triển sản phẩm theo hướng hành vi — Behavior Driven Development (ảnh dưới).

Từ đây việc triển khai các kịch bản kiểm thử được thực hiện trôi chảy hơn gồm 2 phần:

1. QA định nghĩa các kịch bản kiểm thử bằng ngôn ngữ tự nhiên với ngôn ngữ Gherkin. Từ đó các kịch bản kiểm thử được thể hiện thông qua một tập hợp tuần tự các mệnh đề (Given, When, Then).
2. Cách mệnh đề trong kịch bản kiểm thử sau khi được định nghĩa bằng ngôn ngữ Gherkin sẽ được cài đặt bằng các đoạn mã Python tương ứng phù hợp với chức năng của chúng.

Lựa chọn công nghệ đã xong, bài toán tiếp theo mà hệ thống kiểm thử tự động của Got It cần phải giải quyết được chia làm 2 phần việc chính:

1. Vận hành việc thực thi các kịch bản để nó đem lại hiệu quả cao nhất

2. Xây dựng, tổ chức các kịch bản kiểm thử 1 cách có hệ thống

Hai phần việc này cùng những bài toán hóc búa cần giải quyết sẽ được trình bày ở phần sau đây.

Got It xây dựng môi trường kiểm thử thế nào?

Trong Test Automation, ở hầu hết các trường hợp, chúng ta cần đảm bảo cùng một kịch bản kiểm thử tự động được thực thi tại 1 thời điểm bởi nhiều người một cách độc lập và không ảnh hưởng lẫn nhau.

Lấy ví dụ với sản phẩm Excelchat của Got It, khi một QA đang thực thi kịch bản kiểm thử cho một người dùng tạo câu hỏi, sau đó sử dụng một tài khoản chuyên gia để trả lời câu hỏi đó. Trường hợp trên sẽ thất bại nếu như trong cùng khoảng thời gian này, một QA khác sử dụng cùng kịch bản đó để thực thi trên cùng một môi trường, Rất có thể chuyên gia của kịch bản sau sẽ trả lời nhầm câu hỏi được tạo ra bởi kịch bản trước đó.

Một cách tiếp cận đơn giản cho vấn đề này là mỗi QA sẽ thực thi kịch bản kiểm thử trên một môi trường độc lập. Docker chắc chắn là một sự lựa chọn hoàn hảo trong trường hợp này. Got It viết Dockerfile cho từng module và sử dụng docker-compose để build và run cả hệ thống cần test trên máy của từng QA engineer.

Tuy nhiên, cách làm này có một nhược điểm: Các QA phải trực tiếp động vào source code của từng module để có thể xây dựng được docker image cho module đó. Điều này dẫn tới việc đôi khi ở máy mỗi người sẽ phát sinh những lỗi khác nhau trong quá trình xây dựng docker image tốn nhiều thời gian để xử lý. Để giải quyết vấn đề này, Got It đã quyết định tự động hoá luôn cả việc tạo ra môi trường kiểm thử cho mỗi QA.

Môi trường kiểm thử của mỗi QA sẽ được khởi tạo và chạy trên một AWS EC2 instance có cài sẵn docker. Để có thể tạo ra các EC2 instance như thế, Got It sử dụng AWS Lambda. Về cơ bản, đây là các function được viết bằng Javascript, sử dụng AWS SDK dành cho Node.js để tạo ra một EC2 instance và thực thi một số lệnh đã được định nghĩa sẵn từ trước để xây dựng và chạy các module cần thiết.

Để mỗi QA đều có thể chủ động hơn trong việc tạo ra môi trường kiểm thử, Got It sử dụng Slackbot như là phần giao diện để giao tiếp với các AWS Lambda function kia. Như vậy, tất cả những gì một QA cần phải làm để tạo ra môi trường kiểm thử là gửi tin nhắn trực tiếp cho Slackbot đã được tạo sẵn theo đúng cú pháp. Slackbot này sẽ chạy các lambda function thích hợp để xây dựng và chạy các module và sau đó gửi lại thông tin truy cập cho QA engineer.

Vậy là khía cạnh về tự động hóa đã được giải quyết. Tuy nhiên, khi số lượng các module cần kiểm thử ngày càng lớn, Got It vấp phải vấn đề về mặt thời gian do quá trình build lại các module từ đầu vẫn xảy ra với mỗi QA. Vì vậy, Got It quyết định sử dụng AWS ECR như một registry để lưu các docker image cho các module cần kiểm thử. Chỉ ai có quyền quản lý registry này mới thực hiện build và upload image lên. Như vậy, ở EC2 instance của mỗi QA sẽ không cần phải build lại các module này từ đầu nữa, mà chỉ đơn giản là pull về từ registry.

Khi mọi thứ đã đi vào quỹ đạo được hơn một tháng, một vấn đề khác nảy sinh: Got It nhận được thông tin là chi phí phải trả cho AWS tháng trước tăng đột biến. Sau khi điều tra cụ thể, cả team phát hiện ra một sự lãng phí vô cùng trầm trọng, đó là EC2 instance của mỗi QA sẽ chạy 24/24 ngay kể cả khi người đó chỉ sử dụng nó vài tiếng một ngày. Ban đầu, một ý tưởng được đề xuất là sẽ chỉ cho chạy các EC2 instance này lên vào giờ làm việc và đưa chúng vào trạng thái stopped khi hết giờ. Tuy nhiên, điều này sẽ gây một sự bất tiện vô cùng lớn cho các QA phải làm việc vào buổi tối để xử lý các vấn đề gấp.

Vì vậy cách tiếp cận đúng ở đây là giữ instance này chạy chừng nào QA vẫn đang sử dụng nó, và tự động tắt đi khi không còn dùng đến. Ban đầu, Got It sử dụng AWS Cloudwatch để theo dõi mức độ sử dụng CPU và Network của instance, khi chúng đạt xuống thấp hơn một ngưỡng cố định thì thực hiện dừng instance lại và thông báo cho QA biết qua Slackbot.

Tuy nhiên, sau một thời gian sử dụng, rất nhiều QA gặp phải trường hợp instance của mình bị dừng một cách vô cớ. Nguyên nhân rất có thể là do có một số tác vụ mà QA thực hiện không tiêu tốn quá nhiều tài nguyên của instance. Do đó, Got It quyết định đổi một phương pháp khác. Cứ mỗi 30 phút, Slackbot sẽ hỏi xem QA có còn đang sử dụng instance này hay không. Nếu như QA không phản hồi trong năm phút sau đó, instance sẽ bị dừng. Nếu QA phản hồi đúng cú pháp, instance sẽ tiếp tục được sử dụng cho tới lần hỏi tiếp theo.

Một vấn đề tiếp theo được đặt ra: Số lượng các kịch bản ngày càng lớn và để các QA tự chạy bằng tay dưới máy của mình thì sẽ mất rất nhiều thời gian. Với Selenium, chúng ta hoàn toàn có thể chạy các kịch bản với headless browser, nghĩa là browser không có giao diện.

Vận dụng điều này, các kỹ sư Got It đã viết thêm các AWS Lambda function mới có chức năng tạo ra các EC2 instance có cài sẵn Chrome và Selenium Webdriver. Ở cuối các kịch bản kiểm thử mà Got It tạo ra riêng cho các EC2 instance này là các lời gọi API để tự động tắt instance và gửi report vào Slack về kết quả thực hiện của các kịch bản. Dựa vào tính năng mới này, cả team có thể tạo ra số lượng các EC2 instance tuỳ thích và phân bố các kịch bản đều cho các instance, giúp giảm thời gian thực hiện chạy toàn bộ kịch bản đi một cách đáng kể.

Ngoài ra, Got It đã cải tiến thêm để cho phép AWS Cloudwatch chạy các function này một cách thường xuyên để thực thi các kịch bản quan trọng phục vụ cho Business-impact Flow của sản phẩm trên môi trường thật. Kết quả của các lần chạy test này được thông báo vào Slack (ảnh dưới). Nhờ đó mà cả team luôn biết được sản phẩm của công ty có đang hoạt động ổn định hay không.

Sau khi đã có môi trường, các thành phần của kịch bản kiểm thử được tổ chức thế nào?

Như đã nhắc tới ở phần mở đầu, một trong những mục tiêu quan trọng mà hệ thống kiểm thử tự động của Got It hướng tới là linh hoạt chuyển đổi và áp dụng được vào các sản phẩm khác nhau trong hệ sinh thái của Got It. Nói cách khác, việc triển khai xây dựng các kịch bản kiểm thử cho một sản phẩm mới sẽ cần diễn ra nhanh chóng và tận dụng được các tài nguyên có sẵn thay vì phải xây dựng lại đầu. Bài toán này được giải quyết tuần tự dựa trên nhu cầu thay đổi các sản phẩm của Got It.

Ban đầu, hệ thống kiểm thử tự động chỉ chủ yếu được sử dụng cho sản phẩm Excelchat của công ty với kiến trúc còn khá sơ khai với việc ứng dụng Behave. Các bộ test (test suite) được tổ chức theo từng tác nhân của hệ thống (asker, explainer,auditor, admin) gồm các file ngôn ngữ tự nhiên (feature) và các file python để cài đặt (step definition). Kết hợp với đó là việc sử dụng Page Object Model (POM) (ảnh dưới)— 1 mẫu thiết kế phổ biến nhằm đảm bảo tính tổ chức và tái sử dụng code cho các hành động tương tác lên giao diện của ứng dụng web.

Thời gian đó, việc chuẩn bị test data cho một số kịch bản mất rất nhiều thời gian và với độ chính xác không được cao do cần phải mô phỏng lại lượng lớn các tương tác trên giao diện. Từ đó, Got It phát triển API request module với nhiệm vụ mô tả lại hành động của các tác nhân hệ thống mà không cần thông qua các tương tác trên giao diện, góp phần cải thiện vấn đề về mặt thời gian và độ chính xác.

Tiếp đó, ở một số kịch bản cho các tính năng ẩn (kết quả không được thể hiện cụ thể ở giao diện của người dùng), việc truy xuất dữ liệu từ Database là một việc bắt buộc phải làm để có thể xác nhận (verify) kịch bản đó có hoạt động đúng hay không. Và rồi DB query module được sinh ra để giải quyết vấn đề trên. Ở các giai đoạn phát triển tiếp theo của sản phẩm, QA cần kiểm thử thủ công cho việc hệ thống gửi email đến cho người dùng ở 1 số kịch bản. Việc làm trên khá mất thời gian và nhận thấy có thể tự động hoá được, các kỹ sư Got It tiếp tục xây dựng Email checker module để phục vụ việc này.

Kế đến là yêu cầu xây dựng 1 kịch bản kiểm thử nhằm xác nhận các luồng quan trọng của hệ thống (Business-impact Flow ), được thực thi ngay trên môi trường production của công ty, kèm với đó là điều kiện cần đảm bảo không để ảnh hưởng đến trải nghiệm sản phẩm của người dùng. Từ đó, lần lượt các module Configuration và Business impact ra đời.

Cũng trong thời gian đó, các kịch bản được thực thi không đảm bảo được tính ổn định như mục đích ban đầu đã đề ra. Nguyên nhân là POM chưa được nhất quán trong việc mô tả các thành phần giao diện, cùng với đó là việc sử dụng các API mà Selenium WebDriver cung cấp chưa được hiệu quả. Got It tiếp tục tối ưu hoá và tái cấu trúc lại cho Page Object module, xây dựng lớp DriverAPI để thực hiện tùy biến các API được cung cấp bởi Selenium WebDriver.

Từ đây các thành phần của bộ khung kiểm thử tự động của Got It được hình thành và được thống nhất sử dụng cho sản phẩm chính của công ty ở thời điểm bây giờ đó là ExcelChat.

Thời gian sau đó, Got It tiếp tục mở rộng hệ sinh thái của mình với việc phát triển sản phẩm hỏi đáp chuyên gia về các vấn đề liên quan đến truy vấn cơ sở dữ liệu (SQLchat). Nhận thấy sự tương đồng trong mô hình phát triển sản phẩm, team QA đã có 1 số buổi nói chuyện nhóm Software Engineer nhằm phân tích và hiểu rõ kiến trúc hệ thống cũng như cách vận hành của các sản phẩm (Vertical) trong hệ sinh thái (Platform) của công ty. Từ đó, cách làm tương tự cũng được áp dụng cho hệ thống kiểm thử tự động. Hệ thống này sẽ được chia tách thành các phần như sau:

• Các tài nguyên dùng chung, các quy tắc tiếp cận chung sẽ được định nghĩa khái quát và cài đặt ở một nơi (Core Platform).
• Với mỗi hệ thống con (Vertical), kiểm thử tự động sẽ được triển khai ở một module riêng biệt. Các tài nguyên sẽ được tái sử dụng, kế thừa lại từ phần core và viết mới các phần riêng biệt cho các trường hợp cần thiết.

Kết quả là: Sau khi thực hiện việc tái cấu trúc trên, khoảng 2 tuần sau đó, vậy xây dựng các bộ kịch bản kiểm thử cho sản phẩm SQLchat được hoàn thành. Đâu cũng chính là tiền đề cho việc xây dựng nhanh chóng, dễ dàng các bộ kịch bản kiểm thử cho các sản phẩm (vertical) tiếp theo của công ty.

Các tổ chức các thành phần chính được mô tả như dưới lược đồ:

Kết quả hiện tại với tỷ lệ ấn tượng: 80% Automating Testing— 20% Manual Testing

Có thể thấy rằng, tỉ lệ ấn tượng này đến từ một quá trình phân tích, xây dựng kiến trúc, vận hành hệ thống đầy phức tạp và gian nan. Hệ thống kiếm thử của Got It cũng trải qua quy trình phát triển như bao sản phẩm khác với những mục tiêu và vai trò riêng biệt. Dù trải qua không ít lần trầy trượt nhưng cho đến nay, hệ thống kiểm thử tự động đã cho thấy tác động to lớn khi giúp các kỹ sư của Got It nâng cao năng suất vượt bậc. Những kỹ sư kiểm thử ở Got It cũng phải luôn nâng cao trình độ và biết xử lý nhiều vấn đề kỹ thuật phức tạp mới có thể điều hành được hệ thống này.

Với chúng tôi, trong những dự định sắp tới, việc xây dựng Got It Platform sẽ luôn song hành với việc hình thành một sản phẩm có tên gọi khác — đó chính là Test Automation Platform.