Keyword-Driven Testing

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là QA lead tại một công ty fintech ở TP.HCM. Team của bạn có 8 người, nhưng chỉ 2 người biết code Selenium. Sáu người còn lại là manual tester giỏi nghiệp vụ — họ hiểu rõ luồng nạp tiền, luồng KYC, luồng chuyển khoản hơn bất kỳ ai — nhưng khi nhìn vào một file Java đầy driver.findElement(By.xpath(...)), họ bó tay. Kết quả: 2 automation engineer trở thành cổ chai (bottleneck). Mọi test case mới đều phải chờ họ code, và backlog cứ dài ra mãi.

Đây chính xác là bài toán mà Keyword-Driven Testing (KDT) sinh ra để giải quyết. Ý tưởng cốt lõi cực kỳ đơn giản nhưng mạnh mẽ: thay vì viết test bằng code, ta tách phần "kỹ thuật" (cách click, cách nhập, cách kiểm tra) ra khỏi phần "nghiệp vụ" (làm gì, theo thứ tự nào). Người biết code xây một bộ "từ khóa" (keyword) — mỗi keyword là một hành động đã đóng gói sẵn. Người không biết code chỉ việc ghép các keyword lại thành test case, giống như xếp Lego.

Ở bài trước bạn đã học Data-Driven Testing — cách tách dữ liệu ra khỏi test để chạy cùng một kịch bản với nhiều bộ input. Keyword-Driven đi xa hơn một bước: nó tách cả hành động ra ngoài. Đây là bước tiến quan trọng để mở rộng năng lực automation cho cả team, không chỉ vài "coder" trong nhóm. Hiểu KDT còn giúp bạn nắm được nền tảng tư duy đằng sau nhiều framework nổi tiếng như Robot Framework, và hiểu tại sao nó vừa là "vũ khí" vừa là "cái bẫy" nếu dùng sai.

Khái niệm cốt lõi

Test case = chuỗi keyword + argument

Nền tảng của KDT có thể gói gọn trong một công thức:

> Test case = một chuỗi các dòng, mỗi dòng gồm: Keyword + (các) Argument

Mỗi keyword đại diện cho một hành động cụ thể, ví dụ: Open Browser, Input Text, Click Button, Verify Text. Mỗi hành động cần dữ liệu đi kèm — đó là argument (đối số). Ví dụ keyword Input Text cần biết nhập vào ô nào và nhập gì.

Một test case đăng nhập viết theo phong cách keyword sẽ trông như thế này (dạng bảng, thường lưu trong Excel hoặc Google Sheets):

Người đọc bảng này không cần biết username_field được tìm bằng XPath hay CSS, không cần biết Click Button gọi hàm gì bên dưới. Họ chỉ cần hiểu nghiệp vụ: mở trình duyệt, nhập user, nhập pass, bấm đăng nhập, kiểm tra lời chào. Đó là vẻ đẹp của KDT.

Ba tầng kiến trúc

Một hệ thống Keyword-Driven luôn có ba tầng rõ ràng. Hiểu ba tầng này là hiểu 80% bản chất KDT.

Tầng 1 — Lớp Keyword (Keyword Library / Driver). Đây là phần code thật, do automation engineer viết. Mỗi keyword là một hàm. Ví dụ, keyword Input Text có thể là:

def input_text(locator, value):
    element = driver.find_element(*OBJECT_MAP[locator])
    element.clear()
    element.send_keys(value)

