Tiếng Việt: Integrating automated E2E and API test generation

Ở bài trước, bạn đã có một test plan được AI sinh ra và con người duyệt qua. Nhưng một test plan nằm trên giấy (hay trong file Markdown) không bảo vệ được production. Nó phải được chuyển hóa thành test case chạy được, nằm trong CI, và tự động phát hiện regression mỗi khi có code mới. Đây chính là bước "thực thi hóa" (operationalize) test plan — nơi phần lớn team QA áp dụng AI một cách nửa vời rồi bỏ cuộc, vì generated test code chạy không được, sai selector, sai import, hoặc tệ hơn: pass giả (false positive) vì test không thực sự kiểm tra điều nó tuyên bố kiểm tra.

Bài này đi vào bốn câu hỏi cốt lõi của Stage 3 (Automation Stage) trong agentic QA workflow: quyết định automate cái gì, sinh test E2E/API bằng context đúng, chạy ngay và feed kết quả ngược vào loop, và duy trì bộ test AI-generated này theo thời gian mà không để nó "mục ruỗng" (rot).

Làm sao để quyết định cái gì nên automate, cái gì nên giữ manual dựa trên test plan AI sinh ra?

Không phải scenario nào trong test plan cũng đáng để viết automated test. Automate mọi thứ là lãng phí effort và tạo ra một bộ suite khổng lồ, chậm, khó maintain. Nhưng bỏ qua automation cho những case lặp lại nhiều lần thì QA sẽ chết chìm trong regression testing tay. AI có thể giúp bạn phân loại nhất quán hơn con người đang mệt sau một sprint dài — miễn là bạn cho nó một framework rõ ràng để quyết định, không phải "cảm tính".

Khung quyết định 4 yếu tố (The Four-Factor Automation Decision Framework)

Bốn yếu tố này nên được đánh giá cho từng scenario trong test plan:

1. Regression frequency (tần suất hồi quy) — Scenario này có khả năng bị test lại nhiều lần trong tương lai không? Ví dụ: flow login, checkout, tạo đơn hàng — chắc chắn sẽ được test lại ở mỗi release. Một tính năng one-off, chạy một lần rồi bỏ (ví dụ: migrate dữ liệu cho một khách hàng cụ thể) thì không cần automate.
2. UI/API stability (độ ổn định của UI/API) — Nếu UI hoặc API contract đang trong giai đoạn thay đổi nhanh (feature mới ra mắt, đang A/B test nhiều version), automate ngay lúc này sẽ tạo ra test cực kỳ brittle (dễ vỡ). Nên chờ UI/API ổn định tương đối rồi mới automate.
3. Cost of failure (chi phí thất bại nếu bug lọt qua) — Scenario liên quan đến tiền (payment, billing), dữ liệu nhạy cảm (PII), hoặc luồng có traffic cao thì rủi ro cao — nên automate dù effort ban đầu lớn.
4. Machine-verifiability (khả năng kiểm tra được bằng máy) — Một số assertion (ví dụ: "trải nghiệm cảm thấy mượt", "màu sắc hài hòa với brand") không thể verify bằng code một cách đáng tin cậy. Những case cần đánh giá chủ quan, hoặc cần exploratory testing, nên giữ manual hoặc để AI hỗ trợ exploratory session (xem bài về AI-assisted exploratory testing) thay vì cố ép thành automated assertion giả tạo.

Mẹo: Đừng chỉ hỏi AI "case nào nên automate" — hỏi nó tính điểm cho cả bốn yếu tố riêng biệt theo thang 1-5 và show ra reasoning. Khi AI phải giải trình từng yếu tố, bạn dễ bắt được lỗi logic (ví dụ AI đề xuất automate một case one-off chỉ vì nó "nhìn có vẻ quan trọng") hơn là khi nó chỉ đưa ra kết luận cuối cùng.

Thêm decision layer vào Planning Prompt

Cách hiệu quả nhất là nhúng logic quyết định này ngay trong prompt sinh test plan ở Stage 2, để AI tự gắn nhãn "Automate" hay "Manual" cho mỗi scenario khi tạo ra nó, thay vì làm một bước riêng sau đó. Thêm block sau vào cuối planning prompt:

