Description

A focused course, tailored for you

QA in Regulated Banking: From Test Plans to Audit Evidence

Build test artefacts that satisfy OCC examiners and model-risk reviewers, not just your development team.

A software QA analyst at a large US retail bank can run a textbook regression suite and still produce zero useful evidence for an OCC examiner. The test artefacts were written for developers. The examiner wants traceability from requirement to test case to defect to closure rationale, mapped against the change-management record. Most QA practitioners have never been shown how to write for both audiences at once.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

The friction shows up in three places. First, audit prep: someone from compliance drops into the sprint retro asking for the 'test evidence package' and nobody is sure what that means. Second, model-risk reviews: the MRM team asks for test coverage of the validation assumptions and the QA log does not speak to them. Third, change-advisory board submissions: the CAB wants regression scope and risk-acceptance rationale formatted to their template, not the JIRA export. Each gap is solved informally, under pressure, by whoever is available. This course makes that artefact-writing systematic.

What you walk away with

Write a requirements-traceability matrix that links every test case to a business requirement and a change-management ticket in a format the OCC examiner can follow without a technical guide.
Structure defect-closure rationale so that a 'won't fix' decision is defensible in a model-risk review, including the risk-acceptance language and the owner sign-off chain.
Build a regression-scope memo for a change-advisory board submission that names impacted controls, test coverage percentage, and the residual-risk statement.
Produce a UAT evidence package that satisfies both the business sign-off requirement and the internal audit sampling standard.
Identify which SDLC artefacts from your current process are audit-ready and which need a single structural change to become so.
Run a post-release test retrospective that surfaces pattern defects before the next OCC exam cycle, not during it.

The 12 modules

Module 1. The Two Audiences for Every QA Artefact

Most test documentation is written for one reader: the developer who needs to know what passed or failed. In a regulated bank, every artefact has a second reader: the examiner, auditor, or model-risk reviewer who needs to know that the change was controlled, tested to scope, and signed off by the right people. This module maps the gap between those two audiences and shows which structural changes to your existing artefacts close it without rewriting your entire process.

Module 2. Requirements Traceability for OCC Examiners

The OCC expects to trace a change from the business requirement that drove it, through the test cases that covered it, to the test results and the defect log. This module walks through building a requirements-traceability matrix from a real retail-banking change request. You will produce a two-page RTM template that maps requirement ID, test case ID, pass/fail result, and defect references in a format the examiner can read without technical translation.

Module 3. Writing Test Strategies That Speak to Model Risk

Model-risk management teams review software changes that touch models, calculations, or data pipelines. They need to see that the test strategy addressed the specific validation assumptions of the model, not just the functional behaviour of the code. This module covers how to identify which changes in your sprint backlog touch model-risk scope, and how to write the one-page test strategy addendum that the MRM team needs alongside your standard test plan.

Module 4. Defect Classification and Closure Rationale

A defect closed as 'won't fix' is a regulatory liability if the closure rationale does not document who accepted the residual risk and why. This module covers the defect-severity taxonomy used in OCC-examined institutions, the required elements of a risk-acceptance statement, and how to structure the closure comment in JIRA or your defect-tracking tool so that it exports cleanly into an audit package. Includes a worked example from a customer-data pipeline defect.

Module 5. Regression Scope Memos for Change-Advisory Boards

Change-advisory boards want to know: what did you test, what did you not test, and why is the untested scope acceptable? The standard JIRA test-execution report does not answer those questions. This module shows how to write a one-page regression-scope memo that names the impacted controls from the bank's control inventory, states the coverage percentage with a rationale for the gap, and includes the residual-risk statement the CAB chair needs to approve the change.

Module 6. UAT Coordination and Evidence Packaging

User acceptance testing in a retail bank involves business owners who need to sign off on the results and internal audit teams who will later sample the evidence. Both audiences have different evidence requirements. This module covers how to structure the UAT test script so that business-user sign-off is captured in a format that satisfies the internal audit sampling standard, including the required fields for the sign-off record, the retention label, and the link back to the change request.

Module 7. SDLC Controls and Your Role in the Control Matrix

Every large bank maintains a control matrix that maps its regulatory obligations to internal controls, including SDLC controls around change management and testing. Most QA analysts have never seen this matrix and do not know which controls their artefacts are the evidence of. This module explains how to read the SDLC section of a bank's control matrix, identify which of your artefacts serve as control evidence, and what happens when that evidence is missing at exam time.

Module 8. Test Data Management in a Privacy-Regulated Environment

Using production data in a test environment is a control failure that OCC examiners and state-privacy regulators both look for. This module covers the bank-standard test data management controls: data masking requirements, test environment access controls, retention and destruction of test data sets, and how to document your test data sourcing in the test plan so that an auditor can confirm the production-data isolation without a separate inquiry.

Module 9. Automated Testing and Audit Readiness