Tầng 2 — Object Repository (Object Map). Đây là nơi ánh xạ tên thân thiện (username_field) sang locator kỹ thuật thật (//input[@id='user']). Nhờ tách riêng, khi UI đổi ID, bạn chỉ sửa một chỗ duy nhất chứ không phải lục tung toàn bộ test case.

OBJECT_MAP = {
    "username_field": (By.ID, "user"),
    "password_field": (By.ID, "pass"),
    "login_button":   (By.CSS_SELECTOR, "button.btn-login"),
}

Tầng 3 — Test Case (bảng keyword). Đây là phần người không biết code viết. Nó chỉ là dữ liệu — một bảng liệt kê keyword theo thứ tự.

Và ở giữa, có một thành phần gọi là Engine (bộ thực thi): nó đọc từng dòng của bảng, tra cứu xem keyword đó ứng với hàm nào ở Tầng 1, rồi gọi hàm đó với các argument tương ứng. Về bản chất, engine chỉ là một vòng lặp for cộng với một cơ chế "dispatch" (điều phối) từ chuỗi tên keyword sang hàm.

So sánh nhanh với các cách tiếp cận khác

Để định vị đúng, hãy nhớ: Data-Driven tách dữ liệu ra ngoài (một kịch bản cố định, nhiều bộ input). Keyword-Driven tách hành động ra ngoài (nhiều kịch bản khác nhau ghép từ các keyword tái sử dụng). Hai kỹ thuật này không loại trừ nhau — trên thực tế người ta thường kết hợp thành Hybrid: keyword để mô tả hành động, data table để cung cấp nhiều bộ dữ liệu cho cùng chuỗi keyword. Đây mới là cấu hình mạnh nhất trong thực tế.

Tình huống thực tế

Tình huống 1 — Team QA ngân hàng số mở rộng automation cho manual tester

Một ngân hàng số tại Hà Nội (giả định tên "TrustBank") có team QA 10 người kiểm thử ứng dụng mobile banking. Chỉ 3 người viết được Selenium/Appium. Mỗi sprint, business analyst đẻ ra khoảng 40 kịch bản mới, nhưng 3 automation engineer chỉ kịp code khoảng 15 kịch bản/sprint. Tỷ lệ tự động hóa dậm chân ở mức 35%.

Họ áp dụng KDT. Ba engineer bỏ ra 4 tuần xây một thư viện gồm khoảng 60 keyword phủ hết các hành động thường gặp: Nhap OTP, Chon Tai Khoan Nguon, Xac Nhan Chuyen Tien, Kiem Tra So Du... Sau đó, 7 manual tester được huấn luyện 2 ngày để viết test case bằng Google Sheets với các keyword này.

Kết quả sau một quý: số kịch bản tự động hóa mỗi sprint tăng từ 15 lên 48. Ba engineer chuyển từ "người code từng test" sang "người bảo trì thư viện keyword" — công việc có giá trị cao hơn. Bài học: KDT không làm automation engineer mất việc; nó chuyển họ lên vai trò kiến trúc và bảo trì, đồng thời nhân năng lực sản xuất test case lên nhiều lần bằng cách tận dụng cả team.

Tình huống 2 — Cái bẫy "quá nhiều keyword" ở một sàn TMĐT

Một sàn thương mại điện tử ở Đông Nam Á (giả định "ShopFast") hào hứng với KDT đến mức... lạm dụng. Sau một năm, thư viện của họ phình lên hơn 400 keyword. Nhiều keyword trùng chức năng (Click Button, Press Button, Tap Button do các người khác nhau tạo ra), một số keyword lại quá "to" đến mức nhận 12 argument. Manual tester không nhớ nổi keyword nào làm gì, phải mở tài liệu tra cứu liên tục — nhanh hơn viết code thì không, mà rối hơn thì có.

Họ phải làm một đợt "refactor keyword": gộp keyword trùng, chuẩn hóa quy ước đặt tên, và tạo thêm các keyword nghiệp vụ cấp cao (high-level) như Dat Hang Thanh Cong — bản thân nó gọi lại 8 keyword cấp thấp bên trong. Sau refactor, số keyword mà tester cần nhớ để viết một test mua hàng giảm từ ~20 dòng xuống còn 4-5 dòng. Bài học: thư viện keyword cần được thiết kế và quản trị như một sản phẩm phần mềm thật sự — có quy ước đặt tên, có review, có phân tầng cấp thấp/cấp cao. Không có kỷ luật, KDT tự biến thành mớ hỗn độn khó bảo trì hơn cả code.

Tình huống 3 — Kết hợp Keyword + Data với Robot Framework

Một công ty gia công phần mềm ở Đà Nẵng nhận dự án test hệ thống bảo hiểm cho khách Nhật. Yêu cầu: cùng một luồng "tính phí bảo hiểm" phải chạy với 150 bộ dữ liệu khác nhau (tuổi, gói, vùng miền). Họ dùng Robot Framework — framework mã nguồn mở nổi tiếng, chính là hiện thân thương mại của tư tưởng keyword-driven.

Họ viết một keyword nghiệp vụ Tinh Phi Bao Hiem (dùng cú pháp Given/When/Then dễ đọc), rồi kết hợp với template data-driven để đổ 150 dòng dữ liệu vào. File test đọc gần như tiếng người, khách hàng Nhật (không phải dev) vẫn review được logic nghiệp vụ. Bài học: sức mạnh thật sự đến khi bạn kết hợp keyword-driven (dễ đọc, tái sử dụng hành động) với data-driven (phủ nhiều dữ liệu). Và bạn hiếm khi phải tự xây engine từ đầu — Robot Framework đã làm sẵn tầng engine cho bạn.

Hướng dẫn từng bước

Dưới đây là quy trình xây một hệ thống KDT tối giản để bạn nắm bản chất. Ta sẽ dựng bằng Python thuần để bạn thấy rõ engine hoạt động ra sao (thực tế nên dùng Robot Framework).

Bước 1 — Liệt kê các hành động lặp lại. Nhìn vào 5-10 test case manual hiện có, gạch chân những hành động lặp lại: mở trình duyệt, nhập text, click, kiểm tra text hiển thị, chờ phần tử... Đây là danh sách keyword ứng viên. Đừng cố nghĩ ra hết mọi keyword ngay — bắt đầu với 8-10 keyword thiết yếu.

Bước 2 — Xây Object Map. Tạo một dictionary ánh xạ tên thân thiện sang locator. Đây là nơi duy nhất chứa locator, giúp bảo trì tập trung.

Bước 3 — Viết lớp keyword. Mỗi keyword là một hàm nhận argument. Đăng ký chúng vào một bảng điều phối:

KEYWORDS = {
    "open_browser":  open_browser,
    "input_text":    input_text,
    "click_button":  click_button,
    "verify_text":   verify_text,
    "close_browser": close_browser,
}

Bước 4 — Viết engine. Engine đọc bảng test (ví dụ file CSV/Excel), duyệt từng dòng, tra keyword và gọi hàm:

def run_test(rows):
    for row in rows:
        keyword = row[0].strip().lower().replace(" ", "_")
        args = [a for a in row[1:] if a.strip()]
        func = KEYWORDS.get(keyword)
        if func is None:
            raise ValueError(f"Keyword khong ton tai: {row[0]}")
        func(*args)

Bước 5 — Viết test case dưới dạng bảng. Giao cho manual tester file Excel/Google Sheets với 3 cột: Keyword, Arg1, Arg2. Họ điền theo nghiệp vụ, không đụng vào code.

Bước 6 — Bổ sung keyword cấp cao khi mẫu hình lặp lại. Khi thấy một chuỗi keyword lặp đi lặp lại (ví dụ 4 dòng đăng nhập luôn đi cùng nhau), hãy đóng gói chúng thành một keyword nghiệp vụ mới login nhận username, password. Đây là bước then chốt giữ cho test case ngắn gọn, dễ đọc.

Bước 7 — Thêm log và report. Cho engine in ra từng keyword đang chạy, pass/fail, và chụp screenshot khi lỗi. Nếu không có báo cáo rõ ràng, tester sẽ không tin và không dùng.

Lỗi thường gặp & mẹo

Lỗi 1 — Keyword quá "mịn" (granular). Nếu keyword của bạn chỉ là Find Element, Send Keys, Get Attribute... thì bạn chỉ đang viết lại Selenium bằng tiếng Anh, không giảm được độ phức tạp. Tester vẫn phải nghĩ như lập trình viên. Mẹo: nhắm tới keyword ở tầm hành động người dùng (Input Text, Login), không phải tầm API kỹ thuật.

Lỗi 2 — Bùng nổ số lượng keyword. Như tình huống ShopFast, quá nhiều keyword trùng lặp khiến việc dùng còn khó hơn code. Mẹo: lập quy ước đặt tên ngay từ đầu, và bắt buộc review khi thêm keyword mới. Duy trì một trang wiki liệt kê keyword có sẵn.

Lỗi 3 — Nhét logic vào bảng test case. Có người cố nhồi if/else, vòng lặp vào bảng keyword. Bảng test vốn để mô tả tuyến tính một luồng; khi cần logic phức tạp, hãy đẩy nó xuống bên trong một keyword cấp cao. Mẹo: nếu bảng của bạn bắt đầu trông giống code, đó là dấu hiệu logic đặt sai chỗ.

Lỗi 4 — Bỏ quên xử lý lỗi và báo cáo. Nếu một keyword sai làm cả suite dừng mà không rõ dòng nào lỗi, tester sẽ nản. Mẹo: engine phải báo rõ dòng nào, keyword nào fail, kèm screenshot.

Lỗi 5 — Quên rằng vẫn cần automation engineer. KDT không "xóa sổ" nhu cầu coder. Ai đó vẫn phải xây và bảo trì tầng keyword, vá khi UI đổi. Mẹo: coi thư viện keyword là sản phẩm nội bộ có chủ sở hữu rõ ràng, đừng để "cha chung không ai khóc".

Mẹo vàng: đừng xây engine từ số 0 cho dự án thật. Robot Framework đã hiện thực hóa toàn bộ tư tưởng keyword-driven này một cách chín muồi — có engine, có report đẹp, có sẵn thư viện SeleniumLibrary, cú pháp bảng dễ đọc. Việc tự xây engine chỉ nên dùng để học cho hiểu bản chất.

Bài tập thực hành

• Nhận diện keyword. Lấy 3 test case manual bất kỳ bạn từng viết (đăng nhập, tìm kiếm sản phẩm, thêm vào giỏ hàng). Gạch chân và liệt kê tất cả hành động lặp lại. Bạn rút ra được bao nhiêu keyword chung? Đặt tên chúng theo một quy ước nhất quán.

• Xây engine mini. Dùng đoạn code mẫu ở phần hướng dẫn, hiện thực một engine Python đọc file CSV chứa 3 cột (Keyword, Arg1, Arg2) và chạy được ít nhất 5 keyword: open_browser, input_text, click_button, verify_text, close_browser. Test thử với luồng đăng nhập của một trang bất kỳ (ví dụ trang login demo công khai).

• Tạo keyword cấp cao. Từ bài 2, đóng gói 4 dòng đăng nhập thành một keyword duy nhất login nhận username, password. So sánh độ dài bảng test case trước và sau. Bạn tiết kiệm được bao nhiêu dòng?

• Thử Robot Framework. Cài Robot Framework + SeleniumLibrary, viết lại đúng luồng đăng nhập ở bài 2 bằng cú pháp .robot. So sánh trải nghiệm: engine tự viết của bạn thiếu những gì so với Robot Framework (report, screenshot khi lỗi, tag, setup/teardown)?

• Phản biện thiết kế. Giả sử team bạn đã có 300 keyword và tester phàn nàn khó dùng. Viết ra 3 hành động cụ thể bạn sẽ làm để "cứu" thư viện này (gợi ý: đọc lại tình huống ShopFast).

Tóm tắt

Keyword-Driven Testing tách test thành ba tầng: thư viện keyword (code, do engineer viết), object map (ánh xạ locator tập trung), và test case dạng bảng (dữ liệu, do bất kỳ ai viết). Một engine đọc bảng và điều phối keyword tới hàm tương ứng. Công thức nền tảng: test case = chuỗi keyword + argument.

Sức mạnh lớn nhất của KDT là dân chủ hóa automation — cho phép manual tester giỏi nghiệp vụ tạo test tự động mà không cần biết code, phá bỏ cổ chai "chỉ vài người biết lập trình". Nó cũng gom locator về một chỗ, giúp bảo trì dễ hơn. Nhưng KDT chỉ hiệu quả khi thư viện keyword được quản trị có kỷ luật: keyword ở đúng tầm hành động người dùng, có quy ước đặt tên, có phân tầng cấp cao/cấp thấp, và có người chủ sở hữu. Thiếu kỷ luật, nó biến thành mớ hỗn độn 400 keyword khó dùng hơn cả code.

Trong thực tế, hãy kết hợp keyword-driven với data-driven (Hybrid) để vừa dễ đọc vừa phủ nhiều dữ liệu, và dùng Robot Framework thay vì tự xây engine cho dự án production. Tự viết engine chỉ để hiểu bản chất — và giờ thì bạn đã hiểu rồi.