How do User Journeys work?
User Journeys allow Silktide to crawl areas of websites that are behind password protections. It also allows for specific use cases to be tested.
Examples
A website has a login page before customer areas of the website can be accessed, but the website owners still want to test the private pages for accessibility. A User Journey can be used to fill out the login form and then access the pages before continuing to test them in the same way that the public areas of the website are tested.
A bank wants to ensure that its multi-page form is accessible, but each page requires that the form is completed before the next page can be accessed. A User Journey can be used to fill in the form using input data provided by the bank. This ensures that the pages containing the forms are fully tested by Silktide in the same way that any other page of the website is tested.
What Silktide needs to create a User Journey
Before Silktide support can set up a User Journey we need the following information:
- URL: The URL that the User Journey will use as its starting point. This must be publicly accessible.
- Steps to follow: What steps should be carried out? Provide these as step-by-step instructions that would allow a user who has never seen the website to complete the journey.
- Login details: The username and password that should be used to log in, if applicable. We recommend setting up a dummy account for this purpose, and not using a real user’s account.
Security implications
All of the details are encrypted via SSL and stored behind multiple levels of security. However, users should be aware of the following:
- To test pages we need to store the login details (e.g. username and password) that were provided to us – i.e. we can’t just store a non-reversible hash.
- We store the contents of the pages that we download so they can be tested, and viewed within our platform.
Therefore ensure that the login details provided, and the pages that this login gives access to, are not sensitive in nature. We strongly recommend the use of a dummy account for this purpose.
What can cause problems?
Nearly all well-behaved websites that use web standards correctly will just work. Unfortunately, older and proprietary login systems do not always behave this way.
- If some links are not idempotent – i.e. visiting a page has side effects – we may need to exclude them. The most common example is if a link logs out the user; more serious examples would include links that create or delete data. For this reason, only test with a dummy login account.
- Some logged-in pages use entirely temporary URLs, which exist only for the moment they are first requested (e.g. they contain a unique session ID and/or encrypted application state). Although we can sometimes still test these, they are much more difficult to set up and some parts of Silktide are incompatible with them (e.g. you can’t view the history for a page, as no page exists more than once).