Automated regression suites produce large volumes of machine-generated output that examiners cannot easily read. This module covers how to produce a human-readable summary artefact from your automated test run: the executive test summary that states scope covered, pass rates by module, critical failures, and the sign-off chain. Includes the specific fields that OCC technology examiners have asked for in previous technology reviews at retail-banking institutions.

Module 10. Incident-to-Defect Linkage and Root Cause Records

When a production incident traces back to a defect that passed QA, the examiner asks for the original defect record, the test case that should have caught it, and the root-cause analysis. Most QA teams have the incident record in one system and the defect record in another with no formal linkage. This module covers building a lightweight incident-to-defect linkage process and writing the retrospective root-cause record in the format internal audit uses.

Module 11. Preparing the QA Evidence Package for an OCC Exam

When the OCC requests technology documentation, the QA team receives a list they have never seen before: test plans for specific releases, defect logs for specific date ranges, regression evidence for specific control changes. This module walks through assembling a QA evidence package from request to submission, including the index document that maps each OCC request to the specific artefact and how to handle requests for artefacts that were not formally retained.

Module 12. Building a QA Practice That Stays Audit-Ready by Default

The goal is a QA practice where artefacts are audit-ready as a byproduct of normal work, so exam preparation is a two-day index exercise rather than a two-week scramble. This module covers the artefact-retention policy, the sprint-closing checklist that confirms each required artefact was produced and stored, the quarterly retrospective format that surfaces pattern gaps before the next exam cycle, and how to present this practice to a new internal audit director.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

OCC exam request arrives for test evidence from a specific release: modules 2, 7, 11 give you the RTM, the control-matrix context, and the assembly process.

Model-risk review asks for test coverage of a calculation change: module 3 covers the test-strategy addendum the MRM team needs.

Change-advisory board wants regression scope before approving a deployment: module 5 covers the scope memo format and the residual-risk statement.

Production incident traced to a defect that passed QA: module 10 covers the incident-to-defect linkage record and the root-cause format internal audit requires.

What you get with this course

Twelve text-based modules in the Art of Service learning environment, each with worked examples drawn from retail and commercial banking QA scenarios.
Downloadable templates: requirements-traceability matrix, defect-closure rationale form, regression-scope memo, UAT evidence package index, OCC evidence-package index.
Hand-built implementation playbook delivered alongside course access: a 30-day action plan for applying the artefact changes to your current sprint cycle.

What you will have in hand by Day 1, Week 1, Month 1

Course access provisioned within 24 hours of purchase.

Hand-built implementation playbook delivered alongside course access.

30-day action plan structures the artefact changes across your current sprint cycle.

Before and after

Before

Test artefacts written for developers. Defect closure rationale that does not address risk acceptance. Audit prep is a two-week scramble each exam cycle. OCC requests for test evidence produce gaps.

After

Every test artefact has a regulatory audience built into its structure. Defect closure rationale is complete on the day of closure. Exam prep is a two-day index exercise. OCC evidence requests are answered from the first-pass archive.

What happens if you do not address this

The next OCC technology exam will request test evidence. If the artefacts were written only for developers, the gap becomes visible during the exam rather than before it. Remediation under examiner scrutiny costs significantly more time and credibility than building the practice correctly beforehand.

Who it is for

Software QA analysts and senior QA engineers working inside US retail banks, commercial banks, or bank technology subsidiaries. You write and execute test plans, manage regression suites, coordinate UAT with business owners, and are increasingly being asked to produce evidence that regulators and model-risk reviewers can consume. You have strong testing instincts but were never formally trained on how your artefacts feed into the bank's compliance and audit infrastructure.

Who this is NOT for. QA professionals working outside regulated industries who do not need their test artefacts to serve a regulatory audience. Also not for compliance officers who do not write or review test documentation directly.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Each module is written to be completed in one focused session of 30 to 45 minutes. The full course can be completed across two working weeks at one module per day, or in an intensive week at two to three modules per day.

Why $199 is the right number

Internal training at large banks rarely covers the intersection of QA practice and regulatory evidence. ISTQB certification teaches testing methodology but not how test artefacts feed into OCC or model-risk processes specifically. This course fills the gap between technical QA competence and the bank-regulatory context that the role now operates inside.

FAQ

Is this course specific to a particular testing tool or SDLC methodology?

No. The artefact structures and evidence standards covered apply regardless of whether your team uses JIRA, Azure DevOps, or another tool, and regardless of whether you run Agile sprints or a waterfall change process. The templates are format-agnostic and designed to be adapted to your existing tooling.

Does this cover automated testing specifically?

Module 9 covers how to produce audit-ready summary artefacts from automated test runs. The course does not teach automation frameworks or scripting; it covers the evidence and documentation layer that sits above the automated execution.

Is this relevant outside the US banking context?

The worked examples reference OCC examination standards and US retail banking change-management practices. The underlying artefact structures and evidence principles apply in other regulated financial services environments, but the regulatory-specific guidance is US-bank-centric.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.