All examples for Acceptance Criteria Testability Checker

E-commerce Shopping Cart Checkout

Analyzes vague web checkout criteria ('easy', 'quickly', 'clear') and transforms them into measurable conditions with step counts, time thresholds, and error handling specifications.

Input

What you provide to the skill

User story: shopping cart. Criteria: checkout should be easy, page should load quickly, errors should be clear

Output

What the skill generates for you

Acceptance Criteria Analysis: Shopping Cart Feature

Criterion 1: “Checkout should be easy”

Status: ❌ NOT TESTABLE
Issues:

  • “easy” is highly subjective (easy for whom? compared to what?)
  • No specific checkout steps or interactions defined
  • No measurable usability metric

Testable Rewrites:
Option A (Task Completion):
“Users complete checkout from cart to confirmation in 5 steps or fewer”

  • Measurable: Yes (5 steps max)
  • Observable: Yes (can count clicks/screens)
  • Specific: Yes (defines checkout flow simplicity)

Option B (Time-Based):
“Users complete checkout within 90 seconds for 80% of transactions (returning customers with saved payment info)”

  • Measurable: Yes (90 seconds, 80% threshold)
  • Observable: Yes (can track time from cart to confirmation)
  • Specific: Yes (defines completion time and user segment)

Option C (Error Rate):
“Users complete checkout without errors on first attempt in 85% of cases”

  • Measurable: Yes (85% success rate)
  • Observable: Yes (can track failed vs successful checkouts)
  • Specific: Yes (defines success as error-free completion)

Recommendation: Use Option A + Option C to define both simplicity (steps) and success rate (error-free completion)


Criterion 2: “Page should load quickly”

Status: ❌ NOT TESTABLE
Issues:

  • “quickly” is subjective (quick for who? on what connection?)
  • No measurable time threshold
  • Doesn’t specify which page or what “load” means (initial render, fully interactive, etc.)

Testable Rewrites:
Option A (Initial Load):
“Shopping cart page displays above-the-fold content within 2 seconds on standard broadband (25 Mbps)”

  • Measurable: Yes (2 seconds, specific network speed)
  • Observable: Yes (can be timed)
  • Specific: Yes (defines what loads and under what conditions)

Option B (Perceived Performance):
“Cart items and totals are visible within 1.5 seconds of navigation for 95% of users”

  • Measurable: Yes (1.5 seconds, 95% threshold)
  • Observable: Yes (can measure time to meaningful content)
  • Specific: Yes (defines critical content and success rate)

Option C (Full Interactivity):
“Cart page becomes fully interactive (buttons clickable, quantity editable) within 3 seconds”

  • Measurable: Yes (3 seconds)
  • Observable: Yes (can verify interactive state)
  • Specific: Yes (defines fully functional state)

Recommendation: Option B (focuses on user perception of key content, which matters most for shopping cart)


Criterion 3: “Errors should be clear”

Status: ⚠️ PARTIALLY TESTABLE
Issues:

  • “clear” is somewhat subjective
  • Doesn’t specify what error types or how clarity is measured
  • Good intent but lacks specific verification criteria

Testable Rewrites:
Option A (Error Message Content):
“Error messages display in plain language (no error codes), state the specific problem, and provide next steps to resolve”

  • Measurable: Yes (presence of three components: problem, plain language, resolution)
  • Observable: Yes (can verify message structure)
  • Specific: Yes (defines content requirements)

Option B (Error Visibility):
“Error messages appear adjacent to the field with the error, use contrasting color (WCAG AA compliant), and include an icon”

  • Measurable: Yes (location, color contrast ratio, icon presence)
  • Observable: Yes (visual verification)
  • Specific: Yes (defines placement and visual treatment)

Option C (Error Resolution):
“Users successfully resolve errors and complete checkout within 2 attempts in 90% of cases where errors occur”

  • Measurable: Yes (2 attempts, 90% threshold)
  • Observable: Yes (can track error resolution behavior)
  • Specific: Yes (defines effectiveness of error clarity through user success)

Recommendation: Use Option A + Option B + Option C for comprehensive error clarity (content, visibility, and effectiveness)


Summary

Original Criteria: 3 statements, 2 not testable, 1 partially testable (67% vague)
Testable Criteria Generated: 9 specific, measurable alternatives

Testability Standards Met:
✅ Clear pass/fail conditions for all criteria
✅ Measurable thresholds defined (seconds, percentages, counts)
✅ Observable behaviors specified (what QA can verify)
✅ No subjective terms remaining

Recommended Final Acceptance Criteria:

  1. Users complete checkout from cart to confirmation in 5 steps or fewer
  2. Users complete checkout without errors on first attempt in 85% of cases
  3. Cart items and totals are visible within 1.5 seconds of navigation for 95% of users
  4. Error messages display in plain language (no error codes), state the specific problem, and provide next steps to resolve
  5. Error messages appear adjacent to the field with the error, use contrasting color (WCAG AA compliant), and include an icon
  6. Users successfully resolve errors and complete checkout within 2 attempts in 90% of cases where errors occur

Quality Improvement: From 33% testable → 100% testable