# Test brief: lending platform

Product type: lending platform. A product that originates, scores and services loans to consumers or businesses.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/lending-platform/
Printable checklist: https://howtotestaproduct.com/checklists/lending-platform/

Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: money-loss). Tool class: browser automation. Usually run by: QA engineer.
   Done when: After each release, a test borrower can apply, sign the loan agreement and see the first repayment scheduled against the account they named.
2. unit tests (risks: data-corruption, money-loss). Tool class: unit framework. Usually run by: developer.
   Done when: APR, amortization schedule and late-fee results match a reviewed spreadsheet for every loan product, including month-end and leap-day due dates.
3. integration tests (risks: money-loss, data-corruption). Tool class: API client. Usually run by: QA engineer.
   Done when: A repayment posted by the processor updates the loan balance and next due date on the servicing screen, and a returned payment reverses both.
4. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: external lab.
   Done when: An external tester cannot open another borrower's loan file by changing an ID, and cannot submit an application that skips the identity check.
5. compliance checks (risks: regulatory-penalty, fraud-abuse). Tool class: test management. Usually run by: product manager.
   Done when: For a sample of applications, a reviewer finds the dated disclosures, the identity checks performed and the adverse action notice stored with each file.
6. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer.
   Done when: In the payment sandbox, an autopay debit pulls only from the account the borrower authorized, and a granted extension cancels the debit scheduled for that date.
7. end-to-end functional tests (risks: wrong-decisions, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A declined test application produces an adverse action notice whose reasons match the factors the decision engine logged for that applicant.
8. data integrity and migration testing (risks: data-corruption, regulatory-penalty). Tool class: data validation. Usually run by: QA engineer.
   Done when: The credit bureau file for a set of test loans shows the same status, balance and days past due as the servicing screen, including a loan paid on its due date.
9. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The latest scan of the application portal and loan API shows no open finding that exposes bank statements, SSNs or credit reports.

Acceptance criteria wording:
A release of the lending platform is accepted when a test borrower can apply, sign and see the first repayment scheduled against the named account, and autopay in the sandbox pulls only from that account and skips a date covered by an extension. A declined test application produces an adverse action notice whose reasons match the logged decision factors. The credit bureau file for the test loans shows the same status, balance and days past due as the servicing screen.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.