Tầm quan trọng của hoạt động Kiểm thử Tự động trong phát triển phần mềm nằm ở khả năng cung cấp nhanh chóng các phản hồi cho nhóm phát triển khi xây dựng tính năng mới.
Nó cũng loại bỏ gánh nặng của thao tác kiểm thử hồi quy, giúp QA có thể tập trung vào các hoạt động kiểm thử khác.
Bài viết này cung cấp các lưu ý cũng như những cạm bẫy cần tránh khi triển khai kiểm thử tự động nhằm giúp mang lại giá trị cao nhất cho nhóm phát triển.
Thủ công và Tự động; Kiểm thử và Rà soát
Tránh đặt bài toán so sánh giữa kiểm thử tự động và thủ công. Cả hai hoạt động đều cần thiết và chúng phục vụ cho những mục đích khác nhau. Kiểm thử tự động là một tập hợp các hướng dẫn được viết bởi con người để thực hiện một phép kiểm thử cụ thể. Mỗi khi một kiểm thử tự động được khởi động, nó làm theo một cách chính xác những gì được mô tả và chỉ kiểm tra chính xác những gì được yêu cầu.
Kiểm thử thủ công thì khác, khi thực hiện, người tester có thể liên kết nhiều dấu hiệu, hay thay đổi các bước kiểm thử theo nhiều cách khác nhau, để phát hiện ra các vấn đề ngoài kịch bản. Điều này thể hiện đặc biệt rõ trong các kiểm thử thăm dò.
Tự động hóa những Kiểm thử Hồi quy
Lý do chính cho việc tự động hóa một bài kiểm thử là để thực hiện những kiểm thử mang tính lặp lại. Nếu bài kiểm thử chỉ được yêu cầu để thực thi một vài lần duy nhất thì nỗ lực cần bỏ ra để tự động hóa có thể lớn hơn nhiều so với lợi ích mang lại.
Kiểm thử hồi quy là những bài kiểm thử được yêu cầu phải lặp lại mỗi khi phát hành phiên bản mới của sản phẩm. Đây là những bài kiểm thử cần thiết, nhưng tốn thời gian, và nhàm chán. Đây là những bài kiểm thử nên được tự động hóa.
Thiết kế bài kiểm thử trước khi tự động hóa chúng
Viết trước các test case với một chiến lược rõ ràng và cụ thể trước khi tiến hành tự động hóa kiểm thử. Như thế thiết kế kiểm thử sẽ tốt hơn và giúp dễ nhận diện các lỗi. Việc “tự động hóa” chỉ đơn thuần là triển khai thiết kế của kiểm thử .
Sẽ rất nguy hiểm nếu nhảy ngay vào tự động hóa bởi bạn sẽ chỉ chú ý tới việc làm cho các mã chỉ dẫn hoạt động mà quên mất toàn cảnh. Bạn cũng sẽ thường chỉ chú ý tới các phép kiểm thử “dương” và “trôi chảy” và cố ý bỏ qua các phép kiểm thử cần thiết khác.
Và, đừng giảm phạm vi của kiểm thử chỉ để kiểm thử xanh hết.
Loại bỏ sự thiếu nhất quán khỏi các kiểm thử tự động
Một trong những điểm cốt yếu của kiểm thử tự động là cung cấp kết quả nhất quán mà từ đó chúng ta có thể khẳng định được có điều gì đó không đúng khi xuất hiện kiểm thử thất bại.
Nếu một kiểm thử tự động mới vừa xanh và rồi đỏ ngay trong lần chạy tiếp theo, mà không có bất kỳ thay đổi nào trên phần mềm, chúng ta không thể khẳng định được kết quả thất bại đó là do bản thân phần mềm hay là từ những yếu tố khác như môi trường thực thi, hay chính bản thân mã kiểm thử.
Khi kiểm thử thất bại, chúng ta luôn phải phân tích nguyên nhân, và nếu có nhiều kết quả thất bại thiếu nhất quán như vậy thì chi phí phải bỏ ra để phân tích sẽ rất lớn.
Vậy nên hãy loại bỏ những kiểm thử không ổn định khỏi bộ kiểm thử tự động; để có được bộ kết quả nhất quán nhất mà bạn có thể sử dụng.
Xem xét lại những kiểm thử tính hợp lệ tự động
Hạn chế sử dụng kiểm thử tự động để kiểm thử tính hợp lệ (validation), nếu không bạn sẽ thường xuyên phải cập nhật một lượng lớn các kiểm thử tự động. Nếu cần thiết, chỉ đặt kiểm thử tự động cho những trường hợp quan trọng nhất.
Việc kiểm thử tính hợp lệ tự động một cách bừa bãi có thể là một triệu chứng của việc triển khai kiểm thử tự động mà không dành đủ nỗ lực cho việc lên kế hoạch cũng như thiết kế.
Hãy luôn nhờ một người khác xem xét cẩn trọng những kiểm thử tính hợp lệ. Luôn đảm bảo các kiểm thử này được cập nhật sát với luật hợp lệ.
Đừng kiểm thử tự động những chức năng chưa ổn định
Khi một tính năng mới được phát triển, nó thường không ổn định. Có thể chức năng đó sai, thiếu hợp lý, và có thể sẽ không được phát triển trong tương lai. Cũng có thể tính năng đó sẽ sớm được thay đổi và cập nhật nhiều lần.
Trong cả hai trường hợp, những nỗ lực bỏ ra cho kiểm thử tự động sẽ đều bị lãng phí.
Do đó, tốt nhất là nên tự động hóa việc kiểm thử một tính năng khi tính năng đó đã đi vào ổn định và ít có khả năng thay đổi trong một sớm một chiều.
Đừng trông đợi Kiểm thử Tự động là phép thuật toàn năng
Động lực chính để tự động hóa kiểm thử là để giải phóng thời gian QA dành cho kiểm thử thaw dò, và tạo chỗ dựa để nhóm phát triển có thể tin rằng phần mềm vẫn hoạt động tốt sau khi cập nhật tính năng mới.
Đừng trông đợi kiểm thử tự động tìm được nhiều lỗi. Trọng thực tế, số lượng lỗi được tìm thấy bởi kiểm thử tự động luôn ít hơn nhiều so với từ kiểm thử thủ công và thăm dò.
Đừng đặt kiểm thử tự động làm chỗ dựa duy nhất
Khi cập nhật tính năng mới, các kiểm thử hồi quy tự động vẫn xanh, đó là chỗ dựa để nhóm phát triển có được sự tự tin. Sự phụ thuộc vào kiểm thử và theo đó, nhu cầu có một bộ kiểm thử hồi quy tốt ngày càng tăng lên.
Tuy nhiên, lưu ý rằng không phải tất cả các kiểm thử đều được tự động hóa, hay có thể tự động hóa, do đó hãy luôn kết hợp cả kiểm thử tự động lẫn kiểm thử thăm dò.
Đôi khi một vài sự thay đổi tính năng đáng lẽ khiến kiểm thử thất bại; nhưng bộ kiểm thử tự động rất dễ lâm vào không phát hiện ra, nếu nhóm phụ thuộc hoàn toàn vào kiểm thử tự động thì lỗi này sẽ rất dễ bị bỏ qua.
Đặt mục tiêu nhận phản hồi nhanh
Nhận phản hồi nhanh là một trong số những mục tiêu của kiểm thử tự động bởi nhóm phát triển luôn cần biết được liệu những gì họ đang phát triển có đang hoạt động tốt và không làm hỏng những chức năng hiện tại hay không.
Để có được vòng phản hồi nhanh, các bài kiểm thử cần được tự động hóa ở cấp độ component hay API mà không cần phụ thuộc vào giao diện người dùng.
Các kiểm thử dựa trên giao diện người dùng chạy chậm hơn và dễ lỗi hơn khi giao diện người dùng thay đổi. Nói cách khác nghĩa là chức năng không đổi nhưng kiểm thử thất bại do giao diện người dùng thay đổi. Điều đó vô tình khiến kiểm thử mất đi tính tin cậy.
Hiểu rõ ngữ cảnh
Các kiểm thử có thể được tự động hóa ở nhiều tầng, Đơn vị, API, Service, GUI. Mỗi tầng có những mục đích kiểm thử khác nhau.
Kiểm thử đơn vị đảm bảo mã hoạt động tốt ở tầm mức lớp class, rằng mã có thể biên dịch được, và logic đúng như mong muốn. Kiểm thử ở tầng này mang tính kiểm tra (verification) hơn là phê chuẩn (validation).
Kiểm thử API hay Kiểm thử Tích hợp đảm bảo một tập hợp các chức năng và các class có thể làm việc tốt cùng nhau và dữ liệu có thể được chuyển giao từ một class đến một class khác.
Kiểm thử trên GUI mặt khác kiểm tra luồng và hành trình của người dùng. Nói chung chúng ta không kiểm thử tính năng từ UI. Tính năng nên được kiểm thử ở các tầng thấp hơn.
Mục đích chính của các kiểm thử trên UI là để đảm bảo toàn bộ hệ thống hoạt động theo một số kịch bản sử dụng phổ biến. Kiểm thử ở tầng này mang nhiều tính phê chuẩn hơn là kiểm tra.
Tại tầng UI, chúng ta tự động hóa các kịch bản sử dụng, thay vì các tính năng (user stories).
Đừng tự động hóa mọi kiểm thử
100% Test Coverage là không thể vì lẽ có tới hàng triệu sự kết hợp khác nhau. Chúng ta luôn chỉ thực hiện một tập con của các kiểm thử có khả năng thực hiện. Và kiểm thử tự động cũng thế.
Tạo ra một kiểm thử tự động cần thời gian và công sức, và nhắm đến mục tiêu “Tự động hóa Mọi Kiểm thử” sẽ cần rất nhiều thời gian và công sức, thứ mà thường chúng ta không có sẵn.
Thay vào đó, sử dụng một cách tiếp cận dựa trên mức rủi ro để xác định xem kiểm thử nào cần được tự động hóa. Để nhận được nhiều giá trị nhất từ kiểm thử tự động, chỉ nên tự động hóa những nghiệp vụ và kịch bản quan trọng nhất.
Quá nhiều kiểm thử tự động cũng sẽ khiến chi phí và độ khó của việc bảo trì tăng lên.
Một lưu ý khác nữa là không phải tất cả các kiểm thử đều có thể tự động hóa được. Có một số kiểm thử về bản chất rất phức tạp, yêu cầu nhiều ở hệ thống hạ tầng, và có thể không có tính nhất quán. Những trường hợp đó tốt nhất là để dành cho kiểm thử thủ công.
Áp dụng các kỹ thuật kiểm thử vào Kiểm thử Tự động
Những kỹ thuật kiểm thử mà bạn học được từ ISTQB không chỉ dành riêng cho kiểm thử thủ công. Chúng cũng được áp dụng để kiểm thử tự động. Những kỹ thuật như Phân tích Giá trị Biên, Phân vùng Tương đương, Kiểm thử Chuyển đổi Trạng thái, Kiểm thử cặp đôi… rất có giá trị trong kiểm thử tự động.
Đừng tự động hóa loạn
Để tối đa hóa giá trị của kiểm thử tự động cần có một quy trình QA tốt. Nếu quy trình QA đang hỗn loạn, việc thêm kiểm thử tự động vào chỉ làm cho tình hình tệ hơn.
Cố gắng trả lời rõ ràng những câu hỏi như Tự động hóa cái gì? Bao giờ thì tự động hóa? Khi nào thì thực thi các kiểm thử tự động? Ai sẽ tự động hóa các kiểm thử? Công cụ nào nên dùng?
Tổng kết
Bài viết này được dịch từ https://devqa.io/test-automation-tips-best-practices/. Thông tin được lấy từ những kinh nghiệm triển khai kiểm thử tự động trong thực tế của tác giả, và hi vọng sẽ có ích với bạn.
