Mở đầu — vì sao bài này quan trọng
Ở hai bài trước, bạn đã hiểu bức tranh tổng quan về kiểm thử phần mềm và cách thiết kế test case, viết bug report cho gọn gàng. Nhưng có một sự thật mà nhiều bạn tester mới vào nghề bị "sốc" khi đi làm: kiến thức kiểm thử trong sách vở thường mô tả một thế giới lý tưởng, nơi lập trình viên bàn giao sản phẩm hoàn chỉnh rồi tester mới bắt đầu làm việc. Còn thực tế tại đa số công ty phần mềm Việt Nam hiện nay — từ các product house như MoMo, Tiki, VNG cho đến các công ty outsourcing như FPT Software, KMS Technology — họ đều làm việc theo Agile. Và trong Agile, cách bạn kiểm thử sẽ khác hẳn.
Trong Agile, không còn khái niệm "chờ dev code xong rồi mới test". Tester tham gia từ ngày đầu tiên của sprint, làm việc song song với lập trình viên, và phải phản hồi cực nhanh. Khi tốc độ release tăng lên — có công ty deploy mỗi ngày vài lần — thì việc kiểm thử thủ công toàn bộ trở nên bất khả thi. Đó là lý do Test Automation (kiểm thử tự động) ra đời và trở thành kỹ năng gần như bắt buộc với QA hiện đại.
Bài học này giúp bạn nắm hai mảnh ghép quan trọng: (1) cách tư duy và làm việc như một tester trong môi trường Agile, thông qua mô hình Agile Testing Quadrants, và (2) những khái niệm nền tảng về kiểm thử tự động để bạn biết bắt đầu từ đâu. Đây chính là chiếc cầu nối giữa "biết kiểm thử" và "kiểm thử được trong công ty thật".
Khái niệm cốt lõi
Agile Testing là gì và khác gì so với cách truyền thống
Trong mô hình truyền thống (Waterfall), quy trình diễn ra tuần tự: phân tích yêu cầu → thiết kế → lập trình → kiểm thử → phát hành. Tester đứng gần cuối dây chuyền, giống như trạm kiểm định chất lượng ở cuối nhà máy. Vấn đề là khi tester phát hiện lỗi ở giai đoạn cuối, chi phí sửa đã đội lên rất cao, và nhiều khi không còn đủ thời gian để sửa cho tử tế.
Agile lật ngược tư duy đó. Thay vì "kiểm thử là một giai đoạn", Agile coi kiểm thử là một hoạt động diễn ra liên tục trong suốt sprint. Một vài đặc điểm cốt lõi:
- Whole-team approach (cả đội chịu trách nhiệm chất lượng): Chất lượng không phải việc riêng của tester. Lập trình viên viết unit test, tester viết test case cho tính năng, Product Owner làm rõ tiêu chí chấp nhận. Ai cũng góp phần.
- Testing sớm và liên tục (shift-left): Tester đọc user story ngay khi nó vừa được viết, đặt câu hỏi để làm rõ, tìm lỗ hổng trong yêu cầu trước khi một dòng code được viết ra. Tìm lỗi trong yêu cầu rẻ hơn tìm lỗi trong code hàng chục lần.
- Phản hồi nhanh: Trong một sprint 2 tuần, tester không có 3 ngày cuối để test dồn. Họ test ngay khi từng phần nhỏ hoàn thành.
Agile Testing Quadrants — bản đồ tư duy cho tester Agile
Đây là mô hình do Brian Marick đề xuất và được Lisa Crispin, Janet Gregory phổ biến trong cuốn Agile Testing. Nó giúp bạn trả lời câu hỏi lớn: "Trong một dự án Agile, tôi cần những loại kiểm thử nào, và mỗi loại phục vụ mục đích gì?"
Mô hình chia kiểm thử theo hai trục:
- Trục ngang: Business-Facing (hướng nghiệp vụ, dùng ngôn ngữ người dùng) ↔ Technology-Facing (hướng kỹ thuật, dùng ngôn ngữ lập trình viên).
- Trục dọc: Guide Development (hỗ trợ quá trình phát triển) ↔ Critique Product (đánh giá, phê bình sản phẩm đã có).
| Business-Facing | Technology-Facing | |
|---|---|---|
| Guide Development (hỗ trợ phát triển) | Q2: Functional tests, examples, story tests, prototype, mô phỏng luồng nghiệp vụ | Q1: Unit tests, component tests, integration tests |
| Critique Product (đánh giá sản phẩm) | Q3: Exploratory testing, usability, UAT, kiểm thử thủ công theo kịch bản thực | Q4: Performance, load, security, kiểm thử phi chức năng bằng công cụ |
- Q1 (dưới-phải): Các test kỹ thuật giúp định hướng code, thường do dev tự động hóa. Ví dụ: unit test kiểm tra một hàm tính giảm giá.
- Q2 (trên-trái): Các test nghiệp vụ mô tả hành vi mong đợi của tính năng, thường viết dưới dạng ví dụ/kịch bản. Đây là nơi tester và dev cộng tác nhiều nhất. Có thể tự động hóa (ví dụ bằng BDD).
- Q3 (dưới-trái): Con người thực sự dùng sản phẩm để đánh giá. Đây là nơi kỹ năng con người tỏa sáng — kiểm thử khám phá (exploratory), đánh giá trải nghiệm. Rất khó tự động hóa.
- Q4 (trên-phải): Kiểm thử phi chức năng cần công cụ chuyên dụng: đo hiệu năng, kiểm tra bảo mật, tải trọng.
Test Automation Basics — kiểm thử tự động là gì
Kiểm thử tự động là việc dùng công cụ/script để thực thi test case thay cho con người click tay. Nhưng đừng hiểu lầm rằng "tự động hóa = thay thế tester". Tự động hóa giỏi ở việc lặp đi lặp lại chính xác, nhanh, không mệt mỏi — hợp với regression (kiểm tra lại tính năng cũ sau mỗi lần thay đổi). Còn con người giỏi ở tư duy, phán đoán, khám phá cái bất ngờ.
Nguyên tắc chọn cái gì để tự động hóa:
- Nên tự động: test case chạy đi chạy lại nhiều lần (regression), luồng ổn định ít thay đổi, các phép tính/logic có kết quả xác định, smoke test sau mỗi lần build.
- Chưa nên tự động: tính năng đang thay đổi liên tục, test chạy đúng một lần, những thứ cần đánh giá cảm quan (giao diện đẹp/xấu, trải nghiệm mượt/khó chịu).
Tình huống thực tế
Tình huống 1: Đội QA tại một fintech Việt Nam chuyển từ Waterfall sang Agile
Một công ty ví điện tử tại TP.HCM (gọi là "PayViet" cho tiện) trước đây làm theo Waterfall. Mỗi phiên bản mất 3 tháng, tester nhận build ở tuần cuối cùng và phải test dồn 200 test case trong 5 ngày. Kết quả: liên tục bỏ sót lỗi, và có lần một lỗi tính sai phí giao dịch lọt ra production, khiến 4.000 khách hàng bị trừ sai vài nghìn đồng — không lớn về tiền nhưng gây khủng hoảng niềm tin và tốn hàng trăm giờ xử lý khiếu nại.
Khi chuyển sang Agile với sprint 2 tuần, đội QA thay đổi cách làm dựa trên Agile Testing Quadrants. Ở Q2, tester ngồi cùng dev và PO ngay khi user story "tính phí giao dịch" được viết, đặt câu hỏi: "Phí có làm tròn không? Làm tròn lên hay xuống? Giao dịch dưới 10.000đ tính thế nào?" — những câu hỏi này lộ ra ba trường hợp mà chính PO cũng chưa nghĩ tới. Ở Q1, dev viết unit test cho hàm tính phí. Ở Q3, cuối sprint tester exploratory với các số tiền kỳ lạ.
Bài học rút ra: Việc kéo tester vào từ đầu (shift-left, Q2) đã ngăn lỗi ngay từ khâu yêu cầu — nơi sửa gần như miễn phí. Cùng một lỗi, nếu để lọt ra production sẽ tốn gấp hàng chục lần.
Tình huống 2: Tự động hóa regression tại một công ty thương mại điện tử
Một sàn TMĐT ở Đông Nam Á có checkout flow gồm 40 bước kiểm thử: chọn hàng, áp mã giảm giá, chọn phương thức thanh toán, xác nhận địa chỉ... Mỗi lần dev thay đổi bất cứ đâu, tester phải chạy lại toàn bộ 40 test này bằng tay, mất khoảng 3 giờ. Với tần suất release 3 lần/tuần, đội tốn gần 9 giờ mỗi tuần chỉ để "chạy lại thứ đã chạy".
Đội quyết định tự động hóa. Nhưng thay vì lao vào viết ngay UI test cho cả 40 bước (sai lầm kinh điển), họ áp dụng kim tự tháp: đẩy phần lớn kiểm tra logic tính tiền, tính giảm giá xuống tầng API test (nhanh, ổn định), và chỉ giữ khoảng 5 kịch bản E2E quan trọng nhất ở tầng UI ("happy path" mua hàng thành công). Kết quả: bộ regression tự động chạy trong 12 phút, tích hợp vào pipeline chạy sau mỗi lần build. 9 giờ/tuần được giải phóng để tester làm exploratory testing (Q3) — nơi họ tìm ra nhiều lỗi tinh vi hơn hẳn.
Bài học rút ra: Tự động hóa không phải để "làm cho oai" mà để giải phóng con người khỏi việc lặp lại nhàm chán, dồn sức vào việc máy không làm được. Và phải tự động hóa đúng tầng — ưu tiên API hơn UI.
Tình huống 3: Cái bẫy "tự động hóa 100%"
Một startup gọi vốn xong, sếp kỹ thuật ra chỉ tiêu đầy tham vọng: "Tự động hóa 100% test case trong quý này." Đội QA viết hàng trăm UI test cho mọi thứ, kể cả các màn hình giao diện đang được thiết kế lại liên tục. Chỉ sau 6 tuần, họ rơi vào cơn ác mộng: mỗi lần designer đổi vị trí một nút bấm, hàng chục test đỏ. Đội dành nhiều thời gian sửa test hơn là tìm lỗi. Các test chập chờn (flaky) khiến team dần mất niềm tin, cuối cùng ai cũng bỏ qua kết quả test đỏ — nghĩa là bộ automation trở thành vô dụng.
Bài học rút ra: Không phải cái gì cũng nên tự động hóa. Tính năng đang thay đổi liên tục, hoặc cần đánh giá cảm quan, nên để con người kiểm thử. Mục tiêu không phải "100% tự động" mà là "tự động hóa đúng chỗ để tối đa hóa giá trị".
Hướng dẫn từng bước
Đây là cách tiếp cận thực tế khi bạn là tester trong một sprint Agile và muốn bắt đầu đưa automation vào:
- Tham gia từ đầu sprint (Q2). Khi user story được đưa vào backlog, đọc kỹ và đặt câu hỏi làm rõ. Viết ra các ví dụ cụ thể mô tả hành vi mong đợi ("khi khách nhập mã X thì giảm Y%"). Đây là hoạt động rẻ nhất mà tạo ra giá trị lớn nhất.
- Phối hợp với dev về Q1. Hỏi dev: "Phần này anh đã có unit test chưa? Case nào anh đã cover?" Bạn không cần viết unit test, nhưng biết dev đã cover gì giúp bạn tránh test trùng và tập trung vào chỗ chưa được che.
- Kiểm thử tính năng ngay khi từng phần hoàn thành. Đừng đợi cuối sprint. Test ngay để phản hồi nhanh, dev còn nhớ code mình vừa viết.
- Xác định ứng viên tự động hóa. Sau khi tính năng ổn định, hỏi: test này có phải chạy lại nhiều lần không? Logic có xác định không? Nếu có → đưa vào danh sách automation regression.
- Chọn đúng tầng theo kim tự tháp. Ưu tiên kiểm tra logic ở tầng API. Chỉ để UI/E2E cho vài luồng quan trọng nhất mà người dùng thật sự đi qua.
- Tích hợp vào pipeline. Cấu hình cho bộ test tự động chạy sau mỗi lần build/merge (CI). Khi có test đỏ, phải có người xem xét ngay — test đỏ mà không ai để ý còn tệ hơn không có test.
- Dành thời gian cho Q3 và Q4. Automation lo phần lặp lại; con người dùng thời gian được giải phóng để exploratory (Q3) và phối hợp làm performance/security (Q4).
Lỗi thường gặp & mẹo
Lỗi thường gặp:
- Hiểu sai số thứ tự Quadrant. Nhắc lại: Q1–Q4 là phân loại, không phải trình tự. Đừng làm "Q1 trước Q4 sau".
- Coi automation là mục tiêu, không phải phương tiện. Chạy theo con số "% test tự động" dẫn đến tự động hóa cả những thứ không đáng, sinh ra bộ test dễ vỡ.
- Kim tự tháp lộn ngược. Dồn hết vào UI test khiến bộ test chậm, mong manh, tốn công bảo trì.
- Bỏ mặc test đỏ. Một khi team quen với việc test đỏ mà vẫn merge, toàn bộ giá trị automation sụp đổ.
- Tester "ngồi chờ" trong Agile. Vẫn giữ tâm lý Waterfall, đợi dev code xong mới làm — bỏ lỡ toàn bộ giá trị của shift-left.
- Bắt đầu automation từ smoke test — vài kịch bản sống còn nhất (đăng nhập được, đặt hàng được). Nhỏ, giá trị cao, dễ duy trì.
- Đặt tiêu chí rõ ràng cho ứng viên automation: chạy ≥ 5 lần, logic xác định, luồng ổn định.
- Coi test tự động như code sản phẩm: cần review, refactor, đặt tên rõ ràng. Test bẩn cũng sinh nợ kỹ thuật.
- Dùng Agile Testing Quadrants như một checklist đầu sprint: "Sprint này bốn góc phần tư của tôi ai lo, đã cover chưa?"
- Đừng quên: automation không tìm ra lỗi mới — nó chỉ báo cái đã biết bị hỏng. Lỗi mới vẫn cần con người khám phá.
Bài tập thực hành
- Phân loại theo Quadrant: Cho các hoạt động sau, hãy xếp vào Q1–Q4: (a) dev viết unit test cho hàm tính thuế; (b) tester dùng thử app như người dùng thật để tìm điều bất ngờ; (c) đo xem trang chủ chịu được bao nhiêu người truy cập cùng lúc; (d) viết ví dụ mô tả "khi giỏ hàng trên 500k thì miễn phí ship" cùng PO.
- Quyết định tự động hóa: Với mỗi trường hợp, quyết định NÊN hay CHƯA NÊN tự động hóa và giải thích: (a) test đăng nhập — chạy sau mỗi build; (b) test một màn hình landing page đang được A/B test đổi liên tục; (c) kiểm tra logic tính điểm thưởng theo 8 bậc thành viên; (d) đánh giá xem animation chuyển trang có mượt không.
- Tình huống mở: Đội bạn có 60 regression test chạy tay mất 4 giờ, release 2 lần/tuần. Hãy phác thảo kế hoạch tự động hóa: chọn tầng nào cho phần nào, nên bắt đầu từ đâu, và giữ lại thao tác gì cho con người.
Tóm tắt
Trong bài này, bạn đã học hai mảnh ghép giúp trở thành tester làm việc được trong công ty thật. Thứ nhất, Agile Testing: kiểm thử không còn là giai đoạn cuối mà là hoạt động liên tục, cả đội cùng chịu trách nhiệm chất lượng, tester tham gia từ đầu (shift-left). Mô hình Agile Testing Quadrants của Brian Marick cho bạn tấm bản đồ bốn góc — Q1 (unit/kỹ thuật), Q2 (ví dụ nghiệp vụ), Q3 (khám phá/con người), Q4 (phi chức năng/công cụ) — nhớ rằng đây là phân loại chứ không phải thứ tự.
Thứ hai, Test Automation Basics: tự động hóa để giải phóng con người khỏi việc lặp lại, mạnh nhất ở regression; phải chọn đúng cái để tự động và đúng tầng theo kim tự tháp (nhiều unit, vừa API, ít UI). Automation là phương tiện, không phải mục tiêu; và nó không thay thế tư duy con người.
Nắm vững hai điều này, bạn đã sẵn sàng bước vào các bài chuyên sâu tiếp theo về nguyên tắc kiểm thử, quy trình, và từng kỹ thuật thiết kế test cụ thể.