DevelopmentPayment protectionDetails
- Revisions within the package are free.
- If you do not respond within 3 days of delivery, the work is accepted automatically.
The money is reserved when you pay and released only once you accept the work.

Example result
Test cases: sign-up, cart and checkout of a small online tea shop
Cases from the "Checkout" area (4 of 18)
| ID | Title | Steps | Test data | Expected result | Priority |
|---|---|---|---|---|---|
| CO-01 | Order with a card, standard delivery | 1. Add 2 teas to the cart. 2. Open the cart, press Checkout. 3. Fill in the address, choose standard delivery. 4. Pay with the test card. | Test card from the payment provider's sandbox | The order page shows the number; a confirmation email arrives within 5 minutes | High |
| CO-04 | Free delivery threshold | 1. Add teas for $39.90. 2. Open checkout. 3. Add one more tea. | Shop rule: free delivery from $40 | Delivery shows $4.90, then $0.00 after step 3 | High |
| CO-09 | Postcode left empty | 1. Fill in every field but the postcode. 2. Press Pay. | — | The form is not sent; the postcode field is marked with a clear message | Medium |
| CO-15 | Back button after paying | 1. Pay for an order. 2. Press the browser's Back button. | — | No second charge; the cart is empty | High |
Checklist: cart (part)
- The quantity can be changed with + and − and typed in
- Removing the last item shows an empty cart message
- The cart is kept after closing the tab and coming back
- Prices and the total match the product pages
Files: an Excel workbook with the cases, a Result column and the checklists, and a Word file with the test plan. We write the cases from the description and screenshots; the shop's own people run them.
Client: Leaf & Kettle, an online shop selling about 80 kinds of loose tea, on its own site. Task: cases the shop owner and an assistant can go through before each update. Standard package: 60 cases in up to 4 areas, checklists and a short test plan. Excerpt below.
The client and all details are made up.
About this service
Test cases are written checks: for each one, the steps to follow, the test data, the expected result and the priority, so anyone can go through a site, app or program and spot what is broken. Describe what you built and what matters most, and send screenshots, a link to public pages, a user guide or a feature list. From that description we write the cases: what should work and what should be refused, edge cases, form checks, user roles and the devices and browsers you name. You get an Excel workbook with the cases and checklists and a column for results, and from Standard a Word file with the test plan; Premium adds a regression checklist and a bug report template. We write the cases; you or your people run them. We do not log in to, use or test your product ourselves, so the cases follow what you describe and show.
What is included
- What you getAn Excel workbook with your test cases: ID, area, title, preconditions, steps, test data, expected result, priority and an empty column for the result, plus a checklist for each area. From Standard, a Word file with a short test plan: scope, devices and browsers, order of work and what counts as done; in Premium, a full test plan, a regression checklist to repeat before every release and a bug report template.
- Steps and expected resultsClear enough for anyone to follow
- Positive and negative casesWhat should work and what should be refused
- Edge casesEmpty fields, long text, wrong formats and limits
- PriorityWhat to check first when time is short
- Devices and browsersThe ones you name, in the plan and the checklists
How it works
- 1DescriptionYou describe the product and send screenshots or a link
- 2CasesWe write the cases, checklists and plan from your description
- 3DeliveryYou get the Excel workbook and the Word file on the order page
- 4Your runYou or your people run the cases and note the results
What we need from you
What the site, app or program does and who uses it, the areas or flows to cover (e.g. sign-up, search, cart, payment, profile), the rules that matter (required fields, limits, prices, user roles), the devices, systems and browsers you support, and anything that broke before. Screenshots of each screen, a link to public pages, a user guide, a feature list or requirements help most: up to 5 files as images, Word, Excel or PDF. Never send passwords or real customer data.
We will ask you:
- What are the test cases for?
- Which areas or flows matter most?
- Which devices, systems and browsers do you support?
- Which rules must the product follow?
- What has broken before?
Compare packages
| Packages | Basic25 test cases, 1 area$15 | Standard60 test cases, up to 4 areas$35 | Premium120 test cases, up to 8 areas$69 |
|---|---|---|---|
| Deadline | 1 day | 2 days | 4 days |
| Revisions | 1 | 2 | 3 |
| Test cases | 25 | 60 | 120 |
| Areas or features | 1 | up to 4 | up to 8 |
| Checklists | 1 | up to 4 | up to 8 |
| Test plan | No | short | full |
| Regression checklist and bug report template | No | No | Yes |
| Order Basic | Order Standard | Order Premium |
Payment protection
You pay when you order, but the money is released only for accepted work.
- Fixed priceThe package price does not change after you pay.
- The money is reservedWhen you pay, the amount is only reserved. It is released to the service once you accept the work.
- Checked before deliveryEvery result goes through a quality check before it reaches you, and you see it on the order page before accepting it.
- Free revisionsAsk for changes within your brief as many times as the package allows.
- Acceptance after 3 daysIf within 3 days of delivery you neither accept the work nor ask for changes, it is accepted automatically. If you write in the order chat after delivery, the order waits; once we answer, we may start the 3 days again and will say so in the chat.
- Redo or a full refundIf the result does not match your brief and the revisions did not fix it, or the work takes more than twice its deadline, write in the order chat: we will redo the work or refund the payment in full.
Questions and answers
Will you test my site or app?
No. We write the test cases and checklists; you or your people run them and note what passes and what fails. We never log in to, use or test your product.
Do you need access to my product?
No. Screenshots of the screens and a description are enough; a link to public pages or documentation helps with names and structure. Do not send logins or passwords.
Can you cover a mobile app or a desktop program?
Yes. For apps we add checks for permissions, poor connection, interruptions and screen sizes; for programs, installation, files, settings and updates, all from what you describe.
Can I import the cases into my test tool?
The workbook is in Excel and opens in Google Sheets. Most test management tools import a CSV file, which you save from Excel in one step; you may need to match the column names.
Do test cases mean the product has no bugs?
No. They cover what you describe at the depth of your package; bugs outside the cases can remain, and the result depends on how carefully the cases are run.
Did not find your answer?


