Test‐strategy

Test Strategy

Goal: show that each feature meets its requirements and that bad data is rejected.

Levels

Level	Tool	Who	When
API tests	Postman	Developer	Before each pull request
Manual end-to-end tests	Browser on staging	PO	After each deployment to staging
Data checks	SQL on the staging database	PO	During acceptance
Unit tests (Java, JavaScript)	TODO	Developer	To confirm with the trainer

Postman

• One collection per feature, one folder per action (add, list, modify, delete).
• Two environments, local and staging, each with a baseUrl variable.
• Request names look like POST indicator-values - invalid percentage.
• Collections are saved in the repo: TODO folder

What every feature must test

• Normal case: valid data is saved.
• Validation: missing, wrong or out-of-range values are refused.
• Integrity: duplicates and unknown references are refused.
• Messages: clear error on failure, clear confirmation on success.
• Dependencies: what happens when needed data is missing.

Test data

We create test data with SQL scripts, so we can rebuild the database any time. The same scripts run locally and on staging.

Acceptance on staging

1. We deploy with the Bash script.
2. We tell the PO what changed and how to test it.
3. The PO tests and may check the database.
4. The PO opens a bug issue if something is wrong.