Building Your Complete Multi-Country Testing Workflow

Not ready for a full QA sprint? See 7 Everyday Uses for Test Nexus — quick wins you can start using today.

It’s Thursday afternoon. The Brazil launch is Monday. Your team’s fintech app is adding PIX as a payment method for Brazilian users, and you’re the QA engineer responsible for signing off on the flow before release. The test plan requires you to verify that a Brazilian user can onboard, complete a PIX payment, receive a confirmation, and that the transaction correctly reaches the staging backend — all while the app correctly detects the user’s Brazilian location and displays the localized UI.

You’ve done this for other countries before. You know how it usually goes: a morning spent assembling test data from three different websites, an afternoon of manual testing where half the time goes to copy-pasting data and switching between tools, and a final hour debugging a crash that you can’t reproduce because you didn’t capture the stack trace when it first happened.

Today you’re doing it differently. Every tool you need is on the device in your hand.

This post walks through the complete session — from generating the first Brazilian test profile to filing the final bug report — using the Test Nexus modules in the order you’ll actually reach for them. No tool is introduced to demonstrate a feature. Each one enters the workflow at the moment you need it.

9:00 AM — Setup: Building Your Test Environment

Generate Brazilian Test Profiles (DataHub)

You need profiles for your test cases. The test plan covers:

1. A standard PIX payment with a complete Brazilian profile
2. A user with a long name containing accent characters (to test character handling)
3. A user with a different test profile (to test format handling across multiple Brazilian identities)
4. A user with a minimal profile (edge case: optional fields left blank)
5. Five additional profiles for repetitive flow testing

Open DataHub. Select Brazil. Generate 8 profiles in standard mode — each with a valid CPF (check digits computed), a Brazilian phone number with the correct 9-digit mobile format, a properly formatted CEP postal code, and a Visa card number that passes Luhn validation.

DataHub generates culturally appropriate Brazilian names from its bundled database — “Maria Fernanda Gonçalves” with accent characters, not “Test User Brasil.” The addresses follow Brazilian format conventions with properly formatted CEP postal codes.

Time: 3 minutes. Cost: free — all DataHub profile generation is local and uses no tokens.

Create the PIX Payment Form Schema (AI Custom Forms)

The app’s PIX payment flow has fields that standard DataHub doesn’t cover: PIX key type (CPF, phone, email, or random key), PIX key value, payment description, and payment amount in BRL. DataHub generates the identity; Custom Forms generates the payment-specific fields.

Define a custom form schema:

Form: PIX Payment

Fields:
- PIX key type (CPF / Phone / Email / Random Key)
- PIX key value (matching the key type above)
- Payment description (text, 5-50 words)
- Amount (BRL, 10.00-5000.00)

Generate 5 variations — one for each PIX key type, plus a high-value payment (R$4,999.00) to test the amount limit. The AI generates payment descriptions that read like real Brazilian transactions: “Mensalidade academia janeiro” (gym membership January), “Aluguel apartamento fevereiro” (apartment rent February).

Time: 2 minutes.

Set Mock Location to Brasília (Mock Location)

Your app uses location to determine which payment methods to display. PIX should only appear when the user’s device reports a Brazilian location. If you’re physically sitting in an office in the US, the app will show US payment methods.

Open Mock Location. Search “Brasília.” Set coordinates to -15.7942, -47.8822 (Esplanada dos Ministérios, central Brasília). Every app on the device now receives Brazilian GPS coordinates.

For later test cases, you can switch to other Brazilian coordinates to verify the app doesn’t break on different locations. But for now, Brasília.

Time: 30 seconds.

Enable Monitoring for Your App (Deep Inspector)

Before you start testing, turn on Deep Inspector health monitoring for your fintech app. It runs in the background, capturing logs from all apps and actively monitoring your selected apps for crashes, ANRs, and performance issues. If something crashes during your session, you want the stack trace and the preceding logs (context buffer) captured automatically.

Time: 1 minute. Select your app and tap “Start Monitoring.”

Connect to Staging Server (Terminal)

Open Terminal. Tap your saved “Staging DB” connection profile. SSH connects to the staging server. You’ll use this later to verify that transactions actually reach the backend, but having the connection ready means there’s no delay when you need it mid-test.

Time: 5 seconds.