AUTOMATION DECISION RULES
For each test scenario you generate, classify it as AUTOMATE or MANUAL
using this rubric. Show your scoring for each factor (1-5) before the
final classification.

1. Regression frequency (1 = one-time check, 5 = will run every release)
2. UI/API stability (1 = actively changing this sprint, 5 = stable for 2+ releases)
3. Cost of failure if this bug reaches production (1 = cosmetic, 5 = revenue/data-loss/compliance risk)
4. Machine-verifiability (1 = requires subjective human judgment, 5 = deterministic pass/fail)

Classification rule:
- If average score >= 3.5 AND machine-verifiability >= 3 -> AUTOMATE
- Otherwise -> MANUAL (add a one-line reason)

Output as a table: | Scenario | Regression | Stability | Cost | Verifiability | Avg | Decision | Reason |

Mẹo: Yêu cầu AI xuất ra dưới dạng bảng markdown với cột "Reason" bắt buộc, ngay cả cho case AUTOMATE. Reasoning ngắn 1 dòng này chính là tài liệu để bạn (hoặc tech lead) review nhanh và bác bỏ quyết định sai mà không cần đọc lại toàn bộ test plan.

Ma trận quyết định trong thực tế

Ví dụ áp dụng cho tính năng "Checkout với voucher giảm giá":

Nhìn ma trận này, bạn thấy ngay pattern: những case liên quan tới logic tính toán tiền luôn được automate, còn UX cảm quan hoặc feature đang thử nghiệm thì giữ manual. Đây chính là điều một senior QA làm trong đầu một cách bản năng — giờ AI làm nó minh bạch và nhất quán cho cả team, kể cả junior.

Làm sao để trigger việc sinh test E2E và API bằng cách kết hợp codebase context và spec context?

Đây là bước mà 90% người dùng AI để sinh test thất bại — không phải vì AI "không biết viết code test", mà vì họ không cho AI thấy codebase thật của bạn. AI sinh ra test dùng driver.findElement(By.id("submit")) trong khi project của bạn dùng Playwright với Page Object Model và data-testid. Kết quả: test không compile, hoặc compile được nhưng chạy fail vì selector sai hoàn toàn.

Chuẩn bị context cho generation

Trước khi viết prompt sinh test, tập hợp đủ 4 nguồn context sau — thiếu bất kỳ nguồn nào cũng làm giảm chất lượng output đáng kể:

1. Test plan đã được duyệt — có sẵn từ Stage 2, đã gắn nhãn AUTOMATE ở bước trên. Chỉ đưa những scenario được đánh dấu AUTOMATE vào prompt sinh test, không đưa cả plan.
2. Feature spec — tài liệu yêu cầu, acceptance criteria, business rule (ví dụ: "voucher giảm tối đa 50% và không cộng dồn với flash sale").
3. Code change — diff hoặc PR liên quan đến feature này, để AI biết chính xác API endpoint, tên field, response schema, hoặc component nào vừa thay đổi.
4. Codebase context (quan trọng nhất, và cũng bị bỏ quên nhiều nhất) — đây là phần quyết định test sinh ra có chạy được hay không:
5. Đọc 2-3 file test E2E hiện có tương tự (cùng module hoặc cùng loại flow) để AI học đúng convention: cách import, cách setup/teardown, cách đặt tên test, cách dùng fixture.
6. Đọc Page Object Model (POM) hoặc helper utility hiện có — ví dụ CheckoutPage.ts, ApiClient.ts — để AI tái sử dụng method có sẵn (checkoutPage.applyVoucher()) thay vì tự viết selector thô mới.
7. Đọc file source code liên quan (component, controller, DTO) để AI biết chính xác tên field, route, response shape thật — không đoán.

Mẹo: Nếu codebase của bạn có file CLAUDE.md hoặc tài liệu tương tự mô tả cấu trúc test folder, đừng chỉ dựa vào đó — luôn kèm theo 1-2 file test thật làm ví dụ cụ thể (few-shot). Mô tả bằng lời ("chúng tôi dùng Page Object Model") kém hiệu quả hơn nhiều so với việc AI nhìn thấy trực tiếp một file .spec.ts hoàn chỉnh để bắt chước pattern, format, và style code.

Prompt sinh test E2E

Cấu trúc prompt phải tách rõ từng loại context thành section riêng, để AI không nhầm lẫn giữa "cái cần test" và "cái để tham khảo style":

