Check list for testing a software product

Complete list of items checked by Webasyst Store administration when you submit a product for publication

Contents...

Check all of these items yourself to get your product published upon the very first submission.

Configuring test environment

What a submitted product should not have

  1. Possibility of conflicts with other installed software products.
  2. More than one directory in the archive root. The submitted archive must contain only one directory named by the product ID.
  3. Custom code in configuration files db.php, app.php, plugin.php, settings.php besides that described in the documentation. In file routing.php custom code may be accepted in certain cases when there is no way to avoid it.
  4. PHP and HTML files and PHP classes in them, named in violation of the recommendations provided in the documentation.
  5. Unnecessary files which are not used by the product.
  6. Directories with PHP files, HTML templates, and localization files without .htaccess files containing Deny from all directory.
  7. Extra directives in .htaccess files.
  8. Empty subdirectories.
  9. Values are added to SQL queries without the use of placeholders (recommended method) or conversion to a safe data type.
  10. PHP code contains structures which are not available in some PHP versions sarting with 5.2, and there is no such limitation in the product's system requirements.
  11. PHP extensions are used and their availability is not verified in the working PHP code or in the system requirements.
  12. Functions file_get_contents, copy, get_headers, class XMLReader, or other similar methods are applied to remote resources wihout checking the value of allow_url_fopen parameter, which must also be mentioned in the product's system requirements.
  13. Any files are saved, modified, or deleted beyond directories designed for this purpose, i.e. wa-cache/, wa-config/, and wa-data/; e.g., in directories wa-apps/, wa-content/, wa-installer/, wa-plugins/, or wa-system/.
  14. Names of files or directories contain characters not supported by some operating systems.
  15. Database tables are created by other means than using file db.php (except for meta udates, see details below).
  16. Database table fields are created by other means than using file install.php.
  17. Repeated execution of code in file install.php generates errors.
  18. JavaScript error messages in the browser error console.
  19. PHP error messages.
  20. Error messages in server responses.
  21. Text characters are not escaped when displayed to users, or excessive escaping is performed.
  22. In user interface, text similar to the one shown below is not correctly displayed:
    '"></textarea><script>alert(1)</script>
    I.e. JavaScript code is executed instead of being displayed as text.
  23. Only webasyst/ is always used as the path to Webasyst backend.
  24. URLs of files loaded on web pages from external resources use http:// as the protocol name, which can affect the operation of a page opened via https://. The universal method of loading external files on web pages by using // notation must be used to avoid such errors.
  25. In website frontend, temporary messages like "Website is under maintenance" generated by your product are freely accessible to search engine crawlers for indexing, including the use of redirects.
  26. Debugging code left in product's source files.
  27. Large amount of code disregarding the architecture and programming interfaces provided by the framework.
  28. A plugin does not use its ID as the prefix for the following:
    • names of plugin's own database tables; the correct template for plugin's database table names is [app]_[plugin]_***; e.g., shop_watermark_data
    • names of plugin's own fields added to an app's existing database tables
    • names of plugin's own PHP session variables
    • names of plugin's own cookie variables
    • names of plugin's global JavaScript variables and functions, on the pages where plugin's code is executed next to the code of other plugins or its app.
  29. When a plugin is deleted, its file uninstall.php does not delete its own fields in an app's database tables, except for reasonable cases when deleting such fields can harm the app's normal operation.
  30. In plugin's configuration file plugin.php, non-existent methods of its main PHP class are specified.
  31. A system plugin of shipping, payment, or SMS type utilizes functions and classes of a certain app instead of being developed for use with any number of different apps designed to support those system plugins.
  32. In method callbackHandler() of a payment plugin there is no check for existence, positive length, and validity of a hash or signature sent by a payment gateway before updating order status by an app using the plugin.
  33. Plugin or app, when processing and event or in an HTML template helper, terminate the execution of a PHP script using die() function or other similar methods.
  34. Ability for a user to upload PHP or other similar files to the server which can be executed by requesting files at their URLs or in any other way.

What else should not be in a product update

  1. Database tables and fields in existing tables are created by other means than using meta updates.
  2. Repeated execution of code in meta updates files generates errors.
  3. Modified contents of file db.php without corresponding meta update files adding the new tables to the servers of users who already have the product installed.
  4. The new version does not contain files which were available in the previous version, and there are no meta update files removing those old files.

Critical defects in product's functionality and description

  1. Incomplete localization of the user interface.
  2. Non-intuitive user interface without a detailed description.
  3. Many grammar errors in the user interface or product description, including screen shots.
  4. Referral links in the user interface or product description.
  5. Critical errors in the product functioning.