Có một nỗi lo mà nhiều tester dạo này chắc đã nghe không ít, thậm chí có khi tự nghĩ trong đầu rồi nhưng chưa nói ra.

AI viết test case được.
AI generate script được.
AI đọc log được.
AI còn có thể hỗ trợ tạo luôn cả test data, suggest edge cases, thậm chí draft Playwright script nhìn cũng khá ra gì.

Vậy tester rồi sẽ đi về đâu?

Nghe hơi căng. Nhưng nói thật, đây không phải câu hỏi vô lý. Chỉ có điều, nếu nhìn kỹ hơn một chút, vấn đề không nằm ở chỗ “tester sắp hết việc”. Vấn đề nằm ở chỗ kiểu làm việc cũ của tester đang dần bớt giá trị.

Nếu một người làm test chủ yếu nhận requirement, viết test case theo form, chạy test, log bug rồi lặp lại vòng đó hết sprint này sang sprint khác, thì đúng là AI đang tiến rất nhanh vào đúng khu vực đó. Và đó là khu vực máy thường làm khá ổn: nhanh, đều, ít mệt, không ngại copy structure, cũng không than phiền vì regression quá dài.

Nhưng nếu nhìn vai trò tester ở tầng cao hơn, câu chuyện lại khác hẳn.

Điều AI đang làm tốt là phần “thao tác”, không phải phần “hiểu đúng”

Đây là chỗ cần tách bạch.

AI có thể hỗ trợ tạo test scenario từ requirement.
AI có thể generate test script automation.
AI có thể draft sẵn bộ test case theo luồng happy path, thậm chí suggest thêm vài exception case tương đối hợp lý.
Nếu dùng khéo, nó còn giúp tạo traceability matrix, review lại coverage, rà chỗ nào có vẻ thiếu, chỗ nào bị trùng.

Những chuyện đó là thật. Và càng ngày sẽ càng tốt hơn.

Nhưng tất cả những thứ đó vẫn có một điều kiện: đầu vào phải đủ rõ, người dùng phải đủ tỉnh để biết mình đang hỏi gì, và đầu ra phải được review bằng tư duy thật.

AI không tự hiểu hệ thống của mình đang vận hành ra sao ngoài đời.
AI không tự cảm được chỗ nào trong flow business là “cực kỳ nhạy”, dù requirement viết rất ngắn gọn.
AI cũng không tự chịu trách nhiệm nếu một lỗ hổng logic bị bỏ sót rồi nổ ra sau release.

Nó giúp rất tốt ở phần tăng tốc. Nhưng nó không tự biến chất lượng thành thứ có thể tin được nếu người dùng vẫn đang làm test theo quán tính.

Giá trị của tester không còn nằm chủ yếu ở chuyện “viết test case nhanh”

Đây là đoạn hơi nhột, nhưng đáng nói thẳng.

Trong một thời gian dài, nhiều nơi vô tình kéo vai trò tester về khá gần với việc thực thi:

• đọc tài liệu
• viết test case
• chạy test
• log bug
• re-test
• đóng ticket

Tất nhiên những việc đó vẫn cần. Nhưng nếu giá trị của tester bị hiểu chủ yếu ở phần này, thì AI sẽ gây áp lực rất nhanh. Vì đây là loại công việc có cấu trúc tương đối rõ, lặp lại nhiều, và dễ được tăng tốc bằng tool.

Điều khiến tester mạnh hơn không nằm ở việc ngồi viết được nhiều test case hơn trong một buổi chiều.
Điều quan trọng hơn là:

• có hiểu business flow không
• có phát hiện requirement mơ hồ không
• có nhìn ra scenario còn thiếu không
• có biết chỗ nào phải test sâu, chỗ nào chỉ cần kiểm tra vừa đủ không
• có bảo vệ được chất lượng ở mức hệ thống, chứ không chỉ mức checklist không

Nói cách khác, tester mạnh không chỉ là người “thử phần mềm”.
Họ là người giúp đội ngũ nhìn rõ chất lượng cần được thiết kế ở đâu, kiểm soát ở đâu, và rủi ro nằm ở đâu.

