Transparency & Verification

Tenereteam Coupon Testing Methodology

This methodology explains how Tenereteam records checkout-based coupon tests, how shopper reports are treated as a separate evidence source, how results are classified, and the limits of what any single test can prove.

Methodology version: 2.0Applies to Code Test HistorySeparates shopper and editor evidence

1. Purpose

Tenereteam's testing methodology is designed to document observable coupon behavior at checkout. The goal is to make each recorded test understandable: what code was tested, what product or cart was used, what result appeared, when the test happened, and what evidence was available.

2. Scope

This methodology applies to Tenereteam/editor checkout tests shown in Code Test History. Shopper-submitted reports in Community Verified are a separate evidence source and should not be described as editor tests.

A checkout test may stop before payment or order submission. The purpose is to verify the coupon behavior shown by the merchant's checkout flow, not to complete a purchase unless a separate internal process requires it.

3. Evidence sources

Tenereteam Checkout TestsEditor/staff observations from a specific merchant checkout session, including product/cart context, result, timestamp, and available evidence.
Shopper ReportsCommunity feedback showing whether shoppers recently reported that a code worked and, where available, how much they reported saving.

These sources are intentionally kept separate. Tenereteam does not treat a shopper report as a substitute for an editor test, or an editor test as a substitute for shopper consensus.

4. Testing procedure

  1. Identify the offer. Review the coupon code and the advertised benefit.
  2. Select a product or cart. Choose one or more items that reasonably allow the offer to be evaluated.
  3. Open the checkout flow. Add the selected items to cart and proceed to the point where a coupon can be entered.
  4. Submit the code. Enter the code in the merchant's promo, coupon, or discount field.
  5. Observe the response. Record whether the code is accepted, rejected, restricted, or produces a different result.
  6. Verify the financial effect. Where visible, record original subtotal, eligible items, discount amount, and final total.
  7. Record the test. Save timestamp, tester/editor attribution, product/cart context, result, and evidence when available.

5. Product & cart selection

The product or cart used in a test matters because coupon eligibility is often product-specific. A code may apply only to a category, full-price merchandise, a first order, selected products, or carts above a minimum value.

When useful, we may test multiple products in the same cart and record which items received the discount and which did not.

6. The Checkout Test Record

Each test can be represented as a structured Checkout Test Record. Depending on what the merchant exposes during checkout, a record may contain:

FieldPurpose
Test resultWorked, Failed, Restricted, or Unverified.
Coupon codeThe exact code entered.
Advertised offerThe expected benefit before testing.
Product(s) / cart testedThe checkout context used for the test.
Eligible itemsWhich cart items received the discount.
Observed savingsThe discount amount or benefit shown by the merchant.
Final totalThe checkout total after the observed discount.
Tester/editorThe person responsible for the recorded test where applicable.
TimestampWhen the result was observed.
Checkout evidenceScreenshot or other evidence supporting the recorded result, when captured.
Test IDAn internal reference for the specific recorded test.

7. Result classifications

✓ WorkedThe code was accepted and the expected discount or benefit was observed.
✕ FailedThe code was rejected or produced no observable discount.
RestrictedThe code was recognized but eligibility was limited by product, customer type, minimum spend, region, or another condition.
UnverifiedNo reliable conclusion could be reached because the checkout flow or another condition prevented a valid test.

8. Decision rules

Observed checkout outcomeDisplayed result
Code accepted and advertised benefit is observedWorked
Merchant rejects the code or no discount is producedFailed
Code works only for some tested products/customers/conditionsRestricted
Test cannot produce a reliable conclusionUnverified

9. Checkout evidence

When available, Tenereteam may capture evidence supporting the recorded result. Evidence may show the coupon field, merchant response, selected products, discount line, or final cart total.

If no screenshot was captured, the test record should say so rather than implying that visual evidence exists.

10. Privacy and evidence redaction

Checkout evidence should be limited to information needed to verify the coupon result. Personal or sensitive information should not be displayed publicly.

  • Names, email addresses, shipping addresses, account information, and payment details should be excluded, cropped, blurred, or redacted where necessary.
  • Redaction should preserve the parts of the evidence needed to understand the coupon result.
  • Evidence should correspond to the specific test record it supports.

11. Tester and editor attribution

Where a test is attributed to a named Tenereteam editor or staff member, that attribution should identify the person responsible for performing, reviewing, or recording the test according to Tenereteam's internal workflow.

Names, avatars, and job titles should not be used to create the appearance of a specific human test if the test was not actually associated with that person.

12. Freshness and retesting

Coupon behavior can change quickly. Recent evidence is generally more useful than old evidence, which is why every test is time-stamped.

Codes may be retested when older results become stale, when a merchant appears to change an offer, when shopper reports conflict with a previous result, or when the code's behavior appears inconsistent.

Tenereteam displays freshness signals separately rather than combining all evidence into a single universal confidence score.

13. Conflicting evidence

Editor tests and shopper reports can disagree. That does not necessarily mean one source is wrong. Coupon eligibility may differ by product, account, customer status, region, or timing.

When evidence conflicts, Tenereteam may show the sources separately and retest the code. Examples include:

  • Editor test worked; shopper reports are mixed.
  • Shopper reports show recent success; latest editor test failed.
  • Code works on some products but not others.

14. Historical records

Code Test History may include successful and unsuccessful tests. Failed or changed results are retained when they help document how the code behaved over time.

A genuine test history should not show only successful examples.

15. When no working code can be verified

Sometimes Tenereteam cannot confirm that any currently available coupon code is working. When that happens, the store page may state that no currently verified working code is available rather than presenting an unverified code as working.

Other legitimate savings opportunities—such as first-order offers, email sign-up discounts, newsletter offers, or store sales—may still be shown separately when they are supported.

16. What a test does not prove

  • A successful test does not prove the code will work for every shopper.
  • It does not prove every product is eligible.
  • It does not prove the code will remain active indefinitely.
  • It does not prove the same result applies in every country, account, or customer segment.
  • It does not override personalized, account-specific, or merchant-controlled eligibility rules.
Preferred wording: describe observed results—for example, "worked during our test" or "10% was applied at checkout"—rather than implying universal eligibility.

17. Limitations of coupon testing

A checkout test cannot reproduce every shopper's situation. Results may vary because of account status, region, product selection, minimum order value, sale exclusions, one-time-use rules, merchant A/B tests, or changes made after the recorded test.

For that reason, every test should be interpreted as a dated checkout observation rather than a permanent guarantee.

18. Corrections and updates

If Tenereteam learns that a test record contains incorrect information—for example, the wrong product, amount, status, timestamp, attribution, or evidence—the record should be corrected or removed.

Historical records should remain clearly dated so shoppers can distinguish past observations from current coupon availability.

19. Frequently asked questions

Does "Worked" mean the coupon will work for everyone?

No. It means the code worked in the checkout test shown. Eligibility can vary by shopper, product, cart, region, or merchant rules.

Why show "Restricted" instead of "Failed"?

Because a code that works only for selected products or customers is different from a code that is rejected completely.

Why include failed tests?

Because the purpose of Code Test History is to document outcomes, not only successful examples.

Why show the product tested?

Product context helps shoppers understand what the code was actually tested on and whether the observed discount applied to the entire cart.

Do you always have checkout screenshots?

No. If evidence was not captured, the test record should make that clear.

How is this different from Community Verified?

Community Verified summarizes shopper reports. Code Test History documents Tenereteam/editor checkout tests. They are separate evidence sources.