Tiếng Việt: Equivalence partitioning, boundary analysis, and exploratory heuristics

Equivalence Partitioning (EP - phân vùng tương đương), Boundary Value Analysis (BVA - phân tích giá trị biên) và các heuristic khám phá (exploratory heuristics) như SFDPOT hay FCC CUTS VIDS là những kỹ thuật kinh điển trong test design. Chúng không mới, nhưng AI thay đổi cách chúng được áp dụng: từ việc một QA tự tay liệt kê từng partition/boundary trong nhiều giờ, sang việc AI làm phần liệt kê máy móc trong vài giây, còn QA tập trung vào việc kiểm tra tính đúng đắn và quyết định kỹ thuật nào áp cho ca nào. Bài này đi qua cách prompt AI cho từng kỹ thuật, cách kết hợp nhiều kỹ thuật trong một prompt, và một hướng dẫn chọn kỹ thuật theo tình huống.

Làm Thế Nào Để Dùng AI Tạo Equivalence Partition Sets từ Requirements?

Nguyên Lý Cốt Lõi AI Cần Để Làm Việc

EP hoạt động dựa trên giả định: nếu hai giá trị input thuộc cùng một "vùng" thì hệ thống xử lý chúng theo cùng một cách — do đó chỉ cần test đại diện, không cần test mọi giá trị. AI chỉ chia partition đúng khi nó biết ranh giới logic của hệ thống, không phải ranh giới "thường gặp". Vì vậy trước khi prompt AI chia partition, luôn cung cấp rule nghiệp vụ/kiểu dữ liệu rõ ràng — thiếu rule, AI sẽ chia partition theo trực giác chung (ví dụ mặc định coi số âm luôn invalid, dù hệ thống của bạn cho phép số âm biểu thị hoàn tiền).

Phân Tích Partition Cho Một Field Đơn

FIELD: discount_percent
TYPE: integer
RULE: valid range is 0-100 inclusive; values outside are rejected;
      values with decimals are rejected (integer only)

TASK: Identify all equivalence partitions for this field (valid and
invalid). For each partition, give one representative value and
explain why all values in that partition are expected to behave
the same way.

Output đúng sẽ tách rõ: partition hợp lệ (0-100), partition không hợp lệ dưới 0, partition không hợp lệ trên 100, và partition không hợp lệ do sai kiểu (có phần thập phân, không phải số). Nếu AI chỉ đưa ra "valid" và "invalid" mà không tách theo nguyên nhân invalid, đó là partition chưa đủ chi tiết.

Phân Tích Partition Cho Form Nhiều Field

Với form nhiều field, thử thách không phải là chia partition từng field (dễ), mà là tổ hợp các partition giữa field với field mà không nổ số lượng test case vô hạn. Prompt cần yêu cầu AI ưu tiên tổ hợp có ý nghĩa nghiệp vụ:

