WHAT9S

Sample Site Check report

practicesoftwaretesting.com

A public demo store built for testing practice, not a customer. Tested Oct 15, 2026 on desktop and mobile.

Download the PDF
WHAT9S Site Check: practicesoftwaretesting.com
Tested: Oct 15, 2026 · Delivered within 48 hours
4 / 9 nines
YOUR 9s SCORE
4 / 9 — Struggling: several serious problems across your flows.
Coverage: 5 flows × desktop + mobile · Every scored bug reproduced twice
This is a sample report, not a customer. practicesoftwaretesting.com is a public demo store (the “Toolshop” app, version 2.5) built for people to practice software testing. We ran a standard Site Check on it on Oct 15, 2026 so you can see exactly what a report looks like. We used our own test accounts and Cash on Delivery test orders only. No real payment details were entered.

How each flow went

FlowDesktopMobileWorst issue
Signup / login7/7 stepsCompleted with issuesMajorbug 1
Contact formCompleted with issuesCompleted with issuesMinorbug 4
Search, browse & product page5/5 steps3/3 steps—
Cart → checkout
Cash on Delivery, test orders		Completed with issuesCompleted with issuesMajorbugs 1, 2, 3
Menus & navigation
incl. mobile menus		2/2 stepsCompleted with issuesMinorbugs 5, 6

every step passedfinished, but with problemscouldn’t finish (none this time)

Blockercan’t finishMajorworkaround or wrong resultsMinorannoying, still worksCosmeticlooks wrong only

Step counts appear only where every step had a clear pass or fail.

Top 3 fixes money and lead paths first, then biggest point gain

  1. 1
    Stop the address lookup from overwriting the address people type
    Signup and checkout · desktop + mobile·Major·+3.0 points
  2. 2
    Let checkout go through when someone corrects their billing address, and show a message if it can’t
    Checkout · mobile·Major·+1.5 points
  3. 3
    Tell people about the 50-character minimum before they press Send, or lower it
    Contact form · desktop + mobile·Minor·+1.0 point

No caps to lift, because we found no Blockers. Fix 3 ties with pre-filling the house number (also +1.0); we put the contact form first because it’s likely the quicker change. Together these three win back 5.5 points. On a re-test with nothing else changed, that would be a raw 6.75, so 6 / 9.

Your 9s score is WHAT9S's own 1–9 rating of how well your key user flows worked when we tested them. It is not an uptime percentage and does not measure availability, load, or security.

How we tested

DesktopGoogle Chrome in a full-size window (1920 × 1113 viewport).
MobileChrome’s built-in phone emulation at 390 × 844, the screen size of an iPhone 12 Pro. This is emulation in a desktop browser, not a physical phone.
Orders4 demo Cash on Delivery orders went through (2 on desktop, 2 on mobile). One more mobile order did not go through because of bug 2.
RuleWe only score a bug after we’ve seen it at least twice. Anything we saw once is listed separately and not scored.

The bugs we scored 6 bugs · 9 counts across devices · 0 Blockers

1

Invoices show a made-up billing address

Major · people can finish, but only with a workaround or wrong results

Desktop + MobileCart → checkout, and signup on mobile−1.5 desktop, −1.5 mobile

We used a real-looking address: Test St, Alamo, CA 94507. Every invoice came back with “Vivianne Island, Raphaelleton, Idaho” instead. On mobile we watched it happen: as soon as the house number is entered, the form’s automatic address lookup replaces Street, City and State with that fake address. It does this at signup and again at checkout. On desktop the billing form still showed Test St, Alamo, CA, but the invoice did not.

Steps to reproduce

  1. Register with country US, postal code 94507, house number 1, Test St, Alamo, CA.
  2. Add a Claw Hammer to the cart and check out with Cash on Delivery.
  3. Open My account → Invoices and open the new invoice.

Expected

The invoice shows the address you entered: Test St, Alamo, CA 94507.

Actual

Street “Vivianne Island”, City “Raphaelleton”, State “Idaho”. Postal code 94507 and country US are kept.

How often we saw it: Desktop: 2 of 2 orders (INV-2026000003, INV-2026000004). Mobile: 2 of 2 orders (INV-2026000005, INV-2026000006), and 2 of 2 at signup.

