1.1 Project Overview
This Test Plan defines the strategy, scope, and approach for QA automation of the ParaBank simulated banking system. The framework validates data integrity and behavioral consistency across UI, API, E2E, and Database layers — integrating TestAxiom, Failscope, and FixtureForge.
1.2 Objectives
- Validate core banking operations: login, accounts, transfers, loan requests.
- Ensure UI–API consistency — data in the browser matches API responses.
- Identify input validation failures using BVA/EP via TestAxiom.
- Execute DDT scenarios using FixtureForge-generated test data.
- Verify DB-level data integrity after UI and API operations.
- Analyze failures automatically via Failscope dual-agent RCA pipeline.
- Integrate all tests into GitHub Actions CI/CD pipeline with Allure reports.
1.3 System Under Test
| Attribute | Details |
|---|
| Application | ParaBank — Simulated Banking System |
| URL | https://parabank.parasoft.com/parabank/ |
| Type | Web Application + REST API |
| Domain | Financial Services / Banking |
| Default Credentials | john / demo |
| API Base | /parabank/services/bank/ |
| Feature | Layer | Status |
|---|
| Login / Logout | UI, API | In Scope |
| Account Overview | UI, API, DB | In Scope |
| Fund Transfer | UI, API, E2E, DB | In Scope |
| Bill Payment | UI, API | In Scope |
| Loan Request | UI, API, E2E | In Scope |
| User Registration | UI, API | In Scope |
| Find Transactions | UI, API, DB | In Scope |
| Input Validation (BVA/EP) | UI, API | In Scope |
| Mobile Testing | — | Out of Scope |
| Load / Stress Testing | — | Out of Scope |
| Security Penetration | — | Out of Scope |
3.1 Layers
🖥 UI Layer
Playwright + Python. Page Object Model. CSV-based DDT via FixtureForge.
🔌 API Layer
requests + pytest. REST endpoint validation. JSON schema checks.
🔁 E2E Layer
UI action → API verify → DB confirm. Cross-layer integrity checks.
🗄 DB Layer
SQLite. Verify persistence of financial transactions post-operations.
🧪 TestAxiom
EP/BVA test design for all input fields. Decision tables for loan logic.
🔬 Failscope
Dual-agent RCA on every failure. Error fingerprinting + Groq analysis.
3.2 Test Design Techniques
| Technique | Tool | Applied To |
|---|
| Equivalence Partitioning | TestAxiom | Login fields, Transfer amounts |
| Boundary Value Analysis | TestAxiom | Loan amounts, Account balances |
| Decision Table | TestAxiom Pro | Loan approval logic |
| Data-Driven Testing | FixtureForge + CSV | Registration, Transfer scenarios |
| Exploratory | Manual | Edge cases discovered during dev |
| Component | Technology | Version |
|---|
| Language | Python | 3.13 |
| UI Automation | Playwright | latest |
| Test Framework | pytest | latest |
| Test Design | TestAxiom | 0.1.0 (PyPI) |
| Failure Analysis | Failscope | 0.1.1 (PyPI) |
| Test Data | FixtureForge | local |
| Reporting | Allure | latest |
| CI/CD | GitHub Actions | — |
| Database | SQLite | built-in |
| AI Analysis | Groq / Llama | via Failscope |
| OS | Windows 11 | — |
| SUT URL | https://parabank.parasoft.com/parabank/ |
UI Tests
| ID | Title | Priority | Type |
|---|
UI-001 | Valid login with default credentials | High | Auto |
UI-002 | Login with invalid password | High | Auto |
UI-003 | Login with empty fields (BVA) | Med | Auto |
UI-004 | Account overview displays correct balance | High | Auto |
UI-005 | Fund transfer — valid amount | High | Auto |
UI-006 | Fund transfer — boundary amounts (BVA) | High | Auto |
UI-007 | Fund transfer — negative amount | Med | Auto |
UI-008 | New user registration — valid data (DDT) | High | Auto |
UI-009 | Loan request — approved scenario | High | Auto |
UI-010 | Loan request — denied scenario | High | Auto |
API Tests
| ID | Endpoint | Scenario | Priority |
|---|
API-001 | GET /accounts/{id} | Valid account returns correct data | High |
API-002 | GET /accounts/{id} | Invalid ID returns 404 | High |
API-003 | POST /transfer | Valid transfer updates balances | High |
API-004 | POST /transfer | Insufficient funds returns error | High |
API-005 | POST /loan | Loan approval — decision table | Med |
API-006 | GET /transactions | Transaction history is paginated | Low |
API-007 | POST /register | Duplicate username returns error | Med |
API-008 | GET /customers/{id} | Customer data matches UI display | Med |
E2E + DB Tests
| ID | Title | Layers | Priority |
|---|
E2E-001 | Transfer via UI → verify API balance → confirm DB record | UI + API + DB | High |
E2E-002 | Register via API → login via UI → account visible | API + UI | High |
E2E-003 | Loan request via UI → verify API status → DB confirmation | UI + API + DB | High |
E2E-004 | Bill payment UI → API amount deducted → DB transaction record | UI + API + DB | Med |
E2E-005 | Find transaction by amount → UI result matches DB record | UI + DB | Med |
Total: 23 test cases — 10 UI · 8 API · 5 E2E/DB |
TestAxiom generates additional BVA/EP sub-cases per field
| Type | Criteria |
|---|
| Entry — Start Testing | ParaBank URL accessible · Python env configured · pytest + Playwright installed |
| Entry — CI | GitHub Actions workflow file present · Allure configured |
| Exit — Pass | ≥90% pass rate · All High priority tests pass · Allure report published |
| Exit — Fail | Any E2E-001/002/003 failing · UI login tests failing · CI pipeline broken |
| Risk | Level | Mitigation |
|---|
| ParaBank public server downtime | High | Run local Docker instance of ParaBank as fallback |
| Flaky UI tests (dynamic elements) | Med | Playwright auto-wait + explicit wait helpers in BasePage |
| Groq API unavailable (Failscope) | Low | Failscope offline mode (--fs-offline flag) |
| TestAxiom Pro license missing | Low | Community tier (EP/BVA) sufficient for most cases |
| DB state pollution between tests | Med | pytest fixtures with teardown + SQLite reset per session |
| Deliverable | Status |
|---|
| Test Plan v1.0 | ✓ Done |
| Test Case Specification | Next |
| Framework Code (conftest + POM) | Pending |
| TestAxiom Integration | Pending |
| Failscope Integration | Pending |
| GitHub Actions CI Pipeline | Pending |
| Allure Report (GitHub Pages) | Pending |