Học Tester ở đâu tốt và thực chiến?

CyberSoft Tester cung cấp lộ trình học kiểm thử phần mềm từ cơ bản đến nâng cao: manual testing, automation với Playwright/Selenium, kiểm thử API, performance và AI testing, bám sát công việc thật của doanh nghiệp.

Người mới, chưa biết gì có học Tester được không?

Được. Lộ trình bắt đầu từ khái niệm test case, bug report rồi nâng dần lên automation và AI testing, kèm luyện phỏng vấn và CV để đi làm được.

AI Testing là gì và học như thế nào?

AI Testing là việc dùng AI (như Claude) để sinh test case, review, tăng độ phủ và tăng tốc kiểm thử. CyberSoft Tester có chuyên mục AI trong Testing và AI Agent trong Testing.

Có luyện thi ISTQB và phỏng vấn không?

Có. Nền tảng có ngân hàng câu hỏi ISTQB tự chấm, luyện phỏng vấn QA và mock interview mô phỏng thực tế.

Fixture trong automation testing là gì?

Fixture là một khối chuẩn bị (setup) chạy trước khi test thực thi — ví dụ tạo tài khoản, tạo đơn hàng, mở kết nối — và có thể tự động dọn dẹp (teardown) ngay sau khi test kết thúc, dù test đó pass hay fail. Trong Playwright, fixture được khai báo bằng test.extend() và test chỉ cần khai báo tên fixture cần dùng trong tham số của hàm test.

Vì sao không nên tạo dữ liệu test bằng cách thao tác qua giao diện (UI)?

Không phải KHÔNG BAO GIỜ được tạo qua UI — mà nên dành thao tác UI cho đúng phần đang muốn kiểm thử. Nếu bài test đang kiểm tra tính năng thanh toán nhưng lại phải điền form đăng ký, đăng nhập, thêm sản phẩm vào giỏ chỉ để CÓ dữ liệu, thì phần chuẩn bị đó vừa chậm vừa dễ vỡ khi UI đổi. Tạo dữ liệu nền qua API/DB nhanh hơn nhiều lần, ổn định hơn, và giữ test tập trung đúng vào điều cần kiểm chứng.

Nếu quên viết teardown (dọn dữ liệu) thì hậu quả thực tế là gì?

Dữ liệu test sẽ tồn đọng lại sau mỗi lần chạy: tài khoản test chất đống, đơn hàng test lẫn vào dữ liệu thật, và những lần chạy sau có thể tình cờ 'thấy' dữ liệu cũ này rồi cho kết quả sai — ví dụ test đếm số đơn hàng của 1 tài khoản sẽ đếm nhầm cả đơn của lần chạy trước. Về lâu dài, database môi trường test phình to, chậm dần, và niềm tin vào kết quả test giảm sút vì không ai chắc dữ liệu đang thấy là 'sạch' hay là rác tồn đọng.

Vì sao dữ liệu test cho automation nên độc lập và lặp lại được (repeatable)? A. Để mỗi lần chạy test đều xuất phát từ trạng thái dữ liệu giống nhau, không phụ thuộc kết quả của lần chạy trước hay của test khác B. Để dữ liệu test trông giống hệt dữ liệu thật trên production C. Để giảm số lượng test case cần viết D. Để không cần viết assert/expect trong test

✅ Đáp án: A. Dữ liệu độc lập và lặp lại được giúp mọi lần chạy cho kết quả đáng tin cậy, không bị ảnh hưởng bởi thứ tự chạy hay dữ liệu tồn đọng từ trước.

Fixture trong Playwright dùng để làm gì? A. Chỉ dùng để chụp ảnh màn hình khi test lỗi B. Chuẩn bị (setup) dữ liệu/môi trường trước khi test chạy, và dọn dẹp (teardown) sau khi test xong C. Thay thế hoàn toàn việc viết câu assert/expect D. Chỉ hoạt động khi chạy trên trình duyệt Chrome

✅ Đáp án: B. Fixture gói gọn phần setup trước use() và teardown sau use(), giúp test chỉ cần khai báo tên fixture cần dùng.

Vì sao nên tạo dữ liệu nền (background data) qua API/DB thay vì qua giao diện (UI)? A. Vì giao diện UI luôn chứa lỗi không thể tin tưởng B. Vì tạo qua API/DB nhanh hơn nhiều, ổn định hơn, và không phụ thuộc các bước UI có thể thay đổi C. Vì gọi API thì không cần xác thực (authentication) D. Vì giao diện ShopEasy không hỗ trợ chức năng đăng nhập

✅ Đáp án: B. API/DB tạo dữ liệu nhanh và ổn định hơn hẳn, để dành thao tác UI cho đúng phần đang cần kiểm thử.

