What to test before launching business software
When reviewing a product, check what each person can discover or do with the available information. The first test concerns permissions; the others cover sharing, transactions and recovery. Select those that fit your project and use fictional data in a test environment.
1. Sign in with another account
Situation: customers have their own orders, appointments, documents or records.
Try this: create two customer accounts. Use the first to create a test order and copy the link to its record inside the application. Open it with the second account, then in a browser window without a session. Include employee and administrator roles if applicable.
Expected outcome: each account can access only what your business rules allow. A private record owned by the first customer stays private from the second. If public order tracking exists, define exactly which fields it exposes.
Ask for: a list of roles and their view, create, edit, delete and export permissions, with evidence of the test. Button visibility is one part of the interface; the request for the underlying data must also check access.
2. Forward something the system lets you share
Situation: the product creates links, downloads, reports or exports.
Try this: forward a test link outside its original account. Inspect a report's columns. Check an expired temporary link and access for an account whose permission was removed.
Expected outcome: recipients receive only the agreed information. Document whether a link requires a session or works for anyone who has it, its lifetime and how access can be revoked. Customer reports exclude internal notes and other customers' records.
Ask for: a sample of each output and its access rule. If a download URL grants temporary access to its holder, explain that design choice. Revoking an account does not erase a file someone already downloaded.
3. Repeat an operation
Situation: a person double clicks, refreshes after sending or retries after a slow connection.
Try this: submit the same test order twice and inspect the result. For payments, request a demonstration in the provider's test environment that covers retries and repeated notifications for one payment.
Expected outcome: retrying the same attempt creates one order, one charge and one stock adjustment. If repetition is allowed, the product distinguishes a new intended action from a retry. The interface shows whether processing has finished.
Ask for: the operation identifier, the final result and what prevents duplicate processing. The technical term is idempotency: repeating the same attempt preserves a single effect.
4. Interrupt a service the product depends on
Situation: email delivery, an external connection or a payment response fails.
Try this: have the team simulate the failure in the test environment. Inspect the customer and administrator views, then what happens when service returns.
Expected outcome: pending, completed and failed states reflect what was actually confirmed. An email delivery failure does not erase a saved order. A payment awaiting verification remains identifiable as pending, with a clear next step.
Ask for: a failure and recovery example, who receives the alert, and how retries work. Name the action and owner for any manual intervention.
5. Recover the information
Situation: important records were deleted or an earlier version is needed.
Try this: request a restore into a separate environment and open specific records. If the product stores files, check those too. Open an export using the intended tools.
Expected outcome: the team can show what was recovered and when the backup was taken. Agree on backup frequency, recovery time and the information that could be missing.
Ask for: the restored backup's date, checked records, responsible person and recovery procedure. A backup file alone does not demonstrate that restoration works.
Agree on the checks before delivery
For every applicable check, record:
- Scenario: the specific situation being tested.
- Action: what the person does and under which role.
- Expected result: what should remain visible or recorded.
- Evidence: a screenshot, recording or execution log.
- Owner: who fixes or makes a decision about an unresolved result.
For example: "Customer B opens the private record of customer A's order. Access is denied and no order data appears." You can verify that during delivery review.
At Exos, custom software starts with the operations and the people who use it. These scenarios help define the rules and outcomes to review. Tell us what you want to build and we can work through that definition together.