Desktop invoice INV-2026000003: the billing address reads Vivianne Island, Raphaelleton, Idaho.
Desktop invoice INV-2026000003: the billing address reads Vivianne Island, Raphaelleton, Idaho.
Mobile checkout: once house number 1 is typed, Street and City change to the fake address.
Mobile checkout: once house number 1 is typed, Street and City change to the fake address.
2

Confirm does nothing if you correct the billing address

Major · people can finish, but only with a workaround or wrong results

MobileCart → checkout−1.5 mobile

Because of bug 1, we changed the billing address back to Test St, Alamo, CA by hand. After choosing Cash on Delivery we pressed Confirm 4 times. Nothing happened on screen: no order and no error message. Behind the scenes, the server rejected the order each time (an error code 422, which means it refused the details it was sent). When we left the fake address in place instead, the order went through. So the only way to finish is to accept the wrong address.

Steps to reproduce

  1. Add an item to the cart and go to checkout.
  2. At Billing Address, replace the pre-filled street, city and state with Test St, Alamo, CA.
  3. Choose Cash on Delivery. “Payment was successful” appears.
  4. Press Confirm.

Expected

An order confirmation, or a clear message saying what needs fixing.

Actual

Nothing visible happens. The browser’s error log shows the order request rejected (422) on every press.

How often we saw it: Mobile: Confirm pressed 4 times in one checkout, rejected all 4 times. We compared it with the next order, which used the unchanged fake address and went through (INV-2026000006). We did not try a hand-corrected address on desktop.

Mobile: after pressing Confirm, the page stays on the payment step with no message.
Mobile: after pressing Confirm, the page stays on the payment step with no message.
3

House number isn’t filled in at checkout

Minor · annoying or confusing, still works

Desktop + MobileCart → checkout−0.5 desktop, −0.5 mobile

Street, city and state are filled in from the account, but the house number stays empty, and “Proceed to checkout” stays greyed out until you type it. The profile page has no house number field, so there’s no way to save it. On mobile, typing it is what sets off the address lookup in bug 1.

Steps to reproduce

  1. Register with house number 1.
  2. Add an item and go to checkout.
  3. Look at the Billing Address step.

Expected

House number is filled in like the other address fields.

Actual

House number is empty and the Proceed button is disabled until you type it.

How often we saw it: Desktop: 2 of 2. Mobile: 2 of 2.

Desktop billing step: House number is empty and “Proceed to checkout” is greyed out.
Desktop billing step: House number is empty and “Proceed to checkout” is greyed out.
4

Contact form refuses short messages

Minor · annoying or confusing, still works

May be on purposeDesktop + MobileContact form−0.5 desktop, −0.5 mobile

A short note (“Sample Site Check test, please ignore.”, 38 characters) was refused with “Message must be minimal 50 characters”. The rule only shows up after you press Send. It may be intentional, but it will surprise anyone sending a quick question.

Steps to reproduce

  1. Open Contact and choose the subject “Customer service”.
  2. Type a message under 50 characters.
  3. Press Send.

Expected

The message is sent.

Actual

Error: “Message must be minimal 50 characters”. A longer message did send.

How often we saw it: Desktop: 2 of 2. Mobile: 2 of 2 (30- and 27-character messages).

Desktop: the 38-character message is refused.
Desktop: the 38-character message is refused.
Mobile: a 30-character message gets the same error.
Mobile: a 30-character message gets the same error.
5

Invoices table is wider than the phone screen

Minor · annoying or confusing, still works

MobileMenus & navigation (My account)−0.5 mobile

On My invoices, the table runs past the right edge of the screen. You have to scroll sideways, and the “Details” button that opens each invoice is cut off. The other pages we checked (home, product, cart, checkout, contact and invoice details) fit the screen.

Steps to reproduce

  1. On a phone-size screen (390 px wide), sign in.
  2. Open My account → My invoices.

Expected

The table fits the screen or wraps.

Actual

A sideways scrollbar appears and the Details buttons are cut off.

How often we saw it: Mobile: 2 of 2.

Mobile: the Details buttons are cut off at the right edge, with a sideways scrollbar at the bottom.
Mobile: the Details buttons are cut off at the right edge, with a sideways scrollbar at the bottom.
6