TEST PLAN — SCENARIOS TO AUTOMATE
1. Apply valid voucher code -> discount applied correctly, total recalculated
2. Apply expired voucher code -> error message "Voucher has expired" shown, total unchanged
3. Apply voucher exceeding max discount cap -> discount capped at 50%, no stacking with flash sale

SPEC CONTEXT
- Voucher discount is capped at 50% of subtotal.
- Voucher cannot stack with flash sale discount (whichever is applied first wins,
  second one is rejected with a toast message).
- Voucher code is case-insensitive.

CODE CHANGE CONTEXT
- New endpoint: POST /api/cart/apply-voucher { code: string } -> 
  { success: boolean, discountAmount: number, message?: string }
- Frontend component: src/components/checkout/VoucherInput.tsx
- Error states rendered via <Toast variant="error">

CODEBASE CONTEXT — EXISTING TESTS AND PAGE OBJECTS
--- existing test file: e2e/checkout/apply-coupon.spec.ts ---
[paste full existing test file here]
--- page object: e2e/pages/CheckoutPage.ts ---
[paste full page object file here]

GENERATION RULES
- Reuse existing methods in CheckoutPage.ts. Do NOT invent new selectors if an
  equivalent method already exists.
- If a new page-object method is needed, add it to CheckoutPage.ts explicitly
  (show the full updated file), do not inline raw selectors in the test.
- Follow the exact test file naming and describe/it structure used in
  apply-coupon.spec.ts.
- Every assertion must map to a specific line item in TEST PLAN above — do
  not add assertions not requested in the plan.
- Use data-testid selectors only, matching what appears in the existing
  Page Object. If a needed data-testid does not exist in the codebase context
  provided, flag it explicitly instead of guessing one.

OUTPUT FORMAT
1. Updated/new Page Object methods (full file)
2. New test file (full file, ready to save)
3. List of any assumptions made or missing data-testid attributes flagged

Mẹo: Luôn thêm rule "nếu thiếu data-testid thì flag ra, không đoán" (dòng cuối GENERATION RULES). Đây là nguyên nhân số 1 gây ra test flaky (test cho kết quả không ổn định, lúc pass lúc fail) ngay từ lúc mới sinh — AI rất "lịch sự", nó sẽ tự bịa ra một selector hợp lý về mặt cú pháp nhưng không tồn tại trong DOM thật, và bạn chỉ phát hiện ra khi test chạy fail.

Prompt sinh test API

Test API thường đơn giản hơn E2E về mặt UI, nhưng lại dễ sai về schema và edge case nếu thiếu context về response thật:

TEST PLAN — SCENARIOS TO AUTOMATE
1. POST /api/cart/apply-voucher with valid code -> 200, discountAmount > 0
2. POST /api/cart/apply-voucher with expired code -> 200, success: false, message set
3. POST /api/cart/apply-voucher with malformed code (empty string) -> 400
4. POST /api/cart/apply-voucher when flash sale already applied -> 200, success: false,
   discountAmount unchanged from flash sale value

API CONTEXT
- Base URL: process.env.API_BASE_URL
- Auth: Bearer token via getAuthToken() helper (see existing tests)
- Request/response schema: [paste OpenAPI spec snippet or DTO source file]

EXISTING API TEST PATTERNS
--- existing test file: api-tests/cart/apply-coupon.test.ts ---
[paste full existing test file here]
--- shared helper: api-tests/helpers/apiClient.ts ---
[paste full helper file here]

GENERATION RULES
- Use the shared apiClient helper, not raw fetch/axios calls.
- Match the existing assertion library and style (e.g. chai vs jest expect).
- Validate full response schema, not just status code, for each scenario.
- Include one negative-path test for malformed input even if not explicitly
  listed, matching the existing test file's convention of testing input validation.

OUTPUT FORMAT
1. New test file (full file, ready to save)
2. List of assumptions about schema or auth flow that need confirmation

Mẹo: Với API test, luôn dán schema thật (OpenAPI, DTO, hoặc response mẫu từ Postman/curl) thay vì mô tả bằng lời. AI rất hay "làm tròn" tên field (ví dụ đoán discount_amount thay vì discountAmount thật trong code) nếu chỉ được mô tả miệng — sai lệch camelCase/snake_case là lỗi phổ biến nhất khiến test API generated compile được nhưng assert sai field, PASS giả vì so sánh với undefined.

