testmorrow.Request a quote

A sample
testing report.

What happened, why it matters and how to repeat it. This is the detail your team needs to start investigating.

Finding 01HIGH PRIORITY

Payment taken.
Order missing.

A customer sees a successful payment, but cannot find their purchase in order history. This creates uncertainty, support requests and a risk of duplicate purchases.

Download this example

Expected result

After a successful payment, the order appears in the customer’s account with the correct amount and status.

Actual result

The confirmation screen reports success, but order history remains empty after refresh and a fresh sign-in.

Steps to reproduce

  1. Sign in to the test version of the app as a customer.
  2. Add Form study / 001 to the basket.
  3. Pay using the payment provider’s test option.
  4. Wait for the confirmation screen.
  5. Open Account → Order history and refresh.
  6. Sign out, sign in again, and check order history. The order is still absent.

Test evidence & environment

PASS  basket.total             $80.00
PASS  payment.completed        200
PASS  confirmation.displayed   OK
FAIL  order.history            []
RETRY fresh session            []

Reproduced: 3 / 3 attempts
Browser: Chrome / Desktop
Environment: Staging / fictional Orbit app

What to check next

Check why the successful payment did not create an order. These tests show the problem, but not its cause in the code. After a fix, check the payment, confirmation and order history together.

Finding 02MEDIUM PRIORITY

Password reset.
A blank page.

A customer who opens an expired password reset link has no explanation or visible way to request a new link. Account recovery stops at a blank screen.

Download this example

Expected result

Show a clear expired-link message and a way to request a fresh password reset email.

Actual result

The link opens a blank page. There is no explanation or button to request a new link.

Steps to reproduce

  1. Create and confirm an account in the test version of the app.
  2. Request a password reset email.
  3. Use an expired reset link prepared for this test.
  4. Open the link in a new browser window.
  5. Check for an explanation and a way to request a new link. Neither appears.

Test evidence & environment

PASS  account.created          201
PASS  email.verified           OK
PASS  reset.requested          202
FAIL  expired.link.content     EMPTY
FAIL  recovery.action          NOT FOUND

Reproduced: 3 / 3 attempts
Browser: Chrome / Desktop
Environment: Staging / fictional Orbit app

What to check next

Add an explicit expired-link state with a fresh reset request. Retest expired, already-used and valid reset links, including a fresh browser session.

Finding 03HIGH PRIORITY

A saved change
disappeared.

A customer believes their project changes were saved, but the data is lost on refresh. The success message creates false confidence and repeated work.

Download this example

Expected result

A successful save keeps the new project name after the page reloads or the customer signs in again.

Actual result

The interface shows “Saved”, but a reload restores the previous project name.

Steps to reproduce

  1. Sign in to the test version of the app as a project owner.
  2. Create a project named “Launch plan”.
  3. Rename the project to “Launch plan v2”.
  4. Select Save and observe the success message.
  5. Reload the page.
  6. Check the name. It has reverted to “Launch plan”.

Test evidence & environment

PASS  project.created          201
PASS  project.name.edited      Launch plan v2
PASS  save.toast               Saved
FAIL  project.name.afterReload Launch plan

Reproduced: 3 / 3 attempts
Browser: Chrome / Desktop
Environment: Staging / fictional Orbit app

What to check next

Check whether the save actually updates the stored project name. Show a success message only when the change is saved. Test again after reloading the page and signing in again.

Finding 04HIGH PRIORITY

The payment button
is cut off.

A customer on a small screen cannot see the whole payment button. They have entered their details but cannot easily finish paying.

Download this example

Expected result

The payment button fits the screen and can be used without scrolling sideways.

Actual result

On a 390 px wide screen, the button is cut off on the right, hiding part of its text and arrow.

Steps to reproduce

  1. Open the test app at a screen size of 390 × 844 px.
  2. Add an item and go to checkout.
  3. Complete the address fields.
  4. Close the phone keyboard.
  5. Look at the payment button at the bottom of the form.
  6. The right edge of the button is cut off.

Test evidence & environment

PASS  viewport.width           390 px
PASS  basket.navigation        OK
PASS  address.form             COMPLETE
FAIL  payment.control.width    440 px
FAIL  horizontal.overflow      50 px

Reproduced: 3 / 3 attempts
Browser: Mobile Safari / 390 × 844
Environment: Staging / fictional Orbit app

What to check next

Make the payment button fit the screen. Check at 320, 390 and 430 px wide, with the text zoomed in and with the phone keyboard open.

What could this
reveal in your app?

Request a testing quote