Total Setup: Under 7 Minutes

Your test environment is ready:

• ✅ 8 Brazilian profiles with valid CPFs, correct phone formats, and properly formatted addresses
• ✅ 5 PIX payment variations with realistic descriptions and amounts
• ✅ GPS reporting Brasília coordinates
• ✅ Intelligent monitoring active for your app
• ✅ SSH connection to staging server open and waiting

On a typical day without Test Nexus, this setup takes 30–45 minutes: assembling test data from scattered websites, configuring a separate GPS spoofer, connecting ADB for Logcat, opening a terminal on your laptop for SSH. You’ve compressed that to 7 minutes, and everything is on one device.

9:06 AM — Test Case 1: Standard PIX Payment

Fill the Onboarding Form (Autofill)

Open the fintech app. It detects your Brasília location and displays the Brazilian onboarding flow — Portuguese language, CPF field, Brazilian address format. The localization trigger is working.

The onboarding form has 4 screens: Personal Details, Address, Identity Verification, and Financial Profile. Load Profile 1 from DataHub. When you tap into each form screen, Test Nexus Autofill populates the text fields — name, CPF, address, phone — instantly. You handle the custom widgets manually: the date picker for date of birth, the nationality dropdown, the “Next” buttons between screens, the employment status radio buttons, and the Terms & Conditions scroll-and-check on the final screen.

The 4-screen onboarding completes in about 2 minutes. You’re verifying the UI renders correctly as you go — no truncated text, no layout issues, no localization strings missing.

Result: Onboarding complete. The app shows the dashboard with PIX as an available payment method. ✅

Execute the PIX Payment

Navigate to the payment screen. This is where you use the Custom Forms data. The PIX flow asks for the key type, key value, description, and amount.

Load PIX variation 1 (CPF key type, R$150.00, “Mensalidade academia janeiro”). The Autofill injects the text fields. You select “CPF” from the key type dropdown manually.

Tap “Pay.” The app shows a processing spinner, then a confirmation screen with a transaction ID: PIX-2026-0224-0847.

Result: Payment flow completed. Confirmation screen rendered correctly. ✅

Verify the Backend (Terminal)

Did the transaction actually reach the database? Swipe to Test Nexus Terminal. Your SSH session is still connected.

Run:

SELECT id, status, amount, currency, pix_key_type, description 
FROM transactions 
WHERE id = 'PIX-2026-0224-0847';

       id              | status    | amount | currency | pix_key_type | description
------------------------+-----------+--------+----------+--------------+---------------------------
 PIX-2026-0224-0847    | completed | 150.00 | BRL      | CPF          | Mensalidade academia jan.

The transaction exists. Status is completed. Amount is R$150.00 in BRL. PIX key type is CPF. The description was truncated in the database column — is that a bug or a character limit? Note it for the bug report.

Swipe back to the app.

Result: Backend received the transaction. Description truncation noted. ✅ (with minor issue logged)

Time for Test Case 1: ~4 minutes (45 seconds onboarding + 1 minute payment + 30 seconds backend check + 1 minute noting results).

9:10 AM — Test Case 2: Long Name with Accent Characters

Load Profile 2 from DataHub — the profile with the name “Maria Fernanda Gonçalves.”

Run through the onboarding with this profile. Autofill handles the text fields. Watch the name field on Screen 1: does the full name with accent characters (ç) render correctly? Does the Review screen on page 5 display the complete name?

The onboarding completes. The dashboard shows “Maria Fernanda Gonç…” — the name is truncated in the welcome banner. The full name appears correctly in the profile settings page, but the dashboard widget cuts it off at 25 characters with no ellipsis.

That’s a UI bug. Open the app under test’s profile page, screenshot it. The bug report needs the exact name that triggered the issue and the exact screen where truncation occurs.

Time: 3 minutes. Bug found and documented. DataHub’s culturally appropriate Brazilian name — with accent characters that exercise encoding logic — surfaced an issue that “John Smith” would never trigger.

— ## 9:13 AM — Test Case 3: Different Location — Brasília

Switch Mock Location from São Paulo to Brasília: -15.7942, -47.8822.

Load Profile 3 — another Brazilian profile with a valid CPF, correctly formatted phone number, and Brazilian address.