Điều gì dễ xảy ra nhất nếu quên dọn dữ liệu (teardown) sau khi test chạy xong? A. Test luôn chạy nhanh hơn vì có nhiều dữ liệu sẵn để dùng lại B. Dữ liệu tồn đọng có thể khiến lần chạy sau bị trùng lặp hoặc fail vì trạng thái ban đầu đã khác so với mong đợi C. Không có ảnh hưởng gì vì hệ thống sẽ tự động dọn sạch mọi database mỗi đêm D. Test sẽ tự động bỏ qua toàn bộ các bước cần dùng tới dữ liệu

✅ Đáp án: B. Dữ liệu tồn đọng làm lệch trạng thái ban đầu, dẫn tới lần chạy sau dễ trùng lặp, đếm sai, hoặc fail dù tính năng vẫn đúng.

Vì sao nhiều test chạy song song KHÔNG nên dùng chung 1 tài khoản/1 bộ dữ liệu? A. Vì Playwright không hỗ trợ chạy test song song B. Vì các test có thể đọc/ghi đồng thời lên cùng dữ liệu, gây đụng độ và kết quả không đáng tin cậy C. Vì mỗi tài khoản dùng chung sẽ tự động bị hệ thống khoá lại D. Vì mỗi tài khoản chỉ được phép đăng nhập đúng 1 lần duy nhất trong đời

✅ Đáp án: B. Khi nhiều test song song cùng đụng vào 1 tài khoản/đơn hàng, thao tác của test này có thể ghi đè hoặc làm lệch dữ liệu mà test kia đang kiểm tra.

Chuẩn bị dữ liệu test trong automation cho người mới: fixtures, tạo & dọn dữ liệu (có code chạy được)

Bài cho người mới: chuẩn bị dữ liệu test trong automation qua app TMĐT ShopEasy. Vì sao test cần dữ liệu độc lập & lặp lại được, khái niệm fixture với setup/teardown, tạo tài khoản/đơn hàng qua API thay vì UI, dọn dữ liệu sau test, giữ test không phụ thuộc nhau, hai tình huống thật (dùng chung tài khoản chạy song song đụng nhau, không dọn data khiến lần chạy sau fail), nhiều mockup giao diện, FAQ và trắc nghiệm 5 câu. Chuẩn SEO, dẫn về khóa Tester CyberSoft.

1. Tóm tắt nhanh & vì sao dữ liệu test quan trọng

⭐ TL;DR — Chuẩn bị dữ liệu test là bước nền tảng của automation: mỗi test cần dữ liệu của RIÊNG mình, độc lập với test khác, và có thể tạo lại y hệt ở bất kỳ lần chạy nào (repeatable). Bài này bám app TMĐT ShopEasy: bạn học vì sao dữ liệu dùng chung gây lỗi khó lường, khái niệm fixture với setup/teardown, cách tạo tài khoản/đơn hàng qua API thay vì qua giao diện, cách dọn dữ liệu sau test, và cách giữ test không phụ thuộc lẫn nhau — có code Playwright chạy được, nhiều hình minh hoạ và trắc nghiệm cuối bài.

Chào bạn mới! Khi bắt đầu viết test automation, phần lớn người mới tập trung vào việc thao tác giao diện: bấm nút, điền form, kiểm tra kết quả hiện ra. Nhưng có một câu hỏi âm thầm quyết định test của bạn có đáng tin hay không: dữ liệu bạn đang test LÀ dữ liệu gì, TỪ ĐÂU mà có, và LIỆU nó có còn nguyên vẹn ở lần chạy tiếp theo? Nếu test 'mượn' một tài khoản có sẵn, một đơn hàng ai đó tạo trước, kết quả hôm nay đúng không có nghĩa ngày mai vẫn đúng — vì dữ liệu đó có thể đã bị người khác đổi, xoá, hoặc dùng chung với 1 test khác đang chạy song song. Chuẩn bị dữ liệu test đúng cách chính là nền móng giúp automation đáng tin cậy lâu dài, và đó là điều bài này sẽ giúp bạn làm chủ qua ví dụ thật với ShopEasy.

Màn hình ShopEasy: tài khoản và đơn hàng được tạo riêng cho mỗi lần chạy test, không lẫn với dữ liệu khác

📖 Dữ liệu test (test data): toàn bộ dữ liệu (tài khoản, đơn hàng, sản phẩm...) mà một kịch bản test cần có sẵn để chạy và kiểm tra kết quả, có thể là dữ liệu có sẵn hoặc do chính test tự tạo ra.

2. Vấn đề: test dùng chung dữ liệu, kết quả không đáng tin

Hãy hình dung đội automation ShopEasy viết 20 test, và cả 20 test đều đăng nhập bằng đúng 1 tài khoản 'demo@shopeasy.vn' có sẵn trên môi trường staging. Ban đầu mọi thứ chạy ổn — cho tới khi 2 test cùng cập nhật giỏ hàng của tài khoản này cùng lúc: một test đang kiểm tra 'giỏ hàng trống sau khi xoá hết', test kia lại vừa thêm 2 sản phẩm vào giỏ để test 'tính tổng tiền'. Cả hai chạy song song, và tuỳ vào việc ai 'thắng' trước, một trong hai test sẽ fail dù code tính năng hoàn toàn đúng.