Tester thời AI nên tiến gần hơn tới business analysis

Đây là hướng đi tôi nghĩ rất đáng giá.

Nhiều tester giỏi thực tế đã làm chuyện này từ lâu, chỉ là chưa gọi tên rõ. Họ không đợi đến lúc code xong rồi mới ngồi test. Họ đọc requirement sớm, soi logic nghiệp vụ, hỏi lại những điểm chưa rõ, nhắc team về exception flow, và kéo chất lượng lên ngay từ đầu vòng đời delivery.

Trong thời AI, hướng này càng quan trọng hơn.

Vì khi AI có thể giúp rất mạnh ở phần tạo artifact, vai trò con người càng cần dịch lên phần:

• làm rõ yêu cầu
• bóc tách business rule
• phát hiện thiếu sót
• challenge assumption
• xác định boundary cases
• nối giữa ý định của business và cách hệ thống phải được kiểm chứng

Một tester hiểu business tốt sẽ không chỉ hỏi:

• “Hệ thống có chạy đúng không?”

Họ sẽ hỏi thêm:

• “Đúng với ai?”
• “Đúng trong điều kiện nào?”
• “Nếu người dùng thao tác lệch khỏi luồng chuẩn thì sao?”
• “Nếu hai business rule va nhau thì rule nào thắng?”
• “Nếu hệ thống technically pass nhưng làm sai expectation nghiệp vụ thì tính là pass hay fail?”

Đó là vùng mà chất lượng bắt đầu trở nên thật sự có nghĩa.

AI có thể giúp tester mạnh lên rất nhiều, nếu dùng đúng chỗ

Có lẽ cách nhìn hữu ích nhất là: AI không phải người thay tester. AI là đòn bẩy để tester thoát khỏi phần cơ học và dành nhiều thời gian hơn cho phần đáng làm.

1. Dùng AI để draft test scenarios

Từ requirement, user story, flow nghiệp vụ hoặc transcript họp, AI có thể hỗ trợ draft ra một bộ scenario ban đầu khá nhanh. Việc này đặc biệt hữu ích khi cần đi từ tài liệu thô sang một khung test có thể review được.

Nhưng giá trị không nằm ở chỗ “AI viết nhanh”.
Giá trị nằm ở chỗ tester có thể dùng bản draft đó để:

• rà missing flow
• bổ sung exception path
• tách scenario theo mức độ rủi ro
• nhận ra lỗ hổng ngay từ khâu phân tích

2. Dùng AI để hỗ trợ test matrix và coverage review

Đây là chỗ nhiều tester có thể được tăng tốc rất mạnh.

Ví dụ, từ requirement và danh sách scenario, AI có thể hỗ trợ:

• gom nhóm coverage theo feature
• đối chiếu condition và expected result
• draft traceability matrix
• rà chỗ trùng lặp
• highlight vùng có vẻ chưa cover

Nếu trước đây tester mất nhiều thời gian điền bảng và tự check thủ công, thì giờ AI có thể giúp tạo khung rất nhanh. Khi đó tester không còn phải dồn năng lượng vào việc “lấp bảng”, mà có thể tập trung hơn vào câu hỏi quan trọng: coverage này đã đủ để bảo vệ release chưa?

3. Dùng AI để review lại test artifacts

Đây là phần khá thực dụng nhưng nhiều người bỏ qua.

Một tester hoàn toàn có thể dùng AI như một lớp review phụ để:

• kiểm tra consistency giữa requirement và test case
• xem có business rule nào chưa phản ánh vào scenario không
• xem expected result có đang quá chung chung không
• xem bộ case có lệch nhiều về happy path không
• xem có edge case nào đáng nghĩ thêm không

AI không thay reviewer thật. Nhưng nó là một người soát bài rất nhanh, rất bền, và không ngại đọc lại một đống tài liệu dài.

4. Dùng AI để tăng tốc automation, ví dụ Playwright E2E

Đây là một vùng ứng dụng rất rõ.

