Introduction
1.1 Purpose
One shared way for the QA team to write test cases, test the product, and record the results, so anyone on the team (or an AI tool) can pick up anyone else’s work.
1.2 Scope
| Area | What we test | Tool |
|---|---|---|
| Backend | APIs, Azure Functions, async flows, data written to the database | pytest |
| Frontend | Web UI: pages, buttons, forms, error messages | Playwright (Python, run through pytest) |
| Data pipelines | Each task lands its data correctly, failures stop the pipeline, alerts are sent | pytest |
| Stress & load | How the system behaves at peak and beyond | Locust |
| AI prompts | Model answers to a prepared set of prompts | pytest script + an AI judge |
| Smoke in CI/CD | The deployed app is alive after every deploy | pytest run by the Azure DevOps pipeline (section 10) |
| Documentation | Test plans, test cases, test runs, results, bugs | Kiwi TCMS |
Not in this version: mobile app testing. It’ll be added as a separate page when the team needs it.
1.3 Who owns what
| Work | Owner |
|---|---|
| Unit and integration tests inside the code | Developers (Product Engineer Testing Strategy) |
| Test cases, API tests, UI tests, prompt tests, test runs, sign-off | QA |
Smoke tests and the shared pipeline template (qa-automation repo) | QA |
| Product pipeline, deploy, service connection, Azure access | Developers / DevOps |
| Prompt and model design | Data & Prompt Engineer team. QA tests the result |
QA doesn’t re-test what developer unit tests already cover. QA tests the system the way a user or client uses it.
1.4 Changing this standard
Click “Edit this page”, make the change in a pull request, explain why, and get QA lead approval. Add a line to the change log.