Does the app detect the location change? Does the phone number validation accept the Brazilian format? Does the address form handle the CEP format correctly?

Run the onboarding with Profile 3 — Autofill handles the text fields, you navigate the screens manually. The flow completes. Navigate to the payment screen and execute a PIX payment with variation 2 (Phone key type).

Swipe to Terminal. Verify the transaction:

SELECT id, status, pix_key_type, pix_key_value 
FROM transactions 
ORDER BY created_at DESC LIMIT 1;

       id              | status    | pix_key_type | pix_key_value
------------------------+-----------+--------------+------------------
 PIX-2026-0224-0851    | completed | PHONE        | +5561987654321

Transaction completed with the Brazilian phone number as the PIX key. The +5561 prefix confirms the Brasília area code was stored correctly.

Time: 4 minutes. Location switch + onboarding + payment + backend verification.

9:17 AM — Test Case 4: The Crash

You’re testing Profile 4 — a minimal profile with optional fields left blank. The goal is to verify the app handles empty optional fields gracefully.

Halfway through the onboarding, you skip the optional “Employer Name” field and tap Next. The app crashes.

You didn’t see the crash coming, and you didn’t have Logcat running. But Deep Inspector was active for your app.

Open Test Nexus. Tap Deep Inspector. The crash is already captured in your issue timeline:

FATAL EXCEPTION: main
java.lang.NullPointerException: Attempt to invoke virtual method 
  'int java.lang.String.length()' on a null object reference
    at com.fintech.app.onboarding.FinancialProfileValidator.validateEmployerName(FinancialProfileValidator.java:89)
    at com.fintech.app.onboarding.FinancialProfileFragment.onNextClicked(FinancialProfileFragment.java:142)
    at com.fintech.app.onboarding.FinancialProfileFragment$1.onClick(FinancialProfileFragment.java:67)

Root cause (from reading the trace): FinancialProfileValidator.validateEmployerName() at line 89 calls .length() on a null String. The “Employer Name” field is optional, but the validator doesn’t null-check before calling .length(). When the field is empty, it passes null instead of an empty string.

Device context captured by Deep Inspector:

• Device: Pixel 7, Android 14, SDK 34
• Memory: 3.1 GB available / 8 GB total
• Network: Wi-Fi
• Battery: 82%, not charging
• Timestamp: 9:18:23 AM

Tap Copy. Open your bug tracker. Paste. Add context:

Bug: NullPointerException when "Employer Name" is left blank 
     during onboarding

Steps:
1. Start onboarding with a Brazilian profile
2. On Screen 4 (Financial Profile), leave "Employer Name" empty
3. Tap Next
4. App crashes

Root cause: FinancialProfileValidator.java:89 calls 
String.length() on null. No null check for optional field.

Fix: Add null check: 
  if (employerName != null && employerName.length() > MAX_LENGTH)

Stack trace: [full trace from Deep Inspector]
Device context: [captured automatically]

Severity: High — blocks onboarding for any user who skips 
the optional Employer Name field.
Reproduction: 100% with any profile where Employer Name is null.

Time: 3 minutes from crash to filed bug report with complete stack trace, root cause analysis, and suggested fix. Without Deep Inspector, you would have spent 15 minutes connecting ADB, reproducing the crash, and scrolling Logcat to find the trace.

9:20 AM — Test Cases 5–8: Repetitive Flow Testing (Autofill)

Four profiles remain. The onboarding flow is the same for all of them, and you’ve already verified the screens manually in Test Cases 1–3. Now you need volume: does the app handle four more Brazilian profiles without errors?

Load Profiles 5 through 8 one by one. For each:

1. Load the profile from DataHub
2. Autofill handles the text fields on each screen
3. Navigate through the 4-screen onboarding (custom widgets + Next buttons)
4. Execute a PIX payment with the next payment variation
5. Glance at Deep Inspector — any crashes?
6. Spot-check Terminal — did the transaction land?

Each run takes about 3 minutes. Autofill eliminates the most time-consuming part — data entry. You still handle the navigation and custom widgets, but your brain is free to watch for visual bugs, layout issues, and unexpected behavior.

Time: 12 minutes for four complete onboarding + payment flows. Without Autofill, this would be 20+ minutes of repetitive typing and copy-pasting.

9:28 AM — Session Summary

