The reception of the website should include real tasks for users and editors. See how to prepare test scenarios and pass the corrections in an orderly form.
Test to-dos, not the same look
The execution of the website ends with checking that the project works in everyday use. The screen image will not show whether the form sends a message, whether the link leads to the current document and whether the editor can change the content without violating the layout.
Prepare a few scenarios that match the purpose of the service. For the service site, this will be to find an offer and send a query. For the directory – search for the product and download the documentation. Each scenario should have a specific starting point and the expected result.
Check on real material
Long titles, photos of other proportions and extensive tables reveal problems invisible on short replacement text. Enter a representative sample of content before acceptance, instead of assuming that each subsequent entry will look like a demonstration.
Test the basic operation on your phone and using the keyboard. You do not need to start with a complicated report: check whether you can pass through the menu, read information and make contact. A more accurate range of tests should be adapted to the function and requirements of the project.
An example of a good failure report
Instead of “button works badly” write: subpage address, device, steps and expected result. For example: “After selecting an attachment and sending a form, a confirmation appears, but the message does not contain a file”. This description allows you to recreate the problem without a long exchange of questions.
Add a screenshot only if it helps to show the situation, and remove from it the data you do not need to transmit. Please group by function, giving each individual your own status. This makes it easier to see if the amendment has actually solved the problem.
Determine what readiness to publish means
Separate the bugs that block the basic tasks from the proposal for further development. The new idea for the module does not have to stop running, but the inoperative contact needs to be solved.
- Tested main user paths.
- Approved data, content and documents.
- Tested edition of key materials in CMS.
- Description of known limitations and maintenance plan after launch.
You will read about the preparation of criteria in the project in advance brief guide. Tasks after publication describes web site care.