Validate rằng test sinh ra thực sự chạy được

Sinh ra code không phải là xong việc — bước validate ngay là bắt buộc, không phải optional:

Chạy E2E test và capture output. Chạy ngay trong terminal hoặc headed mode để xem trực quan:

npx playwright test e2e/checkout/apply-voucher.spec.ts --headed --reporter=list

Các lỗi generation phổ biến cần fix ngay khi thấy:
- Sai đường dẫn import — AI đoán sai path tương đối (../pages/CheckoutPage thay vì ../../pages/CheckoutPage). Fix nhanh, nhưng là dấu hiệu bạn chưa cho đủ context về cấu trúc folder.
- Page Object method không tồn tại (checkoutPage.applyVoucherCode is not a function) — AI bịa ra method tên nghe hợp lý nhưng chưa được implement. Cần quay lại, thêm method đó vào Page Object thật, hoặc yêu cầu AI generate luôn phần đó như đã dặn trong OUTPUT FORMAT.
- Thiếu field trong test-data-factory — nếu project dùng factory pattern để tạo test data (buildCartFixture({...})), AI có thể quên field mới cần cho scenario (ví dụ voucherCode). Lỗi này thường xuất hiện dưới dạng undefined runtime error, không phải lỗi compile.
- Selector/data-testid không tìm thấy — test fail với timeout "element not found". Đây là hệ quả trực tiếp của việc thiếu codebase context ở bước trước; verify lại DOM thật bằng browser devtools trước khi sửa selector.

Chạy API test:

npx jest api-tests/cart/apply-voucher.test.ts --verbose

Với API test, lỗi phổ biến nhất là assertion mismatch do sai tên field hoặc sai kiểu dữ liệu (string vs number cho discountAmount) — luôn đối chiếu response thật (log ra hoặc dùng console.log(JSON.stringify(response.body))) trước khi kết luận test sai hay code sai.

Làm sao để chạy test sinh ra ngay lập tức và feed kết quả ngược vào agentic loop?

Test sinh ra mà không chạy ngay thì bạn không biết nó có giá trị gì hay không cho đến khi merge vào CI — lúc đó fix đã đắt hơn nhiều. Nguyên tắc của agentic QA workflow là: mọi artifact AI sinh ra phải được validate trong feedback loop nhanh nhất có thể, và kết quả đó phải trở thành context cho vòng lặp tiếp theo (retry, fix, hoặc escalate — chuyển lên cho con người xử lý).

Validate ngay tại local

Ngay sau khi test được generate và fix các lỗi cơ bản ở bước trên, chạy full suite mới sinh (không phải toàn bộ regression suite) ở mode nhanh nhất có thể:

npx playwright test e2e/checkout/apply-voucher.spec.ts --workers=4 --reporter=json > /tmp/e2e-result.json

Capture pass/fail summary ngắn gọn, ví dụ script tổng hợp:

