How Banking Companies Use Automation Testing to Grow Faster

# payment_flow.spec.ts — a Playwright test for a banking payment flow
# The kind of regression test every bank runs on every commit.

import { test, expect } from '@playwright/test';

test.describe('Fund transfer flow', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('https://demo-bank.example.com/login');
    await page.fill('input[name="username"]', 'demo_user');
    await page.fill('input[name="password"]', 'demo_pass');
    await page.click('button[type="submit"]');
    await expect(page).toHaveURL(/dashboard/);
  });

  test('transfers money to a saved beneficiary and shows confirmation', async ({ page }) => {
    await page.click('text=Transfers');
    await page.selectOption('select[name="beneficiary"]', { label: 'Rahul Sharma' });
    await page.fill('input[name="amount"]', '5000');
    await page.fill('input[name="remarks"]', 'rent');
    await page.click('button:has-text("Continue")');

    // OTP step
    await page.fill('input[name="otp"]', '123456');
    await page.click('button:has-text("Confirm")');

    // Confirmation screen
    await expect(page.locator('.confirmation')).toContainText('Transfer successful');
    await expect(page.locator('.reference')).toHaveText(/TXN\d+/);

    // Balance updated
    await page.click('text=Dashboard');
    await expect(page.locator('.balance')).not.toContainText('0.00');
  });

  test('rejects transfer when amount exceeds balance', async ({ page }) => {
    await page.click('text=Transfers');
    await page.selectOption('select[name="beneficiary"]', { label: 'Rahul Sharma' });
    await page.fill('input[name="amount"]', '9999999');
    await page.click('button:has-text("Continue")');

    await expect(page.locator('.error')).toContainText('Insufficient balance');
  });
});

// Why this test matters to a bank:
// - Transfers are the highest-value flow in retail banking.
// - Success and failure paths both get tested.
// - OTP flow is included — a common regression point.
// - Balance verification proves the transaction actually landed.
//
// Why it is valuable for QA careers:
// - Shows you can write end-to-end tests for a critical banking flow.
// - Demonstrates knowledge of edge cases (insufficient balance).
// - Proves you understand banking domain rules, not just UI clicks.

# test_payment_api.py — an API contract test for a banking payment API
# Banking is API-heavy. Contract tests catch breaking changes before customers do.

import pytest
import requests

BASE_URL = "https://api.example-bank.com"


@pytest.fixture
def auth_headers():
    resp = requests.post(f"{BASE_URL}/auth/token", json={
        "client_id": "test-client",
        "client_secret": "test-secret",
    })
    token = resp.json()["access_token"]
    return {"Authorization": f"Bearer {token}"}


def test_payment_requires_authentication():
    resp = requests.post(f"{BASE_URL}/payments", json={})
    assert resp.status_code == 401


def test_payment_creates_transaction_with_correct_amount(auth_headers):
    resp = requests.post(
        f"{BASE_URL}/payments",
        json={
            "from_account": "ACC123",
            "to_account": "ACC456",
            "amount": 100.00,
            "currency": "INR",
            "purpose": "rent",
        },
        headers=auth_headers,
    )
    assert resp.status_code == 201
    body = resp.json()
    assert body["amount"] == 100.00
    assert body["currency"] == "INR"
    assert body["status"] == "initiated"
    assert body["id"].startswith("txn_")


def test_payment_rejects_negative_amount(auth_headers):
    resp = requests.post(
        f"{BASE_URL}/payments",
        json={"from_account": "ACC123", "to_account": "ACC456", "amount": -100},
        headers=auth_headers,
    )
    assert resp.status_code == 400
    assert "amount" in resp.json()["error"].lower()


def test_payment_rejects_unsupported_currency(auth_headers):
    resp = requests.post(
        f"{BASE_URL}/payments",
        json={
            "from_account": "ACC123",
            "to_account": "ACC456",
            "amount": 100,
            "currency": "XYZ",
        },
        headers=auth_headers,
    )
    assert resp.status_code == 400


# Why banks love API contract tests:
# - They run in milliseconds — thousands per commit.
# - They catch breaking changes before the UI is even tested.
# - They support regulatory traceability and audit evidence.
# - They work across microservices and third-party integrations.
#
# Why this matters for QA careers:
# - Modern banking QA is mostly API-first.
# - Contract tests are a differentiator for banking SDET roles.

# .github/workflows/banking-tests.yml — CI that blocks risky releases
# Banking teams gate deployments on automation — this is what makes it real.

name: Banking Test Suite

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest playwright
          playwright install --with-deps

      - name: Run unit and API tests
        run: pytest tests/unit tests/api --maxfail=1 --disable-warnings

      - name: Run critical E2E tests (payment flows)
        run: pytest tests/e2e/payments --maxfail=1

      - name: Enforce coverage threshold
        run: pytest --cov=app --cov-fail-under=85

  # What this CI does for a bank:
  # - No merge into main without passing unit, API, and E2E tests.
  # - Coverage threshold prevents silent erosion of test quality.
  # - Failing payment E2E tests block the deploy automatically.
  # - The pipeline is auditable — every run is logged.

  # What "automation testing" means in practice at a bank:
  # - It is not a tool. It is a gate.
  # - It replaces hours of manual regression with minutes of CI.
  # - It makes weekly releases possible for banking products.