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.
What non-functional requirements are, the categories that matter, and how to write NFRs that are testable: 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 the three differ and when each runs.
What SQL window functions do 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, with the action each implies.
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.
When money must come back, ISO 20022 gives three distinct mechanisms: 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. With a diagram.
A dbt DAG is the dependency graph of your transformations, built from ref() calls. How to read one, the staging to marts convention, and why tests live 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 when outputs are non-deterministic. Use bounds, properties, guardrails, and evaluation sets, not exact matches.
A practitioner guide to API testing: status codes, response schemas, request chaining, authentication, error contracts, and the checks that actually catch defects.
Batch and event-driven processing differ in timing, and that difference 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. With examples.
What contract testing is, how it differs from integration testing, and how consumer-driven contracts catch breaking API and event changes before they reach 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. With examples.
How to use decision tables to specify complex business rules completely: conditions, actions, rule columns, and collapsing combinations. The tool that leaves no case undefined.
Field notes on going from intimidated to fluent with OpenAPI: what confused me, what clicked, and how reading the contract myself changed how I work as an analyst.
A practical functional specification template: scope, actors, data, business rules, behavior, error handling, and acceptance criteria. The structure that makes 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.
A walkthrough of how a technical business analyst actually investigates a failed payment: the questions, the tools, and following one transaction from the complaint to the cause.
Write API requirements the right way: 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 vs 200 matters in payments. Practical, not exhaustive.
How to test idempotency in APIs and event consumers: idempotency keys, duplicate requests, redelivered events, and the race conditions that cause double processing.
How an analyst reads JSON: objects, arrays, nesting, and types. Understand API payloads, event messages, and config without asking a developer. Practical, not theory.
A practitioner guide to testing Kafka: consuming events in a test, asserting schema and key, verifying ordering, duplicates, and the consumer side effects that matter.
How to design negative tests systematically: boundary values, invalid inputs, state violations, and failure injection. The unhappy path is where the real defects live.
A field-by-field guide to writing pacs.008 test cases: mandatory fields, structured data, validation, reason codes, and the pacs.002 responses that prove each case.
How payment messages flow end to end in ISO 20022: pain.001 initiation, pacs.008 interbank, pacs.002 and pain.002 status, and camt reporting. A systems analyst map.
A practitioner guide to payment testing: following one transaction through ingestion, events, settlement, and status, plus the rejection and stuck-payment cases that matter.
The production support skills that make a technical analyst invaluable: triage, tracing transactions, reading logs, calm under pressure, and turning incidents into requirements.
How an analyst reads an API contract: endpoints, methods, request and response schemas, status codes, and OpenAPI structure. Understand any API without asking a developer.
Field notes from a major payments incident: how reading logs under pressure works, what the trail revealed, and the lessons about observability that became requirements.
How an analyst reads production logs to understand and 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 regex, not theory.
How to do regression testing in payment systems: what to retest, building a regression suite, risk-based selection, and automating the 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 the truth.
How to model a payment as a state machine: define the states, the allowed transitions, the triggers, and the illegal moves. The tool that makes status behavior precise.
User stories capture intent; specifications capture exact behavior. Here is 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. Here is what the role does in payments.
A functional analyst turns business intent into precise, testable system behavior. Here is 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 the acceptance criteria did not work: 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.
Newsletter
Practical, no-fluff playbooks for technical analysts who analyze, code, test, and support. New articles straight to your inbox.
No spam. Unsubscribe anytime.