In 28 minutes, you’ve completed:

Results: 8 test cases completed. 2 bugs found. 1 crash captured with full stack trace.

What Each Module Contributed

Total time saved: roughly 90 minutes of overhead eliminated. The 28-minute session would have been a 2-hour session with the old workflow — and you might have missed the crash entirely without Deep Inspector running.

Everything from this session — the 8 Brazilian profiles, the PIX payment schemas, the saved SSH connection, the captured crash trace, the mock location history — is stored in AES-256 encrypted local databases on the device. Nothing was transmitted to any external server.

9:30 AM — Switching Countries: Australia in 5 Minutes

The Brazil session is done. Your test plan also requires a basic smoke test of the Australian payment flow (BPAY). Here’s how fast the environment switch is when everything is on one device:

Step 1: Change DataHub country (30 seconds) Open DataHub → Select Australia → Generate 3 profiles with TFN (Tax File Numbers), +61 4XX mobile numbers, valid postcodes, and BSB bank identifiers.

Step 2: Change Mock Location (15 seconds) Open Mock Location → Search “Sydney” → Set coordinates to -33.8688, 151.2093 (Sydney CBD).

Step 3: Deep Inspector and Terminal (0 seconds) Already running. Deep Inspector is still monitoring. Terminal’s SSH session is still connected. Nothing to reconfigure.

Step 4: Test (4 minutes) Load an Australian profile → Autofill the onboarding form → Execute a BPAY payment → Verify in Terminal.

Total country switch: under 5 minutes from “done with Brazil” to “Australian smoke test complete.”

With the old workflow, switching countries meant: regenerating all test data from different websites, reconfiguring the GPS spoofer for Sydney coordinates, and updating your mental context for Australian formatting rules. That’s 20–30 minutes of setup overhead before you even start testing.

The Workflow Diagram

Here’s the complete flow from this session, visualized as the sequence you’ll repeat for any country:

┌─────────────────────────────────────────────────────┐
│                    SESSION SETUP                     │
│                                                      │
│  DataHub ──→ Generate country-specific profiles      │
│  Custom Forms ──→ Generate domain-specific test data │
│  Mock Location ──→ Set GPS to target country/city    │
│  Deep Inspector ──→ Start background monitoring      │
│  Terminal ──→ Connect to staging server               │
│                                                      │
│  Time: ~6 minutes                                    │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│                   TEST EXECUTION                     │
│                                                      │
│  For each test case:                                 │
│                                                      │
│    1. Load profile from DataHub                      │
│    2. Autofill text fields into target app            │
│    3. Navigate screens and custom widgets manually    │
│    4. Execute the feature under test (payment, etc.) │
│    5. Deep Inspector captures any crash automatically │
│                                                      │
│  Time: 2-4 minutes per test case                     │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│                   VERIFICATION                       │
│                                                      │
│  Terminal ──→ SSH query to verify backend state       │
│  Deep Inspector ──→ Review any captured crashes       │
│                                                      │
│  Time: 30 seconds per verification                   │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│                  COUNTRY SWITCH                       │
│                                                      │
│  DataHub ──→ Change country, generate new profiles   │
│  Mock Location ──→ Change coordinates                │
│  (Deep Inspector + Terminal stay running)             │
│                                                      │
│  Time: ~1 minute                                     │
│                                                      │
│  Repeat from TEST EXECUTION for next country         │
└─────────────────────────────────────────────────────┘

The loop is the key insight. Once you’ve built the workflow for one country, testing additional countries is a 1-minute environment switch — not a 30-minute reconfiguration. The tools stay running. The connections stay open. Only the test data and GPS coordinates change.

What This Series Covered

This post wraps up the core Test Nexus launch series. Here’s what we covered and where to find it:

Every post was written for the same person: the one holding the test device. If you’ve read this far, you’ve seen every module in context, understood what each one replaces in the old workflow, and watched them work together in a real test session.

The tool is on the Play Store. The 20,000 free tokens are waiting. Your next multi-country test session doesn’t have to involve six disconnected tools, a laptop, and a spreadsheet.

🚀 Run your first complete test session with every module.
Generate test data. Set a mock location. Enable crash monitoring. Open a terminal. Autofill your forms. All on one device.
Download Test Nexus →