Mỗi lần có bạn hỏi nên theo automation test hay low-code, chúng tôi thường nói thẳng rằng không có đáp án đúng tuyệt đối. Quyết định nằm ở bài toán đội bạn đang gặp, quy mô sản phẩm và kỹ năng sẵn có trong team. Chính chúng tôi cũng từng đứng trước câu hỏi này, nên bài viết dưới đây gom lại những điều chúng tôi ước gì được biết sớm hơn, kèm tiêu chí chọn cụ thể và các hạn chế thực tế của từng hướng.
Hai hướng này khác nhau ở đâu?
Nhiều bạn mới vào nghề hay gộp chung hai khái niệm này vì cả hai đều hứa hẹn làm nhanh hơn. Thực ra chúng khá khác nhau. Automation test là viết script để máy tự chạy lại các kịch bản kiểm thử. Bạn vẫn đang viết code, chỉ là đoạn code ấy dành cho việc kiểm tra phần mềm.
Low-code đi theo hướng ngược lại. Bạn kéo thả các khối chức năng, cấu hình sẵn logic, và nền tảng lo phần còn lại. Nói cách khác, một bên là kiểm soát từng dòng, bên kia là đổi lấy tốc độ bằng cách chấp nhận khuôn khổ có sẵn của nền tảng.
Automation test phù hợp khi bạn cần độ linh hoạt và kiểm soát cao, nhất là với hệ thống lớn có logic phức tạp. Low-code phù hợp hơn khi cần ra sản phẩm gấp, hoặc khi người làm nghiệp vụ không chuyên cũng muốn tự tham gia dựng công cụ. Vì vậy, thay vì hỏi cái nào tốt hơn, hãy hỏi đội mình thực sự cần gì.
Tiêu chí chọn công cụ automation test
Việc đầu tiên cần xem là cả team đang viết code bằng ngôn ngữ nào. Nếu đội quen Java, dùng Selenium với Java sẽ đỡ tốn công học lại từ đầu. Đội quen Python thì các thư viện Python dễ tiếp cận hơn. Còn nếu cả đội làm frontend bằng JavaScript, chọn bộ công cụ viết bằng JavaScript giúp mọi người dùng chung một hệ sinh thái, đỡ phải đổi ngữ cảnh liên tục.
Tiêu chí thứ hai là khả năng tích hợp CI/CD như Jenkins, GitLab CI hay GitHub Actions. Test chỉ thật sự có giá trị khi nó tự chạy mỗi lần đẩy code lên. Nếu phải có người bấm nút thủ công, bộ test sẽ nhanh chóng bị bỏ quên, và bạn không còn biết code mới có làm hỏng chức năng cũ hay không.
Cũng cần lưu ý: nhiều công cụ mã nguồn mở đòi hỏi thời gian dựng hạ tầng ban đầu, từ cấu hình môi trường đến máy chạy test. Mỗi hệ thống một khác nên chúng tôi không thể đưa ra con số chung. Bạn nên tự thử trên một dự án nhỏ trước khi triển khai rộng.
Ví dụ minh hoạ: một nhóm 5 dev bắt đầu automation test thế nào
Hãy hình dung một nhóm 5 người đang làm sản phẩm web nội bộ. Họ không nên bắt đầu bằng việc viết test cho toàn bộ hệ thống, vì làm vậy có thể mất vài tháng mà chưa thấy kết quả rõ. Thay vào đó, họ chọn luồng đăng nhập và thanh toán làm điểm xuất phát, bởi đây là chỗ nếu bỏ sót lỗi thì thiệt hại lớn nhất.
Bước tiếp theo là ưu tiên test hồi quy (regression), tức chạy lại những chức năng đã hoạt động đúng để chắc rằng thay đổi mới không làm hỏng phần cũ. Test giao diện có thể đưa vào sau, khi nhóm đã quen quy trình. Đi từng bước như vậy giúp họ thấy giá trị sớm mà không bị quá tải.
Con số tiết kiệm thời gian thì mỗi dự án một khác, nên đừng lấy kết quả giả định này áp lên hệ thống của bạn. Hãy tự đo trên sản phẩm của mình.
Low-code phù hợp với loại dự án nào?
Low-code phát huy tốt ở các ứng dụng nội bộ như form xin nghỉ phép, quản lý tồn kho đơn giản hay quy trình phê duyệt chi phí. Đây là những thứ cần chạy được ngay, không đòi hỏi tối ưu hiệu năng đến từng mili-giây.
Nhóm hưởng lợi nhiều nhất thường là đội nhỏ, hoặc người làm nghiệp vụ muốn tự dựng công cụ cho phòng ban mình mà không phải chờ dev rảnh tay. Hạn chế cũng khá rõ: khi cần tùy biến sâu, nền tảng sẽ bắt đầu gò bó. Ngoài ra, nguy cơ bị khóa vào một nhà cung cấp (vendor lock-in) là có thật, nên hãy hỏi kỹ khả năng xuất dữ liệu trước khi cam kết lâu dài.
Khi nào nên kết hợp cả hai?
Nhiều đội đang làm hai việc song song. Họ dùng low-code để dựng giao diện nhanh, còn phần logic nghiệp vụ quan trọng thì viết test tự động để kiểm tra. Cách này cho phép giao diện thay đổi linh hoạt mà logic vẫn được bảo vệ chắc chắn.
Một việc hay bị bỏ qua là quy ước đặt tên và nơi lưu test case. Nếu không thống nhất từ đầu, sau vài tháng sẽ không ai đọc hiểu được test của người khác. Nên viết quy ước ra một trang tài liệu ngắn và cập nhật khi có thay đổi. Việc nhỏ này tiết kiệm được khá nhiều thời gian tranh cãi về sau.
Chi phí thực tế: giấy phép, nhân lực và thời gian học
Công cụ thương mại thường tính phí theo người dùng hoặc theo gói, và mức giá thay đổi tùy nhà cung cấp cũng như thời điểm. Chúng tôi không đưa con số cụ thể vì dễ lỗi thời. Bạn nên xin báo giá trực tiếp từ bên bán.
Trên thực tế, chi phí ẩn thường lớn hơn tiền license. Thời gian viết script ban đầu và công bảo trì mỗi khi giao diện thay đổi có thể là phần chiếm nhiều công sức. Khi so sánh các phương án, đừng chỉ nhìn giá phần mềm mà hãy tính cả công sức con người bỏ vào đó.
Những sai lầm hay gặp khi bắt đầu
Sai lầm đầu tiên là cố tự động hóa 100% test ngay từ đầu. Kết quả thường là dự án đổ vỡ giữa chừng vì quá lớn để kiểm soát. Hãy bắt đầu từ vài luồng quan trọng nhất rồi mở rộng dần.
Sai lầm thứ hai là viết script phụ thuộc chặt vào vị trí phần tử trên giao diện. Khi bố cục đổi, test báo lỗi giả (flaky) dù chức năng vẫn chạy bình thường. Nên dùng định danh ổn định, chẳng hạn các ID riêng dành cho test.
Ngoài ra còn hai lỗi khá phổ biến: không ai chịu trách nhiệm bảo trì sau khi bàn giao, và không dọn dẹp những test đã lỗi thời khiến bộ test ngày càng phình to và chậm chạp.
Cách đo hiệu quả
Đo hiệu quả là việc nhiều người hay quên nhất. Bạn nên theo dõi ba chỉ số: thời gian chạy một bộ test, tỷ lệ test báo lỗi giả và số lỗi được phát hiện trước khi đưa lên môi trường thật. Ba con số này cho biết test đang giúp đỡ hay đang gây phiền.
Cách đơn giản nhất là so sánh trước và sau khi triển khai trên cùng một nhóm chức năng. Nếu sau vài tháng vẫn không thấy cải thiện, đừng vội thêm test. Hãy xem lại chiến lược, vì nhiều khi vấn đề nằm ở việc chọn sai luồng để kiểm tra.
Lộ trình cho người mới
Nếu bạn chưa vững lập trình, hãy học nền tảng trước, đặc biệt là cách đọc hiểu một đoạn code và quy trình kiểm thử phần mềm cơ bản. Đừng vội nhảy vào công cụ khi nền còn yếu, vì sẽ rất dễ nản.
Khi đã có nền tảng, hãy thực hành với một công cụ mã nguồn mở. Sau đó mới cân nhắc công cụ thương mại nếu công ty yêu cầu. Tài liệu chính thức của từng công cụ luôn là nguồn đáng tin nhất, vì phiên bản mới có thể thay đổi cách dùng so với hướng dẫn cũ trên mạng.
Câu hỏi thường gặp
Người không biết lập trình có học được automation test không?
Có, nhưng giai đoạn đầu sẽ chậm hơn. Bạn nên học cơ bản về biến, vòng lặp và hàm trước. Nhiều công cụ hiện có chức năng ghi lại thao tác, giúp làm quen trước khi viết tay từng dòng.
Low-code có thay thế được automation test hoàn toàn không?
Thường là không. Low-code giúp dựng nhanh nhưng khó kiểm soát logic phức tạp. Hai hướng này thường bổ trợ nhau hơn là thay thế nhau.
Nên bắt đầu từ công cụ nào cho dự án nhỏ?
Hãy chọn công cụ khớp với ngôn ngữ đội đang dùng, và ưu tiên thứ có cộng đồng lớn để dễ tìm lời giải khi gặp lỗi. Đừng chọn theo quảng cáo.
Làm sao biết test tự động đã đủ tốt để tin tưởng?
Nếu test bắt được lỗi thật trước khi người dùng gặp và số test báo lỗi giả ở mức thấp, bạn đang đi đúng hướng. Không cần đặt mục tiêu phủ 100%, vì điều đó hiếm khi thực tế và cũng không cần thiết.
Nếu phải chốt lại một việc, hãy bắt đầu nhỏ với một luồng quan trọng, đo kết quả rồi mới mở rộng. Nếu muốn hiểu nền tảng hơn, bạn có thể đọc automation test là gì và khác biệt với manual testing. Với định hướng lâu dài, lộ trình chọn đúng từ đầu cho lập trình web và mobile sẽ giúp bạn nhìn rõ bức tranh chung. Còn nếu bạn đang quản lý kịch bản test cùng mã nguồn, hướng dẫn sử dụng Git cơ bản cho dev mới là kiến thức nền nên có. Để tham khảo thêm tài liệu chính thức, bạn có thể xem tài liệu của Selenium.
