Something went wrong!
Hang in there while we get back on track
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:
- Users complete checkout from cart to confirmation in 5 steps or fewer
- Users complete checkout without errors on first attempt in 85% of cases
- Cart items and totals are visible within 1.5 seconds of navigation for 95% of users
- Error messages display in plain language (no error codes), state the specific problem, and provide next steps to resolve
- Error messages appear adjacent to the field with the error, use contrasting color (WCAG AA compliant), and include an icon
- Users successfully resolve errors and complete checkout within 2 attempts in 90% of cases where errors occur
Quality Improvement: From 33% testable → 100% testable
About This Skill
Transform vague acceptance criteria into specific, testable conditions with measurable pass/fail thresholds.
View Skill DetailsMore Examples
API Endpoint with Mixed Testability
Demonstrates handling criteria that are already partially testable (response time, error rate) alongside vague ones ('gracefully', 'scalable'), showing how the skill enhances existing metrics while rewriting subjective terms.
Mobile App Onboarding Experience
Transforms mobile-specific vague criteria ('engaging', 'intuitive', 'smooth', 'reasonable') into testable conditions using FPS, milliseconds, completion rates, and device-specific benchmarks.