Floating buttons cover content

Minor · annoying or confusing, still works

MobileMenus & navigation (every page)−0.5 mobile

Two round buttons float in the bottom corners of every page: a red “live activity” button on the left and a blue chat button on the right. On a phone they sit on top of things people need to read, including the login error message, product titles and details, and footer links.

Steps to reproduce

  1. Open the site on a phone-size screen.
  2. Try to sign in with a wrong password, or open any product page.

Expected

The buttons don’t hide any text.

Actual

The red button covers the start of “Invalid email or password” and parts of product pages.

How often we saw it: Mobile: on every page we visited.

Login: the red button covers the start of the error message. (Test account email blurred.)
Login: the red button covers the start of the error message. (Test account email blurred.)
Product page: the red button sits over a row label in the specifications.
Product page: the red button sits over a row label in the specifications.

Seen once, not scored

We only score a bug after we’ve reproduced it twice. These came up but didn’t meet that bar on any one device. They’re worth a look, and they don’t affect your score.

First click sometimes ignored · Seen once, not scored

Desktop: once on the contact form’s Send button and once on checkout’s Confirm button. Each worked on the next click. Mobile: once on the contact form’s Send button. Each sighting was a one-off on that button, so we haven’t confirmed it twice. (A mobile Confirm that seemed to “do nothing” turned out to be bug 2.)

Cart total briefly out of date · Seen once, not scored

After changing the quantity to 2, the line total showed $22.96 but the cart Total still showed $11.48 for a moment on desktop and for a few seconds on mobile, then corrected itself. Seen once on each device.

Empty cart shows no message · Noted once, not scored

On mobile, opening checkout with nothing in the cart shows only the step bar, with no “your cart is empty” message.

Mobile: checkout with an empty cart shows only the four steps.
Mobile: checkout with an empty cart shows only the four steps.

Health notes

Light checks on the pages we already visited. Each type of signal that shows up costs 0.25, up to 1.0 in total. If a signal actually hurts a flow, we log it as a bug instead, so nothing counts twice.

Console errorsCounted: −0.25These are errors in the browser’s behind-the-scenes log. Visitors don’t see them, but they can point to hidden problems. Desktop: one error on the profile page, both times we opened it (the two-factor QR code had no data to show). Mobile: “Cannot read properties of null (reading ‘cart_items’)” about 35 times during checkout. The 422 errors from bug 2 also appeared here, but they’re already counted in that bug.
Mobile layout breaksNot counted againThe invoices table (bug 5) and the floating buttons (bug 6) are already scored as bugs, so they don’t count twice.
Page loadsNot countedNothing felt slow. The slowest page we noted was login: about 2.7 s on desktop and about 1.9 s on mobile. This is what we saw while testing, not a speed test.
Broken links or imagesNot countedNone seen on desktop, and none noted on mobile. One small thing on mobile: a search briefly shows the full product list for about a second before the hammer results appear.

Appendix: how we got to 4 / 9

Scored bugSeverityDesktopMobile
Bug 1 · Invoice shows a made-up addressMajor−1.5−1.5
Bug 2 · Confirm fails after correcting the addressMajornot tried−1.5
Bug 3 · House number not filled inMinor−0.5−0.5
Bug 4 · Contact form refuses short messagesMinor−0.5−0.5
Bug 5 · Invoices table wider than the screenMinor—−0.5
Bug 6 · Floating buttons cover contentMinor—−0.5
Bug points by device−2.5−5.0
Health signals: console errors (1 type)−0.25
Raw score9 − 7.5 (bugs) − 0.25 (health) = 1.25
Round down1
CapsNone. No Blockers, so nothing caps the score lower.
No-blocker floorNo Blocker on any flow or device, so the score is at least 4.
Your 9s score4 / 9 · Struggling

Why the floor: on our scale, 3 and below always mean a visitor couldn’t finish a flow. Every flow here could be finished, though checkout on mobile only by keeping a fake address, so the score stops at 4. Severity points: Blocker −3.0, Major −1.5, Minor −0.5, Cosmetic −0.25. A bug counts once for each device it shows up on. Not scored: the three items seen only once (above).

WHAT9S · WHAT NINES DO YOU HAVE?