How to test — what to include¶
The "How to test" section is optional, but when present it saves the QA engineer (or the person who picks up the ticket) a lot of guessing. This file lists the kinds of content that tend to be useful, with Securitize-specific environment notes.
When to include this section¶
Include it when any of these is true: - The test setup needs specific data that is not obvious (specific accounts, KYC status, token state, contract address). - A feature flag must be on or off. - The behavior differs between environments (dev / rc / sandbox / prod). - There are non-trivial edge cases that QA should check explicitly. - The change touches an area where the test path is not the same as the user-visible path (e.g. a webhook, a cron job, a backend-only effect).
If the test path is "open the app, click the button, see the result" and there's nothing special, you can skip the section. Don't add it for the sake of it.
Securitize environments¶
Securitize has four environments. The workflow organizes "How to test" content by env when the setup differs.
| Env | Purpose | Notes |
|---|---|---|
| dev | Engineering work in progress | Feature flags often on by default; data is shared and may be reset. |
| rc | Release candidate; daily QA runs | Most realistic for QA validation; mirrors prod data shapes. |
| sandbox | External-facing test env (issuers, partners) | Be careful: changes here are visible to non-Securitize users. |
| prod | Production | Avoid using for tickets unless verifying a hotfix. |
A common, useful pattern:
What tends to be useful¶
Test users / accounts¶
Be specific. "a user with KYC pending" is OK; "qa+kyc-pending@securitize.io in rc" is better.
If the account needs a specific state (KYC status, MFA state, balances), say so. If you don't know an account that matches, say "QA to provide" — don't make one up.
Feature flags¶
Name the flag and the value the feature requires:
Flag
mfa-enforcemust beonin the env you test against.
If multiple flags interact, list all of them.
Test data¶
For tickets that require specific records (a token, an issuer, a contract): - Reference an ID (issuer ID, token symbol, smart-contract address) when possible. - If the data does not exist yet and the test requires creating it, give the steps.
Edge cases¶
List the cases worth testing explicitly, especially negative paths: - Boundary conditions (off-by-one, empty input, zero, max value). - Roles other than the obvious one (admin vs. investor vs. issuer). - States other than the happy path (pending, rejected, suspended, expired). - Concurrency (two requests at the same time, retries).
Expected errors / messages¶
If the test path includes triggering an error, say what the error should look like — text, code, status — so QA can confirm they're seeing the right one.
What NOT to include¶
- Implementation details. Save those for "Technical notes". "How to test" is for someone who will exercise the behavior, not someone who will write code.
- The full happy-path description. That's the ticket itself. Just call out what is non-obvious about exercising it.
- Long copy-paste of test results. A pointer is enough.
- PII / real customer data. Use QA accounts only.
A complete example¶
### dev
- User: `qa+mfa-expired@securitize.io` (token last validated 30+ hours ago)
- Flag `mfa-enforce` must be on (default in dev).
### rc
- User: same email mirrored to rc.
- Confirm with @QA before testing — daily Selenium run uses this user too.
### Edge cases
- Token at exactly 24h: should NOT redirect.
- User with no MFA devices: should redirect AND show the "no devices" banner.
- User on a deep-link (`/dashboard?ref=email`): redirect should preserve the query.
### Negative path
- Trigger by manually setting `mfa_validated_at` to 25h ago in MongoDB (collection `users`, field `mfa_validated_at`). The dev env tooling has a script for this: `scripts/expire-mfa.sh <email>`.
Notice how the section is organized by env, then by category, with concrete pointers (script name, collection, field). That's the bar.