Từ một bộ scenario đã được chốt tương đối tốt, AI có thể hỗ trợ:

• tạo skeleton Playwright script
• draft locator mapping ban đầu
• tạo assertions
• generate test data variations
• refactor đoạn script lặp
• gợi ý tổ chức test suite

Nếu biết dùng đúng, tester hoặc QA automation có thể tiết kiệm rất nhiều thời gian ở phần khởi tạo và lặp lại.

Nhưng chỗ cần nói rõ là: AI có thể giúp viết script, không đồng nghĩa AI hiểu test đó có đáng tồn tại hay không. Một bộ automation vô nghĩa vẫn có thể được generate rất nhanh. Và một E2E test dài ngoằng, flaky, khó maintain thì dù viết bằng người hay bằng AI, vẫn là nợ kỹ thuật.

Cho nên càng dùng AI tạo script nhanh, càng cần người có tư duy chất lượng để quyết định:

• test nào nên automate
• test nào chỉ nên giữ ở mức exploratory/manual
• test nào nên nằm ở unit/integration thay vì E2E
• assertion nào thực sự có giá trị

Từ người “chạy test” sang người “thiết kế chất lượng”

Có lẽ đây là chuyển dịch đáng nói nhất.

Ngày trước, nhiều đội vẫn quen nhìn tester như một chốt chặn cuối:

• build xong thì giao test
• test xong thì report
• bug fix xong thì verify

Nhưng trong bối cảnh hiện tại, vai trò tester có giá trị hơn rất nhiều nếu đi sớm hơn và rộng hơn.

Không chỉ là người chạy checklist.
Mà là người:

• góp phần làm rõ requirement
• giúp team nhìn ra rủi ro
• thiết kế scenario có ý nghĩa
• kiểm soát độ phủ
• quyết định chỗ nào nên automation
• dùng AI để tăng tốc execution nhưng không buông phần judgment

Nói cách khác, tester không nên cạnh tranh với AI ở phần máy làm tốt hơn.
Tester nên dùng AI để đẩy bản thân lên phần mà chất lượng cần tư duy hơn, hiểu hệ thống hơn và gần business hơn.

Điều đáng sợ không phải là AI viết được test script

Điều đáng sợ hơn là vẫn làm test như cũ trong khi mọi thứ xung quanh đã thay đổi.

Vẫn chờ requirement xong mới vào cuộc.
Vẫn viết test case như điền form.
Vẫn chạy test theo checklist nhưng ít đặt câu hỏi về logic nghiệp vụ.
Vẫn xem automation là chuyện của “bên khác”.
Vẫn coi bug count là thước đo chính của chất lượng.

Nếu giữ cách làm đó, AI đúng là sẽ khiến nhiều người cảm thấy mình bị bỏ lại.

Nhưng nếu tester biết dùng AI như một công cụ để tăng tốc phần cơ học, đồng thời mở rộng vai trò sang business analysis, scenario design, matrix review và automation thinking, thì câu chuyện rất khác.

Khi đó AI không làm tester nhỏ đi.
Nó chỉ buộc tester trở nên đúng nghĩa hơn.

Kết luận

Tester thời AI không hết việc. Nhưng kiểu làm việc chỉ xoay quanh thực thi thủ công, viết case theo mẫu và chạy test theo quán tính thì đúng là đang bớt giá trị nhanh hơn trước.

Cơ hội lớn hơn nằm ở chỗ khác:

• hiểu business sâu hơn
• tham gia sớm hơn vào requirement
• dùng AI để tăng tốc thiết kế scenario
• kiểm soát matrix và coverage tốt hơn
• review artifacts thông minh hơn
• đẩy mạnh automation ở những chỗ thực sự đáng đầu tư

Cuối cùng, có lẽ câu hỏi không nên là:

“AI có thay tester không?”

Mà nên là:

“Tester nào sẽ trở nên mạnh hơn khi AI đã làm tốt phần execution?”

Câu trả lời nhiều khả năng sẽ không nằm ở người chạy test nhiều nhất.

Nó nằm ở người thiết kế chất lượng tốt hơn.