node -e "
const r = require('/tmp/e2e-result.json');
const stats = r.suites.flatMap(s => s.specs).reduce((acc, s) => {
  acc[s.ok ? 'pass' : 'fail']++; return acc;
}, {pass: 0, fail: 0});
console.log(\`PASS: \${stats.pass}, FAIL: \${stats.fail}\`);
"

Nếu có fail, chạy AI triage ngay lập tức (dùng kỹ thuật triage đã học ở bài về failure analysis) — đừng để test fail nằm im chờ người review test plan quay lại xử lý sau vài giờ. Feedback loop ngắn giữ được context "nóng": AI vừa mới sinh ra test này, vừa mới đọc codebase context này, nên nó sửa lỗi chính xác hơn nhiều so với việc bạn quay lại debug sau một ngày.

Mẹo: Đặt ngưỡng rõ ràng cho auto-retry: nếu AI tự sửa lỗi generation (import sai, method thiếu) quá 2 lần mà vẫn fail, dừng loop và escalate cho con người — đừng để AI tự sửa test đến vô hạn lần, vì rất dễ dẫn đến tình trạng AI "sửa" bằng cách làm yếu assertion đi (weaken assertion) để test pass giả, chứ không sửa đúng root cause.

Tích hợp CI để chạy ngay khi có PR

Sau khi test pass ổn định ở local, wire nó vào CI để chạy tự động mỗi khi PR liên quan được mở hoặc update — không chờ đến nightly regression run:

name: Generated Test Execution

on:
  pull_request:
    paths:
      - 'e2e/**'
      - 'api-tests/**'
      - 'src/**'

jobs:
  run-generated-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - name: Run E2E tests (generated + existing)
        run: npx playwright test --reporter=json --output=playwright-results.json
        continue-on-error: true

      - name: Run API tests
        run: npx jest api-tests --json --outputFile=api-results.json
        continue-on-error: true

      - name: Upload results as artifact
        uses: actions/upload-artifact@v4
        with:
          name: qa-generated-test-results
          path: |
            playwright-results.json
            api-results.json

      - name: Fail build on real failures (not flaky retries)
        run: node scripts/evaluate-test-results.js

Mẹo: Đừng để job này continue-on-error: true xuyên suốt pipeline chính — dùng nó chỉ để đảm bảo bạn luôn upload được artifact kết quả dù test fail, nhưng vẫn có một step cuối (evaluate-test-results.js) quyết định fail build thật. Nếu không, generated test đang flaky sẽ lặng lẽ mất khả năng chặn merge mà không ai để ý.

Feed kết quả CI ngược vào loop

Đây là bước khép vòng loop agentic — kết quả CI không chỉ để xem, nó phải trở thành input cho bước tiếp theo trong quy trình:

• Cập nhật context của loop với kết quả CI — khi AI agent tiếp tục xử lý (ví dụ sinh thêm test cho scenario khác, hoặc fix test đang fail), luôn đưa vào prompt: "CI run #1234 kết quả: 8 pass, 2 fail. Failure detail: [log]". Điều này giữ cho agent không lặp lại lỗi đã biết.
• Commit kết quả vào thư mục qa-artifacts/ — lưu lại snapshot kết quả run (JSON hoặc summary markdown) theo timestamp hoặc theo PR number, để có audit trail (nhật ký truy vết) và để agent các lần sau có thể tham chiếu lịch sử flakiness của một test cụ thể:

mkdir -p qa-artifacts/2026-07-09
cp playwright-results.json qa-artifacts/2026-07-09/pr-482-e2e-results.json
git add qa-artifacts/2026-07-09/pr-482-e2e-results.json
git commit -m "test(qa-artifacts): record generated E2E results for PR #482"

Việc lưu artifact này không chỉ để phục vụ traceability (khả năng truy vết nguồn gốc) — nó là dữ liệu huấn luyện ngầm cho chính bạn và cho AI: sau vài tháng, bạn có thể hỏi AI "test nào trong qa-artifacts/ có tỷ lệ fail cao nhất trong 30 ngày qua" để tìm ra test đang flaky cần refactor.

Làm sao để commit và duy trì automated test do AI sinh ra như một phần của workflow?

Test AI sinh ra mà không được quản lý như code thật thì sẽ nhanh chóng trở thành "shadow codebase" — không ai biết nó từ đâu ra, không ai dám sửa, và cuối cùng bị skip hoặc xóa khi gây rối. Coi generated test như bất kỳ contribution nào khác: cần convention rõ ràng, cần attribution (ghi rõ nguồn gốc/tác giả), và cần một nơi tổng hợp để biết cái gì đang tồn tại.

Convention commit cho test AI sinh ra

Attribution rõ ràng trong commit message giúp team biết test nào cần review kỹ hơn (vì có khả năng chứa lỗi generation) và giúp truy vết khi cần điều tra một test đang flaky:

git commit -m "$(cat <<'EOF'
test(checkout): add E2E coverage for voucher discount cap and stacking rules

Generated via AI from approved test plan (Stage 2, PR #480) using
existing CheckoutPage.ts patterns. Manually reviewed and validated
locally (4/4 passing) before commit.

AI-Generated-From: qa-artifacts/2026-07-09/test-plan-voucher.md
Reviewed-By: dat.hoang@youthdev.net
EOF
)"

Mẹo: Đưa attribution vào trailer (dòng metadata cố định ở cuối commit message) có format cố định (AI-Generated-From:, Reviewed-By:) chứ không phải văn xuôi tự do — để sau này bạn có thể git log --grep="AI-Generated-From" và thống kê được bao nhiêu % test suite hiện tại là AI-generated, phục vụ báo cáo hoặc audit chất lượng.

Section duy trì trong CLAUDE.md

Duy trì một section cố định trong CLAUDE.md (hoặc file hướng dẫn tương đương của project) liệt kê rõ những gì đã được AI generate, để agent ở lần sau (hoặc đồng nghiệp) biết ngay đâu là test cần cẩn trọng khi động vào:

## AI-Generated Test Files

### E2E Tests
- `e2e/checkout/apply-voucher.spec.ts` — generated 2026-07-09, source: PR #480
- `e2e/checkout/flash-sale-stacking.spec.ts` — generated 2026-07-02, source: PR #465

### API Tests
- `api-tests/cart/apply-voucher.test.ts` — generated 2026-07-09, source: PR #480

### Maintenance Notes
- All files above use `CheckoutPage.ts` and `apiClient.ts` helpers — update
  those helpers first if selectors or auth flow change, generated tests
  should not need direct edits for infra changes.
- If a code change breaks any file above, prefer re-generating via the
  E2E/API generation prompt (see module-8 topic 4) with updated codebase
  context, rather than hand-patching, to keep prompt-to-test traceability.
- Review this list quarterly; remove entries once a test has been
  hand-edited significantly (it's no longer "purely AI-generated").

Mẹo: Đừng để section này trở thành nghĩa địa — thêm dòng "Review this list quarterly" và thực sự làm nó. Một danh sách "AI-Generated Test Files" không ai cập nhật sau 6 tháng còn tệ hơn không có, vì nó tạo cảm giác an toàn giả (false confidence) rằng bạn đang track được nguồn gốc test, trong khi thực tế đã lệch xa thực tế.

Duy trì test đã sinh sau khi ứng dụng thay đổi

Tình huống chắc chắn sẽ xảy ra: một code change hợp lệ (đổi UI, đổi API contract) làm vài generated test bị fail — không phải vì bug, mà vì test đã lỗi thời. Đây là lúc entry trong CLAUDE.md phát huy giá trị: bạn (hoặc agent) tra cứu ngay được test này sinh ra từ đâu, dùng helper nào, và nên re-generate hay patch tay.

Quy trình xử lý khi "một code change làm hỏng những test này":

1. Xác nhận đây là lỗi do thay đổi hợp lệ (không phải regression thật) — kiểm tra changelog/PR gây ra thay đổi.
2. Tra CLAUDE.md section trên để biết test được sinh từ prompt nào, dùng context nào.
3. Cập nhật lại CODEBASE CONTEXT trong prompt gốc (Page Object mới, schema API mới) và re-run generation prompt, thay vì sửa tay từng assertion — giữ nguyên nguyên tắc "regenerate với context mới" đã ghi trong Maintenance Notes.
4. Chạy lại theo quy trình validate ở phần 3 (local run, fix lỗi generation, chạy CI).
5. Cập nhật lại ngày "generated" trong CLAUDE.md và note ngắn về lý do re-generate, để lịch sử thay đổi minh bạch.

Mẹo: Nếu một generated test bị hỏng do thay đổi hợp lệ nhiều hơn một lần trong vài tuần, đó là dấu hiệu feature đó chưa đủ ổn định để automate (quay lại yếu tố "Stability" trong Four-Factor Framework ở đầu bài) — hạ nó về MANUAL tạm thời thay vì cứ regenerate liên tục, tốn effort mà không tạo giá trị bền vững.

Tổng kết

Sinh test tự động bằng AI chỉ tạo ra giá trị thật khi nó được gắn chặt vào một quy trình có kỷ luật: quyết định automate dựa trên framework rõ ràng, cung cấp đủ codebase context để test sinh ra chạy được ngay từ lần đầu, validate và feed kết quả ngược vào loop trong CI, và duy trì nó như bất kỳ tài sản code nào khác — có attribution, có tài liệu, có quy trình cập nhật. Bỏ qua bất kỳ mắt xích nào trong bốn mắt xích này, bạn sẽ có một bộ test AI-generated trông hoành tráng trong demo nhưng mục ruỗng và mất niềm tin của team chỉ sau vài sprint.