Service

Reports and Retesting

A report is the whole of what you buy, so it is built to be acted on: sorted by priority, reproducible step by step, and checked again once you say the fixes are live.

What is done

What the work actually consists of

Written to be reproduced

Each finding names the page, the browser, the width and the device, then gives the steps, what should have happened and what did. A developer should be able to see it for themselves inside ten minutes, without writing back to ask which phone it was.

Sorted by priority, with the meaning of each given

High is something that cannot be read, reached or used. Medium is usable but harder, or looks broken. Low is worth putting right and stops nobody. The definitions are printed in the report, so the order of work is settled before anyone argues about it.

A matrix of what was covered

Every page against every configuration, so the report says what was looked at as clearly as it says what was found. A blank cell means it was looked at and nothing came up, not that it was skipped.

Retesting after the fixes

The findings you say you have fixed, on the pages they were found on, in the configurations they were found in. Each comes back marked gone, still present, or changed - and a fault that has moved rather than gone is written up again, because by then it is a different fault.

What you get back

The report as a document you keep, with the findings, the matrix and the definitions in it.
Screenshots attached or linked, at a resolution you can read.
The retested report, marked against the original, on the date agreed when you say the fixes are live.
A short summary of what repeats, so a component that causes six findings is fixed once.

What is not in it

A guarantee that a fix works everywhere it was not tested. A retest covers the configurations the fault was found in.
Continuous monitoring. A run is a run, on a date; watching a site over time is different work.
Access to a dashboard or an account on this site. There is no account to open here.

Saying what is not included is not modesty. A buyer who expects one of these and does not get it has bought the wrong thing, and that is the disagreement worth preventing before an order rather than after it.

The form a finding takes

One finding, in full

Every finding in every report looks like this. The steps are the part that saves the time: a developer should be able to see it for themselves without writing back to ask which handset it was.

F-01 High priority Sideways scroll

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The page can be dragged sideways by 28 pixels

Page: example.test/
Browser: Chrome (Blink)
Width: 360 px
Device: Samsung Galaxy S22 Held in the hand

Steps to reproduce

Open the home page on the Galaxy handset in Chrome.
Scroll to the band of three promotional cards.
Drag the page to the left.

Expected

Nothing moves. A page at this width has no second column to reveal.

Observed

The page slides 28 pixels and shows a strip of empty background. The third card keeps a left margin that is only cancelled at the tablet breakpoint, so at this width it pushes past the right edge and widens the document.

High 5 in the run shown

Something on the page cannot be read, reached or used at this size.

Medium 5 in the run shown

The page works, but it is harder to use or reads as broken.

Low 1 in the run shown

Worth putting right, and nothing is stopped by it.

Those three definitions are printed inside every report, so the order of work is settled before anyone has to argue about what urgent means.

After a fix

How a retest runs, and what it will not pretend

A retest looks at the findings you say you have fixed, on the pages they were found on, in the configurations they were found in. It is not the whole run again, and it does not claim to be.

What a retest looks at

The findings you say you have fixed, on the pages they were found on, in the configurations they were found in. Not the whole run again: a fault reported on one handset is confirmed on that handset.

What comes back

The same report with each retested finding marked as gone, still present, or changed. A finding that has moved rather than gone is written up again, because at that point it is a different fault.

When it happens

On a date agreed when you tell us the fixes are live. Every order names its retesting window and how many rounds it carries in the written quotation, because that depends on the size of the site and on how the work is being released.

What counts as new work

A page that has changed beyond the fixes, a configuration that was not in the original run, or a finding raised after a redesign. Those are quoted before anything is run, never added to an invoice afterwards.

How each finding comes back marked

Gone
The fault is no longer there in the configuration it was found in. The finding is closed and stays in the report as a record of what was done.
Still present
Unchanged, or changed in appearance only. The finding stays open and the retested report says what was seen this time.
Changed
The original fault is gone and something else is in its place. That is written up as a new finding with its own steps, because treating it as the old one hides what actually happened.

Check your website across devices

Send the addresses and the devices that matter to you. The scope, the figure in pounds sterling and the dates come back in writing, and nothing runs until you have accepted them.

Start a request See the coverage list

The other two

Cross-Browser Testing

Opening agreed pages in a named set of browsers at a named set of screen widths, and reporting where the layout or the behaviour differs.

Mobile and Device Testing

Opening agreed pages on physical handsets and tablets, and on emulated profiles, with every finding marked according to which of the two it came from.