Skip to main content

Applying Automation: AtlasBank Onboarding and KYC Flow

Prerequisites: You should already understand Applying Automation: AtlasBank Fund Transfer Suite. Leads to: After this, you'll be ready for Common Mistakes in Test Automation.

The previous module combined framework structure, data strategy, and precise assertions against a fast, largely synchronous flow. This module combines a different set — synchronization, stability, and CI integration — against a feature with a genuinely different risk shape: a multi-step, asynchronous process involving an external verification dependency.

The Feature: AtlasBank Customer Onboarding and KYC Verification​

Automating AtlasBank's new-customer onboarding flow: account details entry, identity document upload, an external KYC verification call (asynchronous, variable duration — anywhere from seconds to over a minute), and a final account-activation step that depends on verification completing successfully.

Synchronization and Stability (Section 3)​

Applying Synchronization and Wait Strategies directly: the KYC verification step gets an explicit wait for the actual verification-complete state, with a generous maximum timeout reflecting the real, wide duration range — not a hardcoded pause, which this flow's variability would make especially unreliable. Applying Test Stability and Flaky Tests: early runs of this suite show intermittent failures specifically correlated with running alongside other onboarding tests — diagnosed, per that module's discipline, as test order dependency rather than retried past.

A real defect surfaces here: the intermittent failure traces to a shared, fixed test KYC-provider sandbox account used by multiple onboarding tests, where concurrent verification requests occasionally cross-contaminate each other's results — a genuine test-isolation gap, fixed by generating a unique identity per test run rather than reusing one shared test identity, directly extending Parallel Execution's own isolation lesson to a scenario involving an external dependency, not just internal application state.

CI/CD Integration (Section 4)​

Applying CI/CD Integration: this suite, given its longer, more variable runtime (KYC verification alone can take over a minute), is deliberately configured as a required check on a slower, less frequent trigger (e.g., before merge to the main branch) rather than on every single commit — a real, considered exception to "run on every change," justified by genuine cost, not a default to imitate everywhere. Applying Test Reporting: failure reports for this suite specifically capture the KYC provider's own response payload alongside the standard screenshot and assertion detail, since diagnosing a failure here often depends on knowing what the external provider actually returned.

A second real defect surfaces here: testing the KYC provider's documented "verification inconclusive" response (distinct from a clean pass or fail, mirroring this path's own broader lesson about testing a dependency's full range of documented responses, not just its happy path) reveals the onboarding flow incorrectly treats "inconclusive" identically to "failed" — permanently rejecting an application that should instead route to manual review, a real, customer-impacting defect invisible to any test using only the KYC provider's straightforward pass/fail responses.

What This Flow Shows​

This feature's dominant risk shape is different from the previous module's: less about numeric precision and UI-state timing, more about a variable-duration external dependency's full response range and the specific isolation challenges that dependency introduces under concurrent test execution. Both modules combined multiple sections' concerns, but which concerns dominated depended on the feature's actual shape — directly echoing this path's own Selecting the Right Test Cases for Automation judgment that a feature's real characteristics, not a fixed checklist, should drive what gets emphasized.

Common Mistakes​

Mistake 1: Applying a uniform "run on every commit" CI policy without considering a specific suite's real runtime cost. This module's deliberate, justified exception (less frequent trigger for this specific, slower suite) shows CI policy itself sometimes needs feature-aware judgment, not a single blanket rule.

Mistake 2: Testing only an external dependency's happy-path response, never its documented alternative outcomes. The KYC "inconclusive" defect was only caught by deliberately testing a documented, non-happy-path response — the same lesson this path's synchronization and integration content builds toward throughout.

Mistake 3: Assuming test isolation only concerns internal application state, not external dependency interactions. The shared KYC sandbox identity defect shows isolation risk extends to anything a test shares with another test, internal or external.

Best Practices​

Practice 1: Match CI trigger frequency to a suite's actual runtime and risk profile, not a single organization-wide default. This module's KYC suite's deliberate, slower trigger is a considered exception, not a deviation to be embarrassed about.

Practice 2: Test an external dependency's full documented response range, not just its most common, happy-path outcome. The inconclusive-response defect was specifically invisible to happy-path-only testing.

Practice 3: Extend test isolation discipline to anything shared between tests, including external dependency interactions. A shared external sandbox identity is just as real an isolation risk as shared internal application state.

Key Takeaways​

  • A feature's dominant testing concerns depend on its actual risk shape — this module's onboarding/KYC feature leaned toward dependency-response-range coverage and external-interaction isolation, differently from the previous module's precision-and-timing emphasis.
  • CI trigger frequency can reasonably vary by suite, justified by genuine runtime and risk considerations, not forced into one organization-wide default.
  • Test isolation risk extends to shared external dependency interactions, not just internal application state.
  • Testing a dependency's full documented response range, not just its happy path, is what caught this module's most customer-impacting defect.

What You Just Learned​

  • How to combine synchronization, test stability, and CI/CD integration against a feature with a genuinely different risk shape than the previous module's
  • Why testing an external dependency's full documented response range matters, using a real KYC "inconclusive" defect
  • How test isolation risk extends to shared external dependency interactions, not just internal state
  • That CI trigger frequency can reasonably be tailored per suite, based on genuine runtime and risk considerations

Next: Common Mistakes in Test Automation

Interview Questions​

Q1: How would you test a feature that depends on an external, variable-duration verification service?

What to look for: A candidate who describes explicit waits with a generous timeout matching the dependency's real variability, testing the dependency's full documented response range (not just success/failure), and considering test isolation for anything shared with that dependency.

Q2: Would you always configure a test suite to run on every single commit? Why or why not?

What to look for: A candidate who recognizes that CI trigger frequency can reasonably vary based on a suite's actual runtime and risk profile — a fast, critical suite belongs on every commit; a slow, less time-sensitive suite might reasonably run less frequently, as a deliberate, justified choice.

Glossary​

No new terms are introduced in this module — every concept used above is defined in its linked source module.

Quick Revision​

Remember these five points:

✓ A feature's actual risk shape, not a fixed checklist, should determine which testing concerns get weighted most heavily.

✓ Test an external dependency's full documented response range, not just its happy path.

✓ Test isolation risk extends to shared external dependency interactions, not just internal application state.

✓ CI trigger frequency can reasonably vary per suite, based on genuine runtime and risk considerations.

✓ Combining multiple sections' concerns against a real feature surfaces defects no single concern, tested alone, would catch.