How babmintot/bank works
1. Repository purpose
- This is a QA-oriented repository for a web service that transfers money from a bank account to a card.
- The repo does not contain the business backend; it contains the test target build, manual QA artifacts, Selenium automation, and CI around that target.
2. Test target application
- The runnable application is a static front-end build in the root output files: index.html plus bundled assets/*.js and assets/*.css.
- It is served locally as a static site with python3 -m http.server 8000.
- The app behavior is parameterized through the URL, for example /?balance=30000&reserved=20001, which suggests the transfer logic is driven by query parameters rather than a separate API/backend in this repo.
3. Main functional boundary
- The key boundary is between the browser UI and the rendered transfer form/state logic inside the static app.
- Selenium tests interact only through the browser, so all validation, commission calculation, and defect reproduction happen at the UI level.
4. Manual testing layer
- The manual/ folder contains the QA documentation:
- test-design.md for coverage strategy,
- test-cases.md for manual test cases,
- bug-reports.md for defect records,
- images for evidence.
- This layer captures requirements analysis and defect findings that directly informed the automated scenarios.
5. Automated test layer
- autotests/ is a Python test suite using pytest + Selenium.
- conftest.py likely contains shared browser setup/teardown and fixture wiring.
- Each test file maps to one scenario or defect category, making the suite easy to trace back to documented QA cases.
6. Automated scenario coverage
- The suite includes both expected-pass and expected-fail cases:
- success flow,
- insufficient funds,
- negative, empty, and short-card validation,
- commission check,
- known defect reproduction for boundary amount and oversized card number.
- This means the test suite is not only regression-oriented, but also serves as a defect-verification suite.
7. Data flow during test execution
- CI or a local developer starts the static app.
- Selenium opens Chrome, navigates to localhost:8000 with preset query parameters.
- The browser UI computes or displays transfer outcomes.
- Assertions in pytest verify success, validation messages, or known broken behavior.
8. Environment and tooling
- The automation stack is Python 3.11+, pytest, Selenium, Chrome, and ChromeDriver.
- webdriver-manager is used so the driver can be obtained automatically.
- This makes the test environment mostly self-contained aside from the browser runtime.
9. CI boundary
- .github/workflows/test.yml defines GitHub Actions execution on push and pull request.
- The pipeline installs Python, Chrome/ChromeDriver, Python dependencies, starts the static service, and runs the Selenium suite.
- CI therefore exercises the same browser-driven path as local execution.
10. Expected CI outcome
- The workflow is intentionally red/failed because two automated tests reproduce known defects:
- boundary amount issue,
- invalid card-length handling.
- That means the CI is being used as a defect detection gate, not a fully passing release pipeline.
11. Architecture summary
- The repo is organized around three planes:
- test target: static transfer UI,
- verification assets: manual documentation and automated pytest/Selenium suite,
- execution infrastructure: local static server and GitHub Actions.
- The only external runtime dependency that materially matters is the browser stack, because all validation is performed through UI automation.
12. What to draw in an architecture diagram
- Show the static web app as the central target.
- Show two consumers of that target: manual QA artifacts and automated Selenium tests.
- Show Selenium tests running in Chrome, driven by pytest.
- Show GitHub Actions orchestrating environment setup and test execution.
- Show the local HTTP server as the delivery mechanism for the static app.
Main entry points: tests Pytest suite · test.yml CI workflow · test-cases.md Test cases · bug-reports.md Bug reports
Components 16
Test target
Static transfer UI delivered as files and served locally.
- Transfer UI · Root HTML and bundled assets that render the bank-to-card transfer interface.
index.html
QA assets
Manual documentation and browser automation used to verify the target UI.
- Test design · Coverage strategy and QA analysis for the transfer behavior.
manual/test-design.md - Test cases · Manual scenario catalog for expected behavior and edge cases.
manual/test-cases.md - Bug reports · Recorded defects and repro notes for known issues.
manual/bug-reports.md - Evidence · Captured images used to support manual QA findings.
manual/images - Pytest suite · Automated browser test runner for UI verification and defect reproduction.
autotests/tests - Fixtures · Shared browser setup, teardown, and test wiring.
autotests/conftest.py - Selenium · WebDriver-driven interaction layer used by the tests.
- Chrome · Browser used to execute the static app and surface UI validation results.
- Driver setup · Resolves and provisions ChromeDriver for the automated runs.
autotests/requirements.txt - Success flow · Happy-path transfer scenario assertions.
autotests/tests/test_success.py - Validation checks · Empty, negative, short-card, and insufficient-funds UI validation coverage.
autotests/tests/test_empty_amount.py - Commission check · Verifies commission calculation shown by the UI.
autotests/tests/test_commission.py - Defect repros · Known-bug reproduction for boundary amount and oversized card-number behavior.
autotests/tests/test_defect_boundary.py
Execution infra
Local serving and CI orchestration around the same browser-driven path.
- HTTP server · Local Python server used to serve the built UI on localhost:8000.
- CI workflow · Workflow that installs dependencies, starts the server, and runs the Selenium suite on push and pull request.
.github/workflows/test.yml
Connections 16
- HTTP server → Transfer UI: serves · Delivers the built front-end as a static site.
- CI workflow → HTTP server: starts · Boots the local HTTP server during CI.
- CI workflow → Pytest suite: runs · Executes the browser test suite in the workflow.
- Test design → Test cases: guides · Coverage strategy informs the scenario list.
- Test cases → Pytest suite: maps to · Manual scenarios are reflected in automated checks.
- Bug reports → Defect repros: informs · Known defects become automated reproduction tests.
- Evidence → Bug reports: supports · Screenshots and captured artifacts back defect records.
- Pytest suite → Fixtures: uses · Suite relies on shared fixtures and browser setup.
- Pytest suite → Selenium: drives · Pytest cases execute through Selenium WebDriver.
- Selenium → Chrome: controls · Browser automation runs inside Chrome.
- Driver setup → Chrome: provisions · Provides the ChromeDriver used by Selenium.
- Pytest suite → Success flow: includes · Happy-path coverage.
- Pytest suite → Validation checks: includes · Input validation and insufficient-funds coverage.
- Pytest suite → Commission check: includes · Commission behavior coverage.
- Pytest suite → Defect repros: includes · Reproduction of known boundary defects.
- Chrome → Transfer UI: loads · Browser opens the served UI and exercises it via query parameters.