Task: to verify if the site works correctly and rapidly on all devices and in all browsers that might be used by target audience. Assure that user stories are executed with no errors. Example of purchase user story for online store: product choice → product review → addition to cart → checkout → successful payment. There should be no mistakes both for scheduled mode and peak traffic.
The site should function efficiently: consume minimal resources – this will allow to choose the best tariff and not overpay for hosting services.
The site is loaded and runs correctly on all devices and in all browsers. All user stories are executed with no errors.
Server returns HTML-document of any site’s page in 0.2 seconds or even more rapidly. All page’s content is loaded in few seconds.
This reduces the risk that a user doesn’t wait until load and leaves the site. Due to rapid load of HTML-document, part of content will be immediately shown on the page, while the rest of the content will be loaded gradually during 2-3 seconds.
Size of HTML-document of any page is within some hundred kilobytes, general size of all pages elements – some megabytes.
In this way, the page is loaded rapidly, browser rendering takes less resources, and the site works with aplomb even on low-end devices. For example, mouse pointer moves over screen with no interruptions, animations do not hang.
When the number of users exceeds estimated peak value ten times, the site remains fully runnable. Rate of HTML-document return by server increases maximum to several seconds.
If in average the online store is viewed by about 1000 users at the same time, during “Black Friday” there may be about 10 000 users. All they should view products and shop with no trouble.
The site shows error messages clear to a used. For example, 401, 403 – access denied, 404 – page not found, 500 – internal server error.
External scripts and styles – standard libraries like Angular or jQuery are connected through CDN (Content Distribution Network).
This allows to increase page’s speed and save traffic, as there is high probability that popular libraries have been already saved to user’s device.
Proper internal scripts and styles not placed on CDN are united into minified files – one script file and one css file. This allows to reduce the number of requests to server, saves traffic and accelerates load rate.
Links to scripts (except counter scripts, for example, Google Analytics) are placed at the bottom of the page, while links to styles – at the top.
This allows to get the optimal load sequence: at first – the main text content → then – styles (site’s visual) → then – images → at the end – scripts.
Counter scripts should be placed at the top of the page so that they have time to be loaded and fix visits even if a user closes the page in one-two seconds.
Caching rules for browsers are set for static files.
Files are saved on user’s device, and during site’s revisitation there are no extra requests to server; this decreases server load and accelerates page load.
For pages that are changed every few hours or less often, their content is cached by server. For sites with average number of same-time users about several hundreds and more, pages are cached on the side of services like Cloudflare.
This increases site’s running speed, decreases server load and increases the number of users that may visit the site at the same time.
When printing pages content, auxiliary elements like navigation and forms are not printed.
Files names contain only Latin symbols, numbers and underscore characters. If there is a mechanism of files load on the site, their names are being corrected automatically if it is necessary, after load.
File’s name «Коммерческое предложение компании.pdf» is converted to “kommercheskoe_predlozhenye_kompanyy.pdf”.
Task: to verify if site’s interface is user-friendly and whether a user gets positive experience when he interacts with it.
Site’s appearance totally matches to design on all actual devices and browsers.
All site’s functional features are available for all types of interconnection: mouse, touchpad, keyboard, touchscreen etc.
This allows to use the site, for example, just using a keyboard, if there is no mouse or laptop touchpad doesn’t work: scroll a page, fill in forms, press buttons. If the site has sliders, there should be the possibility to turn images using arrow buttons on keyboard.
Mouse pointer changes the form when it is pointed on text fields, buttons, links and other interactive elements. Interactive elements react to pointing, focus and pressing.
For example, text input field is highlighted when a user puts a pointer on it.
Critical actions like, for example, deletion, require either additional confirmation or cancellation. It is preferable to have a possibility to cancel such an action.
When clicking a heading, the field gets input focus: it is highlighted as an active one and a cursor appears in it. A user may enter text at once, with no additional clicking on the field.
All the required fields (or on the contrary – optional fields) are marked with asterisks or prompt text.
Verification of data entered by user: filling of required fields, minimal and maximal text length and its format, minimal and maximal value of number, uniqueness of value etc.
Validation is performed on client’s and server’s sides. If validation will not be performed at some reason and data will get directly to server, it will be still verified and declined, if necessary.
All forms indicate in details that there are errors in filling the fields, so that a user definitely understands the reason for their occurrence.
For example, “the field should be filled in”, “the field should have not more than 64 symbols length”, “the field should contain only Latin symbols and numbers”.
During data upload to server, submit button is blocked and becomes visually inactive to avoid double strokes. If an operation may last more than several seconds – animated load indicator or a relevant message is additionally shown.
Forms are submitted by pressing the “Enter” button on the keyboard.
Pop-up forms and other pop-up elements (pop-up messages, windows) are shut down by pressing “Esc” on keyboard.
Logo in top and bottom part of the site is the link that leads to homepage. However, homepage logo is not a link.
When changing language, user remains on the current page.
No passage to homepage or other site’s page when changing the language.
When text in browser is scaled up, the site saves its efficiency. Content is fully available for review, forms, buttons and other interactive elements functioning with no errors.
The site meets WCAG standard of accessibility for people with disabilities of the level АА or AAA.
For example, contrast between text and ground is at the level not less than 4.5:1 (except particular cases), attributes "aria-…” are used etc.
Task: to verify if the site meets basic SEO requirements. Sites that correspond to rules of optimization look more attractive in search, take higher positions in search engines and generate organic (free) traffic.
Page layout goes through HTML validation.
Service to check HTML for errors: https://validator.w3.org/
All pages have a language set. This will notify search and other systems about the language used for it.
meta description tag is present in singular number.
Meta description – site’s page description that is seen by user in search result under the heading. If the description is absent or is too short, there may be viewed a part of text from a page that might misrepresent content meaning.
Tag title is present on all site’s pages in singular number.
title tag content is displayed on site’s tab in browser as a title in search results and is saved as a title when adding the site to favorites.
Tag h1 is present on all site’s pages in singular number.
H1 – main header on a page. For example, homepage of apps developers’ site may have such text in H1: “Android and iOS mobile apps development”. Usually it is written with the largest font and is bold.
Different browsers have different requirements to “favicon” – site’s icon that is usually shown in an open tab, as well as in favorites. For the favicon to be clear and of the proper size, it is necessary to prepare several files in accordance with requirements of specific browsers and add additional layout to HTML-code of pages.
Tags h1–h6 are used for headers, p - for paragraphs, ol and ul - for lists, img - for images that are part of content. Images that are part of graphic design are set by use of CSS-rule “background-image”. The same relates to tags and description of document structure: header, footer, navigation and so on.
Attribute “alt” is indicated for images, audio and video-files.
Due to attribute “alt”, media-files are shown in search by images, for example. And if for any reason a file is not loaded, the content of “alt” tag will be shown on its place – short text that explains what had to be visualized or shown in photo or video.
Photos have JPEG format, while interface fragments (for example, buttons and icons) - PNG or SVG.
Image’s scale should be counted proportionally to width of the area on screen that it fills, considering that 100% of screen width is 1920 pixels. Except the cases when image’s resolution has a key value like, for example, on a photographer’s site. In such case 100% of screen width is considered to be 3840 pixels.
There are no links that lead to deleted or hidden pages on the site.
In most cases all external links should be launched in a new tab or window so that a user doesn’t leave the site when he clicks them.
Texts are written orthographically, with no mistakes. Correct typographics corresponding to the language is used: dash, quotes, apostrophes etc.
If site’s content is changed to local one when changing language – language is indicated in URL as first segment, for example, “/en/”, so that it is possible to refer to definite language version and it is correctly indexed by search systems.
If just interface is changed while the content is not, for example, text on buttons changes from «Подписаться» to «Subscribe», - there is no such a segment in URL, in order not to create twin pages with same content. Such pages will compete in search and this will worsen positions in search results.
Language code for default language in homepage URL is absent. For example, if English is the default language for a site, its code is not shown in the address when passing to homepage.
Format for numbers, dates, currency etc. corresponds to current language and culture.
When entering site’s address in format www.site.com, automatic redirecting to version without “www” in URL is made.
www.site.com → site.com
Or vice versa, if it was decided to use the address with “www”.
site.com → www.site.com
With no redirecting, search engines will perceive the page with “www” and without it as two different pages with same content. Pages will compete in search and this worsens the results of search.
There is no possibility to use the site through HTTP protocol.
Browsers mark sites that run through HTTP as unsafe, and search systems drop them in search results.
All URL have a single format – whether English words and phrases or transliteration to local language (acceptable if site runs and will run only for local market). Hyphen is used as separation symbol between words. All of them, including parameters, lowercase. Special symbols and alphabet letters different from Latin, are coded.
URL structure is consistent and uniform, it corresponds to site’s structure. For example, for page “Heels”, a subcategory of category “Women’s shoes” – “/women-shoes/shoes”.
Email addresses are links with prefix “mailto:”.
In this case clicking on address opens mail client, and the address is set into the “To” field.
Phone numbers are links with prefix “tel:”.
In this case clicking on number leads to possibility of direct phone call if user visits the site from his cell phone.
Content is not replicated for references with “/” and without “/” at the end.
Links “/women-shoes/shoes” and “/women-shoes/shoes/” do not show the same page. In one case 404 error is displayed.
It is used to end links to catalogues (lists) of elements or sections with a slash, links to specific pages – with no slash.
Otherwise, search engine, like in item 3.15, will interpret links as doubles of the same page.
Fault links like, for example, “/women-shoes//shoes” are automatically redirected to “/women-shoes/shoes”.
Otherwise, search engine, like in items 3.15 and 3.21, will interpret links as doubles of the same page.
Site’s root should contain automatically generated file “sitemap.xml”, new pages or products should immediately appear in it.
This is important for rapid indexation of new pages by search engines. If a page is not indexed, it will be out of search results.
Site’s root should contain file “robots.txt”. This file helps search engine to define what pages to index and what not to.
For example, an online store has an admin panel. In this case the address “site.com/admin” should be available just for internal use and not appear in search results.
Google Analytics tracking code should be set up on the site.
Structured data improves snippet’s view – how information on site is shown in search results. It gives the possibility to show author’s name and photo, publication date, product’s rate and other necessary information. Also, when publishing a reference to site in social networks, correct image for skin is loaded.
Task: to verify how good is the site protected from hacking or data loss.
The site runs on HTTPS protocol. Besides this, there are no links to connected resources (scripts, styles, images) through HTTP protocol.
HTTPS provides safe data transfer due to coding and nowadays it is a standard.
Real IP-addresses of servers should be hidden. Services like “Cloudflare” may be used to proxy requests.
If proxying of requests is not used, there is a possibility to find out server’s IP-address by its domain, this increases the chances for it to be hacked.
Use of services like “Cloudflare” to limit repeated requests.
DDOS-attacks may lead to system’s failure – the site will turn unavailable because of excess of maximal load or increase bills for technical resources because of notable increase of load to attacked server.
When errors appear, detailed information about them is not shown. That is debug data for developers that should not be in public access. Messages about errors should be clear for users, as it is indicated in item 1.5.
The site is protected from attempts of introduction malicious scripts with aim to receive users’ data or access to close sections.
Often forms for comments, notes to orders and so on are subject to such attacks, in other words, when text entered by user (or violator) is entered somewhere on a page or in admin panel, and script inside it may be automatically executed by browser.
The site is protected from attempts of introduction malicious SQL-requests with aim to change or destroy data.
Often search fields where text entered by user is placed into previously prepared SQL-request and may contain malicious instructions are subject to such attacks.
All forms on site, for example, feedback forms and online-request forms that send notifications to owners, have spam protection due to services like “Google ReCAPTCHA V3”.
Without protection, site’s owner email receives bigger number of messages with spam that are automatically sent by robots.
After several attempts to enter the wrong password, response time from server increases. Additionally, the server may show a captcha, ask to enter an answer to security question or code from SMS.
This slows down the matching process and warns from tampering attempts. Matching time is extended so much that it becomes almost impossible.
Automatic site’s back-up (database and content) is customized. Copies are created on server situated in another data-center. For example, for the case of a fire.
Frequency of backups depends on site’s specificities. For example, if it is a site that continually takes orders – it’s necessary to create backups every few hours. For the site where changes happen rarely, one backup per week might be enough.
Automatic availability monitoring and automatic mailout to site’s developers and owners in case of its disability are customized.
If site’s availability is crucial, it is necessary to provide its simultaneous operation on at least two service platforms in different geolocations.
If one service platform fails, the other one will provide complete operability.
If site’s data is crucial and its loss is inadmissible (even since the moment of the last backup), it is necessary to provide database replication in another geolocation.
If one service platform fails, the second one will save important information about clients, financial operations, orders etc., and may even allow to continue complete functioning.