QA Tester — Measure Undocumented Message Caps on Subscription Web App (Fixed Price)

Overview We run a subscription web app with an AI chat feature. Message limits are enforced on the backend and are not published anywhere in the UI or on the pricing page. We need those limits measured empirically — actual counts from actual test runs, not estimates or inferences from documentation. Test accounts on every tier will be provided. You will not pay for anything out of pocket. --- ## What you'll test **Tiers:** - Tier A subscription - Tier B subscription **Top-off purchases (add-on message packs):** - $2.99 pack - $4.99 pack **Message lengths — every scenario runs twice:** - Short: ~10–15 words per message - Long: ~100 words per message ---- question text will be provided. The cap may be usage-based rather than a flat message count, so longer messages may consume the allowance faster. Both lengths must be measured and reported separately. **Test matrix: 8 runs total** (2 tiers × 2 lengths, plus 2 top-off packs × 2 lengths). --- ## Also capture 1. **Warning behavior** — does any warning, banner, or counter appear before the cap is reached, or does it hit with no notice? Record the message number at which any warning appears. 2. **Top-off stacking** — when a top-off is purchased with messages still remaining, does the new balance add to the remainder or replace it? 3. **Billing cycle reset** — does the counter reset correctly at the start of a new cycle? 4. **Mid-cycle plan change** — does the counter behave correctly when a user upgrades or downgrades mid-cycle? Record what happens to unused messages and to any active top-off balance. --- ## Deliverables 1. **Written test log** (Google Doc or Markdown) containing: - Exact message count at which the cap fired, for each tier and each top-off, at both message lengths - Message number at which any warning appeared, or a note that none did - Findings for stacking, cycle reset, and mid-cycle plan change - Approximate word/character count sent per run so results can be checked against usage-based math - Date, time, and account used for each run 2. **Screenshots** of the cap prompt and any pre-cap warning, for every scenario. Full-window captures with any visible counter or balance indicator included. 3. Any anomalies observed — miscounts, prompts that fire early or late, balances that don't match, errors. --- ## Requirements - Prior QA or software testing experience with a written deliverable you can point to - Careful, literal record-keeping. The value of this project is entirely in the accuracy of the numbers. - Test messages should be neutral, generic conversational content. Do not send anything related to medical emergencies, distress, or crisis language — the app has safety routing that will interfere with the count. - You will have access to a pre-launch product. A mutual NDA is required before test credentials are issued. - English proficiency sufficient to write a clear, organized report. --- ## Not included Bug fixing, code review, load or performance testing, and recommendations on limit structure are outside this project. --- ## To apply Please include: 1. Your fixed-price quote for the full scope above. 2. Your estimated turnaround time. 3. One example of a test log or QA report you've produced (redacted is fine). 4. How you would handle the billing cycle reset test given it may require waiting for a real cycle boundary. Quotes without a number will not be reviewed.