About Features Downloads Getting Started Documentation Events Support GitHub

Love VuFind®? Consider becoming a financial supporter. Your support helps build a better VuFind®!

Site Tools


Warning: This page has not been updated in over over a year and may be outdated or deprecated.
development:testing:manual_testing

This is an old revision of the document!


Manual Testing

VuFind® uses a set of Unit Tests to check for problems as the software develops and evolves. Automated tests are generally the preferred way to test software, since they are automatic and repeatable. However, sometimes humans can detect problems in areas where automated tests cannot (like aesthetic changes), and sometimes manual testing is useful as a lead-up to developing automated tests. This page contains notes intended to be helpful for manual testers.

General Considerations

Browser Testing

It is a good idea to test the interface in multiple browsers to check for display inconsistencies and Javascript incompatibilities. We are most concerned with compatibility with the current generation of browsers, but compatibility with earlier versions is desirable when possible. Recommended browsers to test:

  • Firefox
  • Edge
  • Chrome
  • Safari
  • Opera

The automated test suite typically runs in Chrome, so doing manual testing in other browsers is a good way to potentially uncover browser-specific issues.

Input Testing

Some general patterns to follow when testing new features:

  • Test fields stored in the database for SQL injection vulnerabilities.
  • Test fields sent as Solr searches for vulnerability to syntax errors.
  • Test fields where input is stored and displayed back for XSS vulnerabilities and missing HTML/URL encoding. A good test is “<script>alert('test');</script>” – if there is an XSS vulnerability, this will cause a pop-up to appear!

If you find something that breaks, please don't just fix it – also build an automated test to prevent regressions!

Testing Integrations

VuFind®'s test suite is not able to connect to third-party systems. While it can simulate these interactions for testing purposes, if third-party systems actually change their interfaces, the test suite will not be able to detect problems. There is no way around this – we do not own copies of every Integrated Library System ever published, or have subscriptions to every third-party resource. Therefore, user testing of integrations that they have access to is valuable to ensure that our code remains up-to-date and relevant.

Some areas of code that benefit from this type of testing:

  • Export Targets (e.g. EndNote, RefWorks, etc.)
  • ILS Drivers (e.g. Alma, Aleph, etc.)
  • Search Backends (e.g. EDS, Summon, WorldCat, etc.)
  • SMTP integration (e.g. sending emails via various services)

If you test and discover that something is not working, please open a JIRA Ticket to report the problem.

Feature Testing

VuFind® has a lot of optional features which are not immediately visible. This section of the page provides quick steps for turning on optional features so that you can test and evaluate them. This is intended to be used in combination with VuFind®'s standard test environment, which you can learn how to set up by watching the Setting Up a Test Environment video or reading the unit testing page.

Library Cards

VuFind®'s “library cards” feature allows a single user account to be linked to multiple ILS accounts, for scenarios where (for example) a single VuFind® instance is connected to multiple libraries, and users might have accounts in multiple locations. The Demo driver (which simulates an ILS using entirely fake data) can be used for testing library cards. Follow these steps:

  1. In config.ini, in the [Catalog] section, set driver to “Demo” and library_cards to “true”.
  2. In the VuFind® web interface, create a user account (or log in to an existing account).
  3. On the “Your Account” page, click on “Library Cards” in the side menu.
  4. You can now create multiple named library cards with different login credentials; by default, the Demo driver accepts all credentials, so you can make up whatever usernames and passwords you like.
  5. Now if you go to the “Profile” page, you should see a drop-down menu of library cards at the top of the “Library Catalog Profile” section of the page. When you switch the values in the drop-down menu, you should see the accounts associated with the different cards. The “First Name” field will include the username that you provided as evidence that the data is actually being switched.
  6. All other features related to the ILS (holds, fines, etc., etc.) should also display the library card selection control.

Transaction History

VuFind® allows users to view (and in some cases purge) their transaction history, but this functionality is disabled by default. To see how it behaves, follow these steps:

  1. In config.ini, in the [Catalog] section, set driver to “Demo”.
  2. In Demo.ini, in the [TransactionHistory] section, set enabled to true.
  3. After creating an account and logging in, a new option should now be available in the account side menu to allow access to transaction history. The Demo driver will populate this with simulated data (and you can log out and back in again to generate a new set of simulated data).
development/testing/manual_testing.1683207576.txt.gz · Last modified: 2023/05/04 13:39 by demiankatz