QA Analyst
A QA analyst proves the system does what the specification promised, from API contract tests to validating event flows. This pillar covers that work in practice: designing negative tests, testing payment and idempotency flows end to end, validating Kafka events you cannot see, and catching breaking changes with contract tests before they ship. Every article is written for analysts who own quality on a delivery team, with concrete test cases you can run.
The parts for a QA analyst joining a new team: feedback with good timing, and the role guide on inheriting a green regression suite the sprint before a SEPA Instant release.
Where requirements work meets the suite: UAT scenarios generated from use case flows, a test strategy that makes decisions, and a CI gate that fails the release when a must-have requirement is not proven.
The two parts built for quality work: a complete test plan with a traceability matrix, and the runnable collection that gates a merge.
The advanced track covers the testing side end to end, from deriving cases to running them as a release gate.
Use agentic coding tools as an analyst who codes: plan mode, permission modes, AGENTS.md and CLAUDE.md, hooks, worktrees, and four jobs with the guardrails.
Load test a payments API with Grafana k6 v2: write the NFR first, then scenarios, thresholds, and checks, safe idempotency keys, test types, and a CI run.
The Arazzo Specification for analysts: sourceDescriptions, steps, successCriteria, and runtime expressions, with a Stripe payment-to-refund workflow to run.
How to read and review an AsyncAPI 3.0 contract for Kafka: channels, operations, messages, bindings, keys, ordering, and schema registry compatibility.
How CBPR+ replaces MT 199 queries and MT 192 recalls: camt.110 and camt.111 investigations, camt.056 and camt.029, Case Management, dates, and tests.
Regulation (EU) 2023/1113, the EU travel rule: required payer and payee data, the pacs.008 fields that carry it, missing information handling, crypto, tests.
How analysts write LLM evals: a golden set from acceptance criteria, code graders vs LLM-as-judge, pass thresholds as release criteria, and regression in CI.
Moving interbank MT101 to CBPR+ pain.001 under the Payment Initiation Relay rulebook: the deferred dates, MT101 to pain.001 mapping, addresses, and test cases.
Open banking APIs for bank analysts: AIS vs PIS, the consent lifecycle, SCA, FAPI 2.0, PSD3, UK, US 1033, and Canada status, plus the test cases that matter.
What changed from OpenAPI 3.0 to 3.1 and 3.2, from nullable to type arrays, webhooks, QUERY and streaming, and what to check when a provider upgrades.
Read OpenTelemetry traces like an analyst: spans, attributes, the traceparent header, trace_id vs UETR, and finding the slow span in Jaeger, Tempo, or Datadog.
Postman CLI vs Newman in CI: install and run commands, JUnit reports, spec linting, where results go, GitHub Actions YAML, and the git-native Bruno CLI.
Fuzz an API from its OpenAPI contract with Schemathesis 4: run command, checks, negative and stateful tests, JUnit in CI, and triaging findings into defects.
SEPA Direct Debit Core and B2B for analysts: mandates, pain.008 and pacs.003, sequence types, D-1 timelines, R-transactions, reason codes, and a test matrix.
How the SWIFT gpi Tracker works for analysts: the UETR, ACSP with G000 to G004, ACCC and RJCT, the update channels and API, Stop and Recall, and what to test.
A 90 day onboarding plan for technical analysts in four phases: orient, map, contribute, own. What to produce each week, with a banking ISO 20022 example.
How a new analyst asks better questions: map who knows what, run first-week 1:1s, use the checked-X-think-Z format, batch questions, and keep a questions log.
How a new analyst gives useful feedback: keep an observation log, raise risk now and the rest at day 30, use evidence and SBI, and share drafts at 30%.
How an analyst runs a 90 day onboarding review: a scored self-assessment, the evidence to bring, a retrospective, and the guide you leave the next joiner.
How a QA analyst onboards: map the environments, inventory test data, read the inherited suite for real coverage, and name three gaps before the next release.
Every analyst career move on one map: switching in, going more or less technical, moving up, and earning more, with timelines, pay deltas, and real cases.
A 60 day plan for analysts after a layoff or career break: explain the gap in one sentence, refresh skills, reconnect, bridge with a contract, hold your pay.
How to build an analyst portfolio when your real work is confidential: 3 to 5 pieces, public or synthetic data, the right pieces per role, and a 5 minute pitch.
Realistic 2026 analyst pay by role and level in the US, Canada, UK, and Eurozone: BA, technical BA, QA, SDET, data, architecture, product, and contract rates.
Which analyst certifications are worth it in 2026: CBAP, CCBA, ISTQB, PSPO, SAFe, cloud, data, and domain credentials ranked by career return for each role.
An internal move is the cheapest analyst career change: 3 to 9 months, usually no pay cut. The step plan, the move proposal, and how to ask for a regrade.
How career changers pass analyst interviews: scripts for why the switch and no experience, the seven common case exercises, STAR stories, and the pay question.
Manual QA to SDET pays 25 to 40 percent more at the same level. The stack to learn, a 6 to 12 month plan with artifacts, the AI angle, and three real moves.
How QA testers become business analysts: what transfers, the elicitation and scope gap, a six month plan, real cases, and the typical 10 to 25 percent raise.
When AI generates code in seconds, a developer's value moves to proving it works: testing, review, quality, release notes, demos, proactivity, and coaching.
AI writes tests that mirror the code, bugs included. Derive tests from the requirement, add property and contract tests, prove the suite with mutation testing.
Reviewing AI-generated code: the failure modes to hunt for, the review order that finds them, what CI should automate, and a PR template that makes it fast.
Stripe's PaymentIntents API scored on a 12-check contract review: 22 of 24, plus the idempotency, webhook, versioning, and lifecycle findings teams must own.
A repeatable review that finds edge cases missing from your specification: nine lenses, one prompt each, run as a script before requirements are signed off.
Generate a Mermaid sequence diagram from a Bruno or Postman collection run: the trace script, the Postman CLI or newman JSON export, the prompt, and CI wiring.
Turn manual Kafka checks into an automated Postman collection: produce and consume over REST Proxy, poll with backoff, assert schema and ordering, run in CI.
What retrieval-augmented generation is, the eight stages where it fails, the requirements an analyst writes for each, and a golden-set harness that proves it.
A working pipeline from workshop transcript to signed UAT result for every requirement: eight stages, three machine-readable formats, and four CI gates.
Turn correlated Splunk or Datadog logs into an accurate Mermaid sequence diagram with AI. The queries, the export shape, the prompt, and the verification step.
Write a test strategy that makes decisions, turn conditions into an executable suite, run it in CI with Xray and Datadog, and generate coverage proof.
Document use cases as structured data, generate Gherkin UAT scenarios from them, keep the requirement id on every scenario, and produce the sign-off pack.
Turn an OpenAPI contract into a Bruno or Postman collection with real assertions, generate the chaining scripts, and put the whole suite behind a CI gate.
The rules of engagement for AI in a regulated delivery team: what data never leaves, how to mask it, tool tiers by blast radius, and the audit trail you keep.
Build a complete test plan with AI in seven steps: risk, scope, conditions, cases, data, environments, and a traceability matrix proving nothing is uncovered.
How pain.001 batching works: the three-level structure, BatchBooking, how a batch becomes statement entries, and what happens when one payment fails.
The amount fields in a pacs.008: instructed amount, interbank settlement amount, exchange rate, and the rules that decide which number the beneficiary receives.
The charge bearer codes in a pacs.008, what each one obliges every agent in the chain to do, and how ChrgsInf records who actually took what.
How the cover method works: pacs.008 to the beneficiary bank, pacs.009 COV to the correspondents, and why the two must carry identical underlying details.
Which ISO 20022 fields sanctions screening reads, why structured addresses cut false positives, and the screening defects an analyst finds in every migration.
How SCT Inst changes payment design: a ten second end-to-end limit, 24/7/365 availability, irrevocability, and the screening and liquidity problems that follow.
Why analysts who send, chain, and script API requests move faster: verified requirements, reproducible defects, faster triage, credible POCs, and a 30-day plan.
Chain API requests in Bruno and Postman: capture values, pre-request and post-response scripts, token refresh, polling, branching, and a Stripe sandbox flow.
The OWASP API Security Top 10 (2023) as test cases analysts can run in Bruno or Postman: object and field authorization, auth, limits, business flows, and more.
How to write API test cases from the contract: a six-source derivation method, 40 worked cases for one payment endpoint, and data-driven automation in Bruno.
Run API test collections in CI with Bruno CLI, Postman CLI, or Newman in GitHub Actions: secrets, tags, JUnit and HTML reports, private networks, flaky tests.
What counts as a breaking API change, versioning strategies, Deprecation and Sunset headers, detecting breaks with oasdiff, and consumer impact assessment.
Build a first API collection in Bruno and Postman: environments, variable precedence, inherited auth, secrets in .env or a vault, and cURL imports.
GraphQL for analysts: queries, variables, mutations, errors returned with HTTP 200, cursor pagination, and hands-on testing of the GitHub GraphQL API in Bruno.
How webhooks work and what analysts must specify: events, signatures, retries, duplicates, and ordering, plus testing with webhook.site and the Stripe CLI.
Troubleshoot failed API requests by symptom: connection and SSL errors, 401 vs 403, wrong-URL 404s, 415 and 422, 429, 5xx, CORS, and unresolved variables.
When an AI agent beats a single prompt for analyst work, what tools it needs, where the guardrails go, and the three agent flows worth building first.
Which analyst tasks to automate first, ranked by payback: environment checks, test data setup, reconciliation, contract validation, ticket evidence.
Six reusable prompt patterns for requirements work: grounded extraction, format contract, adversarial review, gap interrogation, traceability, testability.
Triage is a classification problem with money attached. How to rank by business impact, settle defect versus change request fast, and defer a defect on purpose.
A go decision is made under uncertainty. The analyst's job is to make it explicit, not make it disappear. The readiness dimensions and the evidence.
The output of refinement is not an estimate, it is decisions closed. What to bring, how to split a story without knowing the code, and what ready means.
QA finds where the system disagrees with the spec, and you wrote the spec. An untestable requirement is an analyst defect. How to be the partner QA needs.
The difference between an API key, a personal access token, and an OAuth token, how to scope and rotate them, and where they belong across an analyst toolchain.
Use a personal access token and the Jira and Confluence REST APIs to generate traceability matrices and publish specs, with working Python scripts.
Bruno keeps API collections as files in your repo with no account; Postman wraps them in a cloud platform, now with Native Git. Trade-offs for pacs.008 tests.
A Claude Skill packages your method, references, and scripts into a folder the model loads on demand. Build one that writes pacs.008 test cases.
ISO 20022 carries rich structured data, and every non-native hop quietly degrades it. The field-by-field loss ledger, and how to specify what you accept losing.
Five identifiers travel with every payment and only one survives the whole chain. Which to trace on, reconcile on, deduplicate on, and never use as a key.
Namespaces, element order, the business header, empty vs absent, amount precision, and code choices. The XML layer that fails messages your test tool accepts.
What non-functional requirements are, the categories that matter, and how to write testable NFRs with measurable targets instead of adjectives. With examples.
Smoke testing proves the build is testable, sanity testing proves a fix landed, regression testing proves nothing else broke. How they differ, when each runs.
SQL window functions and the three patterns analysts use daily: ROW_NUMBER for latest record per group, LAG for event timing, SUM OVER for running totals.
What user acceptance testing is, how UAT differs from SIT and QA testing, who writes the scenarios, and the entry and exit criteria that make a UAT cycle real.
The ISO 20022 payment transaction statuses explained: RCVD, ACTC, ACCP, ACSP, ACSC, PDNG, RJCT, and more, with the lifecycle order and what each guarantees.
The ISO 20022 reason codes analysts meet daily: account codes (AC01, AC04, AC06), amount codes (AM04, AM05), agent and regulatory codes, and what each means.
Which ISO 20022 message replaces each SWIFT MT: MT103 to pacs.008, MT202 to pacs.009, MT940 to camt.053, and the traps in the mapping. A reference table.
ISO 20022 gives three ways to bring money back: returns, reversals, and recalls. Who initiates each, which message carries it, and how to model them.
Airflow schedules tasks; Dagster declares the data assets those tasks produce. What the task vs asset split means for lineage, testing, and debugging pipelines.
Data lineage maps how each field flows from source through transformations to the report that shows it, enabling impact analysis, trust, and audit.
A dbt DAG is the dependency graph of transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests sit on nodes.
dbt and SQLMesh both turn SQL into tested, versioned transformation pipelines. Where they differ: SQL parsing, environments, incremental state, and lineage.
Both write code against the same systems. The backend developer owns the production system; the developer analyst uses code to verify and automate analysis.
A functional analyst is accountable for exact system behavior; a product owner for what gets built and in what order. The split, and which seat fits you.
The medallion architecture organizes a lakehouse into bronze (raw), silver (cleaned), and gold (business-ready) layers. What each layer owns, with a diagram.
A QA analyst derives what must be tested from requirements and risk; a test engineer builds the automation that runs it at scale. The split and the overlap.
A self-assessment matrix of 25 skills across the five technical analyst hats, with three levels per skill and where to build each one. Original to this site.
How to write acceptance criteria for AI and LLM features with non-deterministic outputs: bounds, properties, guardrails, and eval sets, not exact matches.
A practitioner guide to API testing: status codes, response schemas, request chaining, authentication, error contracts, and checks that catch real defects.
Batch and event-driven processing differ in timing, which shapes latency, failure modes, and customer experience. When to use each, with banking examples.
How to turn a vague business requirement into a precise functional specification: decompose intent, define inputs and outputs, and write testable behavior.
What contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before production.
What a dead-letter queue is, why event-driven systems need one, and how an analyst specifies DLQ behavior: retries, routing, monitoring, and recovery.
Use decision tables to specify complex business rules completely: conditions, actions, rule columns, and collapsing combinations so no case is undefined.
Field notes on going from intimidated to fluent with OpenAPI: what confused me, what clicked, and how reading the contract myself changed my analyst work.
A functional specification template: scope, actors, data, business rules, behavior, error handling, and acceptance criteria that make a spec buildable.
The Git an analyst actually needs: clone, navigate, read a diff, browse history, and find when behavior changed. Read the codebase without breaking anything.
How a technical business analyst investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the root cause.
How to write API requirements: endpoint, method, request and response schema, status codes, error contracts, and testable acceptance criteria. With examples.
An analyst's guide to HTTP status codes: the 2xx, 4xx, and 5xx families, what each common code means, and why 202 Accepted vs 200 OK matters in payments.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and race conditions behind double processing.
How an analyst reads JSON: objects, arrays, nesting, and types. Understand API payloads, event messages, and config files without asking a developer.
A guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering and duplicates, and checking consumer side effects.
Design negative tests systematically: boundary values, invalid inputs, state violations, and failure injection, since real defects live on the unhappy path.
A field-by-field guide to pacs.008 test cases: mandatory fields, structured data, validation, reason codes, and the pacs.002 responses that prove each case.
How ISO 20022 payment messages flow end to end: pain.001 initiation, pacs.008 interbank, pacs.002 and pain.002 status, and camt reporting, for analysts.
A practitioner guide to payment testing: one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases.
Production support skills for technical analysts: triage, tracing transactions, reading logs, staying calm, and turning incidents into requirements.
How an analyst reads an API contract: endpoints, methods, request and response schemas, status codes, and OpenAPI structure, without asking a developer.
Field notes from a major payments incident: reading logs under pressure, what the trail revealed, and the observability lessons that became requirements.
How an analyst reads production logs to debug a system: correlation ids, log levels, searching by transaction, and following one request across services.
How to map payment reason codes to causes and customer messages: ISO 20022 codes like AC04, internal errors, and the mapping that prevents support incidents.
The regular expressions an analyst actually needs: matching patterns in logs, validating formats like IBAN and BIC, and searching data. Practical, not theory.
Regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating checks that protect live behavior.
What a requirements traceability matrix is, how to build one, and why it proves every requirement is designed, built, and tested. With a payments example.
How an analyst uses Python to automate repetitive checks: calling APIs, comparing files, querying data, and chaining requests. Small scripts, large leverage.
The SQL a technical analyst actually needs: SELECT, WHERE, JOIN, GROUP BY, and reading state during analysis and testing. Not for reports: for finding truth.
How to model a payment as a state machine: the states, allowed transitions, triggers, and illegal moves. The tool that makes payment status behavior precise.
User stories capture intent; specifications capture exact behavior. The real difference, when each fits, and why complex systems need both. With examples.
A developer analyst reads and writes enough code to verify, automate, and prototype without becoming a full-time engineer. What the role does in payments.
A functional analyst turns business intent into precise, testable system behavior. What the role does in banking and payments, and how it differs from a BA.
A QA analyst proves a system behaves correctly by testing it end to end, not by reading the spec. Here is what the role does in banking and payments.
Field notes on an AI project where acceptance criteria failed: why exact-match criteria break on non-deterministic output, and what we replaced them with.
Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.
Free account
A free account, no password: an email link signs you in. It saves your steps and self-assessments on the Labs, shows your missions on a dashboard, unlocks the solutions, and, if you tick the box, sends you new missions and articles when they ship.
Your email is used to sign you in. Nothing else, unless you ask. Privacy.