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ế.

Làm sao thiết kế test case cho tính năng bán hàng đồng thời trên nhiều kênh khi tồn kho gần cạn?

Tôi xác định bất biến cần giữ là available-to-sell không âm, sau đó thiết kế ca gửi N request đồng thời (concurrency test) vào cùng 1 SKU/location với tồn kho rất thấp (1-2 đơn vị) để buộc hệ thống lộ race condition nếu có. Oracle là số giao dịch được chấp nhận phải đúng bằng tồn kho ban đầu, không hơn.

Nếu phát hiện tồn kho hệ thống lệch so với kiểm kê thực tế tại 1 cửa hàng, bạn điều tra thế nào?

Trước hết tôi kéo log StockTransfer/ReturnExchange/Sale trong khoảng thời gian nghi vấn theo location đó, so khớp thứ tự timestamp với các sự kiện đồng bộ bù nếu cửa hàng từng offline, và kiểm tra xem có event nào bị double-apply hoặc bị bỏ sót. Sau đó tôi viết test tái hiện đúng chuỗi sự kiện đó trước khi đề xuất fix.

Điểm loyalty nên được cộng lúc thanh toán hay lúc giao dịch hoàn tất không thể huỷ (ví dụ hết hạn đổi trả)?

Về mặt trải nghiệm, điểm nên hiển thị ngay lúc thanh toán để khách thấy phản hồi tức thì, nhưng về mặt oracle kiểm thử, điểm phải ở trạng thái 'tạm tính' (pending) cho đến khi qua thời hạn đổi trả, sau đó mới chuyển sang 'đã xác nhận' (confirmed) và không thể bị điều chỉnh ngược trừ trường hợp gian lận. Test phải phủ cả 2 trạng thái và đường chuyển đổi giữa chúng.

Thực chiến: đồng bộ tồn kho omnichannel, hoàn/đổi & tích điểm loyalty trong bán lẻ

Bài sâu: bối cảnh, kiến trúc omnichannel đa kho, bất biến tồn kho/loyalty, test plan, ma trận ca, automation, race condition, đối soát, CI, AI, phỏng vấn.

1. Bối cảnh doanh nghiệp & phạm vi

Một chuỗi bán lẻ thời trang - gia dụng có 85 cửa hàng vật lý trên toàn quốc và một kênh online (app + website) vận hành song song, tổng cộng phục vụ khoảng 40.000 giao dịch/ngày, trong đó 65% diễn ra tại cửa hàng qua POS và 35% qua kênh online. Mỗi cửa hàng có kho riêng, ngoài ra còn 2 trung tâm phân phối lớn (WH-HN, WH-HCM) giữ vai trò kho dự phòng cho các đơn online khi cửa hàng gần nhất hết hàng. Bài toán cốt lõi là đồng bộ tồn kho thời gian thực giữa hàng chục điểm bán để tránh tình trạng bán vượt tồn kho (oversell) — một lỗi từng khiến chuỗi bán lẻ tương tự phải hoàn tiền và xin lỗi hơn 1.200 khách hàng trong một đợt sale cuối năm do hệ thống hiển thị 'còn hàng' tại 12 cửa hàng dù kho thực tế đã hết.

Phạm vi bài viết bao trùm 3 luồng nghiệp vụ chính: đồng bộ tồn kho đa kênh (online, POS, kho dự phòng), quy trình hoàn/đổi hàng theo mô hình omnichannel (mua online trả tại cửa hàng — BOPIS return, mua tại cửa hàng đổi online), và hệ thống tích điểm loyalty gắn liền với giá trị giao dịch thực (sau khi trừ hàng trả). Ràng buộc nghiệp vụ quan trọng: tồn kho hiển thị cho khách phải trễ tối đa 5 giây so với tồn kho thực tại quầy, và điểm loyalty phải được tính lại chính xác trong vòng 24 giờ nếu có hoàn/đổi xảy ra sau khi điểm đã cộng.

Kiến trúc luồng tồn kho omnichannel giữa Online/POS/kho/loyalty

Phạm vi tự động hoá

Kiểm thử API cho Inventory Hub: trừ/cộng tồn kho, khoá tạm thời (reservation)
Kiểm thử E2E Playwright cho luồng bán hàng và hoàn/đổi liên kênh
Kiểm thử tính điểm loyalty và cập nhật hạng thành viên

