Some scenarios require a supported printer. We're tracking compatible printers available to team members here.

Also see https://drive.google.com/drive/u/0/folders/1lyk2V15e7amI9OxvgUK_YhYIUVNDWJo0 for different types of file submissions we'll want to test for printing and display (mostly pulled from https://file-examples.com/).

Possible way to break up testing:

• Scenario A: International user
  • il8n/locale testing
• Scenario B: Longstanding user - Export scenarios (veracrypt, LUKS and print)
  • populate submissions list with multiple file type previews (including zip files),
  • export and print scenarios
  • large dataset scenario (submit/download/view)
• Scenario C - new user (making notes on ease of use and usability, assume lack of Qubes mental model)
  • updater testing, including failure situations
  • scenario: Basic Functionality
  • scenario: client and journalist interface both in use
• Scenario D: admin installing Admin familiar with Qubes going through the installation documentation;
  • provisioning
  • ensuring old conversations are recovered
• Scenario E: admin troubleshooting
  • updater failures
  • connectivity issues, unable to troubleshoot alone and process to request support
• Scenario F: Occasionally-connected user
  • network tests (Tor/JI)
  • going back and forth between an authenticated session and offline mode
  • occasionally connected user scenario

Creative/exploratory testing: Beyond the test plan, it's helpful to be a bit creative in a way that simulates a normal user - with emphasis on the last part. (Clicking a button a few times to see if there are any adverse effects on the UI - helpful! Using an automated framework to spam the GUI with hundreds of clicks per second to see what happens - less helpful!). Document any exploratory testing, impressions and observations, and ideally, include steps for others to reproduce your findings.

Some examples:

• Qubes-related interactions: How's updating? How's attaching, removing, and interacting with peripheral devices? Do our docs clearly state how to recover from scenarios such as failed network connection, failed updates, etc? What happens if you disconnect the network in the middle of an update, use toxiproxy to simulate slow downloads, etc?
• Large file issues: Can large files be downloaded and/or moved between VMs? Can conditions be introduced that would make some large file downloads problematic (eg: a several-megabyte file)?
• Large volume of submissions: What happens when there are lots of submissions on the server?
• Impatient/hurried user: What are your observations if you approach your testing session from the point of view of being in a hurry, short on time, rapidly clicking, etc

Some of the feedback may be bug reports and/or UX observations that aren't directly bug reports.

At least one tester should check that:

• Under the LANG=en_XA pseudolocale, all GUI strings like foo are correctly wrapped like [!foo!]. (Any string not so wrapped is missing its gettext() wrapper.)
• Generate a conversation transcript and export it. Inspect to make sure it displays correctly in the specified locale.

Some of these may be a bit time-consuming, so we typically have a subset of devs test these specific scenarios. In these scenarios, we try to validate the behavior of different components of the system. There's a separate section with detail on Client functionality specifically.

The Qubes scenarios are tracked in the requirements tracing document. This is an effort to ensure most (if not all system functionality) is covered by QA / automated tests. This temporarily lives in a google doc, but the goal to move it to the repository itself and have each requirement mapped to its implementation and respective test with the help of a tool like OpenFastTrace.

Some of the tests below should be incorporated into main test plan after the release, while others will not need to be re-tested with each release.

Moved to https://github.com/freedomofpress/securedrop-workstation/issues/548

Moved to https://github.com/freedomofpress/securedrop-client/pull/1083