# Testing-team guide

## Install the testing copy

In the Froiden-based web installer, choose **Testing / Demo** and acknowledge that this installation uses disposable test data. The installer creates a fresh database schema, a private first-owner Super Admin, thirteen shared role accounts, a production team and a sample institution. It uses `APP_ENV=staging`, keeps debug output off, and explicitly enables testing features. Choose **Production** for real users and data; that mode does not expose role credentials or reset previews.

No credentials from the development installation are shipped. Every testing installation generates its own passwords. If real Turnstile keys are omitted in testing mode, official Cloudflare test keys are used; the server still verifies each submitted test token with Cloudflare. The host therefore needs outbound HTTPS access to Cloudflare.

## Copy or select a role account

Open `/login`. Under the login box, **Choose a test account** displays each role's email and password as selectable text. Copy the credentials or click **Use this account**, complete the security verification and click **Sign in**. The button fills the normal login form; it does not bypass password checks, CSRF, account activation or role authorization.

The role list covers Student, Faculty, College, University, Super Admin, Admin, Manager, Designer / Formatter, Reference Specialist, Proofreader, QC, Finance and Help Desk. The first four use the customer role. The private owner account created during setup is not listed in this shared panel.

If a listed account's password changes or the account is suspended, its stale credentials disappear from the picker. The tester should then use the password they chose. New signup passwords are never added to the public list.

## Create and test a new account

1. Click **Create a new account** and register with a unique email/name and a confirmed password.
2. Complete Turnstile. Signup creates a customer account even if a request tries to supply a staff role.
3. In testing mode, the new account can immediately open the dashboard without outbound verification email. Its verification timestamp is not fabricated.
4. Test profile changes, submissions, support and the available customer workflow. Staff accounts use their corresponding menus and backend permissions.
5. Sign out before testing the guest login/signup/reset screens again. Each browser has its own authenticated session.

## Test Forgot password without SMTP

1. Register the account in this browser, then sign out.
2. Open **Forgot your password?**, enter that account's email and complete Turnstile.
3. The same browser receives an **Open password reset form** preview link. Shared seeded demo accounts can also use this testing preview.
4. Open the link, choose and confirm a new password, complete Turnstile and submit.
5. Sign in using the new password. The old password no longer works, and the reset token is consumed.

For privacy, a browser cannot preview reset links for unrelated accounts created elsewhere. Those addresses need configured SMTP or the normal email inbox. Unknown emails receive the same generic response. Reset-link previews are session-scoped, expire naturally with the normal reset token, are not cached publicly and are always disabled in production. A preview is not a password-reset bypass: the normal broker token and form validations still run.

The browser remembers its own most recent twenty account creations across sign-out only while testing mode is enabled. Clearing browser cookies removes that association. The shared demo-role accounts remain available for basic testing from a fresh browser.

## Suggested acceptance checks

- Missing/incorrect passwords; login/logout; duplicate-email registration; password confirmation; account suspension.
- Signup → dashboard → logout → forgot password → reset → login with the new password.
- Role-specific menus and direct attempts to open unauthorized URLs.
- Draft creation, files, services, quotation/acceptance/payment gate, allocation, employee work, independent QC, revisions and closure.
- CSRF rejection with a missing/wrong token; stored and reflected HTML/JavaScript payloads displaying as text.

File quarantine, independent QC, payment verification and authorization gates remain enforced. Configure a real scanner and the required integrations to test their actual behavior; the testing installer does not invent completed scans, payments or live deliveries.

Use a separate fresh production installation for real work. The production installer keeps email verification enabled and requires real mail/Turnstile/payment configuration as applicable.