Bài này giả định Inventory Hub expose test-only endpoint để seed tồn kho theo từng kho/cửa hàng và reset điểm loyalty giữa các lần chạy.

2. Kiến trúc & luồng nghiệp vụ

Kiến trúc trung tâm là Inventory Hub — một service độc lập giữ bảng tồn kho theo (SKU, locationId) và phát sự kiện StockChanged mỗi khi có giao dịch tại bất kỳ kênh nào. POS tại cửa hàng và app online đều gọi Inventory Hub qua API đồng bộ khi cần kiểm tra tồn kho khả dụng (available-to-sell = tồn vật lý − đã giữ chỗ), và gọi bất đồng bộ (qua message queue) khi ghi nhận thay đổi để tránh nghẽn tại quầy thu ngân lúc cao điểm. OMS (Order Management System) đóng vai trò điều phối: khi kho gần nhất hết hàng, OMS tự động chọn kho dự phòng theo thứ tự ưu tiên khoảng cách địa lý và tồn kho khả dụng.

Điểm khó khi kiểm thử

Điểm khó nhất là bán đồng thời trên 2 kênh cho cùng 1 SKU chỉ còn 1 đơn vị tồn kho — đây là race condition kinh điển của bài toán omnichannel, đòi hỏi Inventory Hub phải dùng cơ chế khoá (row lock hoặc optimistic lock với version number) để đảm bảo chỉ 1 giao dịch thắng. Khó khăn thứ hai là độ trễ đồng bộ giữa các kho khi mạng cửa hàng gián đoạn: POS phải hoạt động offline-first (ghi log giao dịch cục bộ) rồi đồng bộ bù khi mạng phục hồi, nhưng thứ tự đồng bộ bù sai có thể khiến tồn kho tính sai tạm thời. Khó khăn thứ ba là hoàn hàng ngược kênh (BOPIS return): khách mua online nhưng trả tại cửa hàng bất kỳ, đòi hỏi tồn kho phải cộng đúng vào kho của cửa hàng nhận trả chứ không phải kho gốc đã xuất bán, nếu không sẽ gây lệch tồn kho giữa các kho theo thời gian.

🎯 Sự cố thực tế

Trong đợt khai trương bộ sưu tập giới hạn, một mẫu túi xách chỉ có 3 chiếc tại kho trung tâm nhưng hệ thống đã bán được 5 đơn hàng online trong vòng 90 giây đầu tiên. Điều tra cho thấy cache tồn kho ở tầng CDN của app có TTL 30 giây, khiến 2 request cuối vẫn thấy 'còn hàng' dù kho đã về 0, và Inventory Hub không có cơ chế publish invalidate cache ngay khi tồn kho chạm ngưỡng thấp.

3. Mô hình dữ liệu & bất biến (oracle)

Mô hình dữ liệu cốt lõi gồm bảng StockLevel (sku, locationId, onHand, reserved, version), StockTransfer (fromLocation, toLocation, sku, qty, status), ReturnExchange (originalOrderId, returnLocationId, sku, qty, refundAmount, type: RETURN|EXCHANGE), và LoyaltyLedger (customerId, points, tier, txnRef, effectiveAt). Available-to-sell của một SKU tại một địa điểm luôn được tính là onHand − reserved, và giá trị này là số hiển thị cho khách chứ không phải onHand thô.

Bất biến nghiệp vụ bắt buộc (oracle)

Bất biến 1: tồn kho tổng toàn hệ thống của 1 SKU (Σ onHand mọi location) không bao giờ âm và không đổi ngoài các giao dịch hợp lệ (bán, nhập, chuyển kho, trả hàng)
Bất biến 2: available-to-sell = onHand − reserved luôn ≥ 0 tại mọi location, mọi thời điểm
Bất biến 3: mọi StockTransfer hoàn tất phải làm tổng tồn kho hai đầu (from+to) không đổi (bảo toàn số lượng)
Bất biến 4: điểm loyalty cộng cho 1 đơn hàng phải bị điều chỉnh giảm tương ứng khi có hoàn/đổi làm giảm giá trị giao dịch thực
Bất biến 5: hạng thành viên (tier) chỉ tăng khi điểm tích luỹ hợp lệ vượt ngưỡng, không giảm ngược khi có hoàn hàng xảy ra sau khi đã lên hạng trong kỳ trước