Vấn đề không dừng ở đó. Khi 1 test khác vô tình xoá tài khoản 'demo@shopeasy.vn' để kiểm tra tính năng 'xoá tài khoản', mọi test còn lại dùng chung tài khoản này sẽ đồng loạt fail — không phải vì tính năng của chúng có lỗi, mà vì dữ liệu chúng cần đã biến mất. Đây là dấu hiệu rõ ràng nhất của một bộ test 'giòn': kết quả phụ thuộc vào thứ tự chạy, vào việc test nào chạy trước, và vào việc có ai đó đang đụng vào cùng dữ liệu hay không — những thứ mà bản thân tính năng cần kiểm thử không hề liên quan.

📖 Cô lập dữ liệu (data isolation): nguyên tắc mỗi test dùng dữ liệu của riêng nó, không đọc/ghi lên dữ liệu mà test khác cũng đang dùng, để kết quả không bị ảnh hưởng bởi test khác.

3. Fixture là gì & vì sao gắn liền với dữ liệu test

Fixture là cách Playwright (và nhiều framework automation khác) chuẩn hoá việc chuẩn bị và dọn dẹp mọi thứ một test cần — trong đó dữ liệu test là ví dụ phổ biến nhất. Một fixture gồm 2 giai đoạn: phần đứng TRƯỚC use() là setup (tạo tài khoản, tạo đơn hàng...), phần đứng SAU use() là teardown (xoá dữ liệu vừa tạo). Test chỉ cần khai báo tên fixture mình cần trong tham số hàm test, Playwright tự lo phần còn lại — kể cả khi test đó fail giữa chừng, teardown vẫn được đảm bảo chạy.

Các loại fixture thường dùng khi chuẩn bị dữ liệu test cho ShopEasy

Điểm mấu chốt của fixture không nằm ở cú pháp, mà ở TƯ DUY: thay vì mỗi test tự tay tạo dữ liệu theo cách riêng (và dễ quên dọn), bạn định nghĩa MỘT nơi duy nhất biết cách tạo đúng loại dữ liệu đó, và mọi test chỉ cần 'mượn' fixture này. Nhờ vậy, nếu sau này cách tạo tài khoản test thay đổi (ví dụ thêm trường bắt buộc), bạn chỉ cần sửa đúng 1 fixture, thay vì rà từng test.

💡 Đặt tên fixture theo đúng dữ liệu nó tạo ra (testAccount, testOrder...) để bất kỳ ai đọc tên tham số trong hàm test cũng đoán được dữ liệu đang dùng là gì.

4. Setup → Test → Teardown: vòng đời của 1 fixture

Mỗi lần một test khai báo dùng fixture testAccount, vòng đời diễn ra theo đúng 3 bước: (1) Setup — Playwright chạy đoạn code trước use(), gọi API tạo tài khoản mới; (2) Test — hàm use(account) trả tài khoản đó vào test, và toàn bộ thân test chạy với dữ liệu này; (3) Teardown — ngay sau khi test kết thúc (bất kể pass hay fail), đoạn code sau use() chạy tiếp để gọi API xoá tài khoản vừa tạo. Ba bước này lặp lại độc lập cho MỖI test, nên 2 test chạy song song sẽ có 2 tài khoản hoàn toàn khác nhau.

Vòng đời chuẩn bị dữ liệu qua fixture: Setup tạo dữ liệu, Test dùng dữ liệu, Teardown xoá dữ liệu

Điều làm nên sự khác biệt so với việc tự viết setup/dọn dẹp thủ công trong từng test là TÍNH ĐẢM BẢO: teardown của fixture chạy ngay cả khi test throw lỗi giữa chừng, vì Playwright quản lý phần này ở khung chạy test, không phụ thuộc vào việc bạn có nhớ gọi hàm dọn dẹp ở cuối file hay không. Đây chính là lý do fixture là công cụ đúng đắn để chuẩn bị dữ liệu test, thay vì viết tay từng bước setup/cleanup rải rác trong mỗi file.

5. Tạo dữ liệu qua API/DB thay vì qua giao diện

Có một câu hỏi người mới hay bỏ qua: khi cần 1 tài khoản để test giỏ hàng, nên tạo tài khoản đó bằng cách nào — điền form đăng ký trên giao diện, hay gọi thẳng API tạo tài khoản? Câu trả lời gần như luôn là API/DB, TRỪ KHI chính bài test đó đang kiểm thử tính năng đăng ký. Lý do rất thực tế: mỗi bước UI (mở trang, điền ô, chờ phản hồi, chờ redirect) tốn thời gian và có thể fail vì lý do không liên quan gì tới dữ liệu — ví dụ 1 ô input đổi id, 1 bước xác thực OTP mới được thêm vào.