Given the fields and their partitions below, do NOT generate every
possible combination (that would explode). Instead, generate:
1. One test case per field where all OTHER fields are valid
   (isolates the effect of that field's partition)
2. A small number of "multiple invalid fields at once" cases only
   where the business rule says the first invalid field encountered
   determines the error shown (to verify error priority/order)

Phân Vùng Domain Không Phải Số (Non-Numeric)

EP không chỉ áp cho số. Với enum, chuỗi tự do, hay file upload, partition dựa trên loại giá trị chứ không dựa trên khoảng số:

• Enum (ví dụ status: draft/published/archived) → mỗi giá trị hợp lệ là 1 partition, cộng thêm 1 partition cho giá trị không tồn tại trong enum.
• Chuỗi tự do → partition theo: rỗng, chỉ khoảng trắng, chứa ký tự đặc biệt/emoji, chứa mã HTML/script (liên quan bảo mật), độ dài vượt giới hạn.
• File upload → partition theo: đúng định dạng & đúng size, đúng định dạng & sai size, sai định dạng (đổi đuôi file giả), file rỗng, file bị corrupt.

Mẹo: Khi field là enum, luôn nhắc AI thêm partition "giá trị không có trong enum nhưng vẫn đúng kiểu dữ liệu" (ví dụ gửi status = "deleted" khi enum chỉ có draft/published/archived) — đây là partition dễ bị AI quên vì nó dễ nhầm với case "sai kiểu dữ liệu".

Kiểm Chứng Lại Partition Do AI Tạo

Sau khi AI chia partition, đừng tin ngay — đối chiếu lại bằng cách hỏi ngược:

For each partition you identified, confirm: does every value inside
this partition truly produce the EXACT same system behavior? If a
partition might actually contain a hidden sub-boundary (e.g., a rate
limit that kicks in only after N valid requests), call it out.

Đây là bước bắt AI tự phản biện logic phân vùng của chính nó — hiệu quả trong việc phát hiện các partition "gộp quá tay".

Làm Thế Nào Để Tự Động Hóa Boundary Value Analysis với AI?

BVA Hai Giá Trị so với Ba Giá Trị

Có hai trường phái BVA: 2-value (chỉ test giá trị biên và giá trị ngay ngoài biên, ví dụ 100 và 101) và 3-value (test giá trị biên, giá trị ngay dưới và giá trị ngay trên, ví dụ 99, 100, 101). Khi prompt AI, luôn nêu rõ bạn muốn trường phái nào — nếu không, AI sẽ trộn lẫn không nhất quán giữa các field trong cùng suite.

Apply 3-value boundary analysis (below boundary, at boundary, above
boundary) for every numeric field. State explicitly which value is
"at boundary" and confirm it against the rule (inclusive vs exclusive).

Mẹo: Luôn hỏi rõ rule là "inclusive" hay "exclusive" (ví dụ max 100 có bao gồm 100 hay không) trước khi AI generate boundary — đây là nguồn sai sót phổ biến nhất trong BVA, cả với người và với AI.

BVA Cho Các Kiểu Dữ Liệu Khác Nhau

Boundary không chỉ nằm ở số nguyên. Với ngày/giờ, boundary quan trọng là ranh giới giữa các đơn vị thời gian (23:59:59 → 00:00:00, ngày cuối tháng, năm nhuận). Với chuỗi, boundary là độ dài ký tự (min/max) và số byte thực tế khi có ký tự Unicode đa byte (một emoji có thể chiếm nhiều "ký tự" theo cách đếm của hệ thống). Với file, boundary là kích thước file tính bằng byte thực tế, không phải MB làm tròn hiển thị trên UI.

For the "bio" field (max 280 characters, UTF-8 encoded), generate
boundary test cases that account for multi-byte characters (e.g.,
emoji or Vietnamese diacritics) potentially counting differently
than plain ASCII characters toward the 280-character limit.

Boundary Analysis Cho API Endpoint

Với API, boundary không chỉ nằm ở field mà còn ở pagination, rate limit, và timeout:

For this paginated API endpoint (page_size default=20, max=100),
generate boundary test cases for: page_size=0, page_size=1,
page_size=100, page_size=101, page=0, page beyond last available
page, and a request exactly at the rate-limit threshold followed by
one more request in the same window.

Kết Hợp EP và BVA Trong Một Prompt

EP xác định vùng nào cần test, BVA xác định giá trị cụ thể nào trong vùng đó đáng test nhất. Kết hợp cả hai trong một prompt giúp tránh việc BVA sinh ra giá trị nằm ngoài các partition đã xác định (hoặc bỏ lỡ boundary của một partition invalid):

Step 1: List all equivalence partitions for the field below.
Step 2: For each partition, identify the boundary value(s) that
sit at the edge of that partition.
Step 3: Output a single test set: one row per boundary value, with
its partition, the exact input value, and expected result.

Equivalence Classes

Đây là phần đầu ra kỳ vọng khi bạn chạy prompt kết hợp trên — một danh sách các vùng giá trị kèm mô tả hành vi mong đợi, dùng làm căn cứ cho bước Boundaries tiếp theo.

Boundaries

Danh sách giá trị biên cụ thể rút ra từ từng equivalence class ở trên — đây là phần cần review kỹ nhất vì sai lệch một đơn vị (off-by-one) là lỗi rất dễ xảy ra cả với AI.

Final Test Set

Bảng test case hoàn chỉnh, mỗi dòng ứng với một giá trị boundary, kèm partition tương ứng và expected result — sẵn sàng để đưa vào bước review chuẩn hóa trước khi import.

Làm Thế Nào Để Áp Dụng Exploratory Heuristics Như SFDPOT và FCC CUTS VIDS với AI?

Heuristic khám phá không sinh ra test case cụ thể ngay — chúng sinh ra câu hỏi định hướng để bạn hoặc AI khám phá tiếp. Vai trò của AI ở đây là giúp bạn áp mnemonic (từ viết tắt gợi nhớ) một cách đầy đủ, không bỏ sót chiều nào, đặc biệt khi bạn đang làm việc dưới áp lực thời gian và dễ quên vài chữ trong mnemonic.

Áp Dụng SFDPOT với AI

SFDPOT (Structure, Function, Data, Platform, Operations, Time) là heuristic của James Bach, thường dùng để lập charter cho exploratory testing session. Prompt hiệu quả nhất là yêu cầu AI đi qua từng chữ, hỏi câu hỏi thăm dò riêng cho feature cụ thể:

Apply the SFDPOT heuristic to this feature. For EACH of the 6
dimensions, ask 2-3 probing questions specific to this feature (not
generic questions), then convert each probing question into a
one-line exploratory test idea.

Structure

Câu hỏi thăm dò về cấu trúc: feature này gồm những thành phần kỹ thuật nào (UI component, API, DB table), và ranh giới giữa các thành phần đó có điểm nào dễ vỡ khi tách rời (ví dụ frontend validate khác backend validate).

Function

Câu hỏi thăm dò về chức năng: feature làm đúng những gì nó tuyên bố làm, và có chức năng phụ/ẩn nào đi kèm (ví dụ đổi avatar cũng ảnh hưởng tới cache CDN) mà requirement không nhắc tới.

Data

Câu hỏi thăm dò về dữ liệu: dữ liệu vào/ra có dạng gì, dữ liệu cũ (đã tồn tại trước khi có feature này) có tương thích với logic mới không.

Platform

Câu hỏi thăm dò về nền tảng: feature có hành xử khác nhau giữa các trình duyệt, hệ điều hành, kích thước màn hình, hoặc phiên bản app cũ chưa cập nhật không.

Operations

Câu hỏi thăm dò về vận hành thực tế: người dùng thực sự dùng feature này trong hoàn cảnh nào (mạng chậm, thiết bị cũ, đang làm việc khác song song) khác với môi trường test lý tưởng.

Time

Câu hỏi thăm dò về yếu tố thời gian: điều gì thay đổi nếu thao tác diễn ra rất nhanh (double click), rất chậm (để form mở cả ngày rồi mới submit), hoặc lặp lại nhiều lần liên tiếp.

Áp Dụng FCC CUTS VIDS với AI

FCC CUTS VIDS (Feature, Complexity, Claims, Users, Testability, Scenarios, Interoperability, Data, Structure — tùy biến theo từng người dùng heuristic này) là một mnemonic mở rộng hơn, tập trung nhiều vào rủi ro sản phẩm hơn là kỹ thuật. Cách prompt tương tự SFDPOT, nhưng nên nhấn thêm vào khía cạnh "Claims" (những gì marketing/PO tuyên bố feature làm được) và "Interoperability" (tương tác với feature khác) — đây là hai chữ hay bị bỏ sót nhất khi con người áp mnemonic này bằng tay, và AI có thể bù đắp tốt nếu được nhắc rõ.

Apply the FCC CUTS VIDS heuristic. Pay special attention to "Claims"
(what has been promised about this feature in the spec/marketing
copy that might not match actual behavior) and "Interoperability"
(how this feature might conflict with adjacent existing features).

Dùng Heuristic Để Tạo Charter Cho Exploratory Session

Sau khi có danh sách câu hỏi thăm dò, gộp lại thành charter (đề bài khám phá) ngắn gọn cho một session khám phá (thường 60-90 phút):

Convert the SFDPOT questions above into 3 exploratory testing
charters, each following this format:
"Explore [area] with [tools/data] to discover [risk/information]"
Keep each charter scoped to fit a 60-90 minute session.

Kết Hợp Nhiều Heuristic Để Tối Đa Coverage

Không cần chọn một heuristic duy nhất. Với feature có độ rủi ro cao, hãy áp cả SFDPOT (rủi ro kỹ thuật) và FCC CUTS VIDS (rủi ro sản phẩm) rồi yêu cầu AI loại bỏ trùng lặp giữa hai danh sách câu hỏi trước khi gộp thành charter cuối.

Mẹo: Đừng áp heuristic cho feature quá đơn giản (ví dụ một field text đơn thuần) — heuristic phát huy giá trị nhất ở feature có nhiều thành phần tương tác lẫn nhau; áp dụng tràn lan sẽ tạo ra charter rỗng, không có giá trị thăm dò thật.

Làm Thế Nào Để Kết Hợp Nhiều Kỹ Thuật Test Trong Một Prompt AI?

Mẫu Kết Hợp Kỹ Thuật (Technique Composition Pattern)

Khi một feature có độ rủi ro đủ cao (ảnh hưởng tài chính, dữ liệu người dùng nhạy cảm, logic phức tạp), một kỹ thuật đơn lẻ hiếm khi đủ. Mẫu kết hợp hiệu quả là chạy tuần tự: EP → BVA → heuristic rủi ro (SFDPOT), sau đó gộp lại và loại trùng.

Apply the following techniques in order, using the outputs of each
step as input to the next:
Step 1: Equivalence Partitioning on all numeric/enum fields
Step 2: Boundary Value Analysis on the partitions from Step 1
Step 3: SFDPOT heuristic questions focused on risk NOT already
        covered by Steps 1-2 (e.g., platform, timing, operations)
Then output a single consolidated test list with no duplicates,
tagging each test case with which technique produced it.

Technique 1: Equivalence Partitioning

Phần này của output liệt kê các partition đã xác định, làm nền cho BVA ở bước sau — review xem có partition nào chồng lấp (overlap) hay bỏ sót không trước khi qua bước tiếp theo.

Technique 2: Boundary Value Analysis

Phần này liệt kê giá trị biên rút ra từ các partition ở trên — kiểm tra kỹ inclusive/exclusive như đã nói ở phần BVA.

Technique 3: Risk-Based Heuristics (SFDPOT)

Phần này bổ sung các case mà EP/BVA không thể phát hiện (vì chúng liên quan đến platform, timing, hoặc tương tác giữa nhiều phần hệ thống) — đây là phần thường mang lại phát hiện bất ngờ nhất trong cả bộ.

Consolidated Analysis

Bảng test case cuối cùng, đã gộp và loại trùng, có gắn tag kỹ thuật gốc — dùng bảng này làm input cho bước review và import vào test management tool.

Kỹ Thuật Decision Table với AI

Khi logic nghiệp vụ có nhiều điều kiện kết hợp (ví dụ tính phí ship phụ thuộc vào cả khu vực, cả tổng giá trị đơn, cả loại thành viên), decision table (bảng quyết định) hiệu quả hơn EP/BVA. Prompt AI dựng decision table trước khi viết test case giúp đảm bảo mọi tổ hợp điều kiện quan trọng được xét tới:

Build a decision table with conditions as rows and rule columns
(one column per unique combination of condition outcomes that leads
to a different result). Collapse combinations that lead to the
same result into one rule column. Then generate one test case per
rule column.

State Transition Testing với AI

Với feature có trạng thái rõ ràng (đơn hàng: pending → paid → shipped → delivered/cancelled), state transition testing (kiểm thử chuyển trạng thái) tập trung vào chuyển trạng thái hợp lệ và chuyển trạng thái không hợp lệ (ví dụ từ delivered quay lại pending). AI cần được cho biết toàn bộ transition hợp lệ trước để suy ra transition không hợp lệ (những cặp không nằm trong danh sách hợp lệ):

VALID TRANSITIONS: pending->paid, paid->shipped, shipped->delivered,
pending->cancelled, paid->cancelled

TASK: List all invalid transitions (any state pair not in the valid
list above) and generate a test case per invalid transition
verifying the system rejects/blocks it.

Hướng Dẫn Chọn Kỹ Thuật Đầy Đủ

Không có kỹ thuật nào áp cho mọi tình huống. Bảng dưới đây tổng hợp khi nào nên chọn kỹ thuật nào:

Mẹo: Khi không chắc chọn kỹ thuật nào, hãy hỏi chính AI trước: "Given this feature description, which test design technique(s) would be most effective and why?" — câu trả lời của AI, dù không phải quyết định cuối cùng, thường là điểm khởi đầu hữu ích để bạn tự phản biện và quyết định.