Last Modified: 15.09.2014
The checklist method is the most appropriate for website testing. The checklist contains the list of operations to be performed without fail.
A checklist is the list of factors, properties, parameters, aspects, components, criteria, or tasks specially structured in order to achieve set goals.
Testing covers a lot of important details which are repeated in every project. Programmers often say that they remember them, but experience shows that they do not, as they miss important aspects and tend to repeat the same errors over and over again. It is not in vain that good project managers close stages/releases only provided that checklist reports executed by designated employees are in place – from layout designers to system administrators.
Checklists are normally drawn up by experienced employees. Checklists are developed and improved according to the growth of the company’s knowledge base. The idea is simple: save time and money by preventing employees from involuntarily (and sometimes voluntarily) repeat the same errors twice or more.
We recommend that you also draw up your own checklist for project delivery. The contents of the list may differ, but, as community experience shows, such a list must contain the following points:
- Search. If a search form is used on the website, it should be tested first. Make sure the search result links are not dead. If several infoblocks with dynamic information are used on the website, make search queries to find elements of different infoblocks separately and make sure the search result links work properly.
- F5. In all forms where users are permitted to introduce any data (e.g., comments) make sure such data are not resent upon pressing the F5 button in the browser.
- Users and access rights. Test the website in three conditions: as an unauthorized user, as an authorized user, and as an administrator. It often occurs that creating an infoblock as an administrator, required access rights are not set for the infoblock, and it remains accessible only to administrators.
- Website map. The standard component Site map is not always suitable for this page. If the main information of the website consists of the catalog of goods (made using the module Information Blocks) it will be logical to display catalog sections and not just website sections.
- Default templates. Make sure default templates are not used anywhere on the website. It may occur that, for example, if a user tries to recover their password, they will receive an email with a link to the website, and, following the link, see a sample Bitrix website instead of the website design familiar to the user.
- Styles in visual editor. Using a visual editor, the content manager should see the text that resembles the text to be displayed on the website as close as possible. I.e. paragraphs, headers, etc. require their own font size, color, etc.
- Dynamic information in the included areas. If an included area contains any dynamic information, it may become cached and it will most likely lead to an undesirable result. It is recommended not to use any dynamic information in the included area.
- Backup copy, update. Update Bitrix to the current version, make a backup copy of the website, and save it to the local computer.
- Cache. Make sure autocache is on. If not, activate it and repeat all testing from the beginning.
- System kernel. Check kernel operation and make sure it is consistent with the original (the kernel was not customized); generate a report.
- Unused files. Make sure the website contains no spare outdated contents and images.
- Third party connections. Different partner programs are often connected to the website: banners, scripts, etc. for monetizing purposes. Make sure all of these functionalities are safe and not vulnerable (access to editing, kernel access, possibility of code injection or saving through connectable file module).
If you do not have sufficient experience to prepare your own checklist, use the standard tool Project Quality Control.