Terminal: SSH, SFTP, and Port Forwarding From Your Test Device

The payment went through. At least, the app says it did — the success screen loaded, the confirmation animation played, the receipt appeared with a transaction ID. Test passed?

Not yet. You need to verify the backend actually received the transaction. The app’s UI showing “success” only proves the frontend rendered a success state. It doesn’t prove the API call completed, the database wrote the record, or the payment processor acknowledged the charge. You’ve seen this before — a retry loop in the network layer silently failed, the frontend optimistically displayed success based on a cached response, and the actual transaction never hit the server. That’s a production bug that slips through if you only test what the screen shows.

So you start the verification sequence:

1. Put the phone down
2. Open your laptop (which is in your bag, because you were doing mobile testing)
3. Wait for it to wake up
4. Open a terminal
5. Type ssh qa@staging.yourcompany.com
6. Enter your key passphrase
7. Run psql -d payments -c "SELECT id, status, amount FROM transactions ORDER BY created_at DESC LIMIT 1;"
8. Read the result — the transaction exists, status is completed, amount matches
9. Close the laptop
10. Pick the phone back up
11. Try to remember exactly where you were in the test flow

The backend check took 90 seconds. But the real cost is the context switch. You were in a testing flow — systematically working through a multi-step scenario with a specific test identity, a specific mock location, and a specific sequence of actions. When you put the phone down and opened the laptop, that flow broke. When you picked the phone back up, you spent another 30 seconds reorienting: which step was I on? Did I already test the refund path? Was I using the Brazilian profile or the Australian one?

Now multiply that by the number of backend checks in a typical test session. Payment verification, user creation check, notification delivery confirmation, file upload verification, API rate limit check — each one is the same 90-second interrupt with the same context rupture. Five backend checks in a session means seven and a half minutes of pure overhead, plus the accumulated cognitive cost of breaking and resuming your flow five times.

Test Nexus Terminal eliminates the laptop from this workflow entirely. SSH into your staging server from the same device you’re testing on. Run the query. See the result. Swipe back to the app. Your testing flow never breaks because you never put the phone down.

The Context Switch Is the Cost

It’s worth being explicit about why this matters, because “SSH from your phone” sounds like a convenience feature, not a testing improvement. The improvement isn’t typing commands on a smaller screen. It’s removing the device transition that fragments your test session.

What Breaks When You Pick Up Your Laptop

Your mock location resets if you’re unlucky. On some devices and Android versions, the mock location provider can lose its override when the screen turns off during the time you’re on your laptop. You come back to the phone and your GPS is reporting your real location instead of the test coordinates.

Deep Inspector might miss a crash. If a background process in the app under test crashes while you’re on your laptop and the phone screen is off, the crash still gets captured — but you don’t see the notification until you pick the phone back up, and by then you’ve lost the immediate context of what was happening when it crashed.

Your mental model of the test state decays. This is the real cost. Manual testing requires holding a mental model of where you are in a flow: which fields you’ve filled, which branches you’ve tested, which edge cases remain. Every context switch degrades that model. After a 90-second laptop detour, you spend 30 seconds rebuilding it. After five detours, your session has silent gaps — edge cases you thought you tested but skipped when you resumed.

Your session takes longer than it should. A test session that should take 45 minutes stretches to an hour because of the accumulated overhead. If you’re billing time or working against a sprint deadline, that overhead is visible.

What Changes With On-Device Terminal

When the terminal is on the same device as your test session, the verification step becomes:

1. Swipe to Test Nexus Terminal (your SSH connection is already open)
2. Run the query
3. See the result
4. Swipe back to the app

No laptop. No screen transition. No passphrase re-entry. No flow interruption. The backend check takes 15 seconds instead of 90, and — critically — your mental model of the test state is preserved because you never left the device.

SSH: Full Client, Saved Connections

Test Nexus Terminal is a complete SSH client, not a simplified wrapper that hides options behind menus. If you’ve used a desktop SSH client, the capabilities are familiar.

Authentication

• Password authentication — for quick connections to development servers where key management isn’t critical
• Key-based authentication — import your existing Ed25519, RSA, or ECDSA keys
• Passphrase-protected keys — your private key passphrase is entered once per session

Saved Connection Profiles

Create and save connection profiles for the servers you use regularly:

Profile: Staging DB
  Host: staging.yourcompany.com
  Port: 22
  User: qa
  Auth: Key (Ed25519)
  Key: staging_qa_ed25519

Profile: CI Server
  Host: ci.internal.yourcompany.com
  Port: 2222
  User: deploy
  Auth: Key (RSA)
  Key: deploy_rsa

Reconnecting to a saved server takes a single tap. You’re not retyping ssh -i ~/.ssh/staging_qa qa@staging.yourcompany.com -p 22 every time you need to check the database.

Shell Environment

Once connected, you have a full interactive shell. Anything you’d run on a desktop terminal works the same way:

• Run SQL queries directly: psql, mysql, sqlite3
• Read log files: tail -f /var/log/app/payment-service.log
• Check server state: systemctl status payment-service, docker ps, kubectl get pods
• Execute scripts: ./scripts/seed_test_data.sh, python3 check_queue.py
• Edit files in a pinch: nano, vim (yes, on your phone — for quick config edits, not a 500-line refactor)

SFTP: Browse and Transfer Files

Sometimes the verification isn’t a database query — it’s a file. Did the app upload the user’s profile image to the correct S3 path? Is the exported CSV on the server? Did the log rotation create today’s log file?

SFTP in Test Nexus lets you browse the remote file system visually, download files to your device, and upload files from your device to the server.

Common QA Use Cases

Download crash logs. Your staging server writes detailed crash logs to /var/log/app/crashes/. Instead of cat-ing them through SSH (which is painful for long files on a phone screen), download the file via SFTP and read it locally with a text viewer — or share it directly to Slack or email.

Verify file uploads. Your app’s file upload feature should write to /uploads/user_123/profile.jpg. Browse to that path in SFTP and confirm the file exists, check its size, and download it to verify the content is correct.

Upload test fixtures. Need to place a specific test file on the server before running a test? Upload it from your device via SFTP. A test CSV, a seed SQL file, a mock API response — push it to the server without touching your laptop.

Pull database exports. After running a test suite, export the test results from the server as CSV or JSON and download them to your device for review or forwarding to the team.

Port Forwarding: Access Internal Services

This is the feature that turns a phone into a genuinely capable remote operations tool. Port forwarding lets you access internal services — databases, admin panels, monitoring dashboards — that aren’t exposed to the public internet, by tunneling through your SSH connection.

Local Port Forwarding

Forward a port on your phone to a service behind the SSH server. The service becomes accessible on localhost on your phone as if you were on the same network as the server.

Example: Access the staging database directly.

Your staging PostgreSQL database is at db.internal.yourcompany.com:5432, accessible only from the staging network. With local port forwarding:

Local Port:   15432
Remote Host:  db.internal.yourcompany.com
Remote Port:  5432

Now localhost:15432 on your phone connects to the staging database through the SSH tunnel. Any database client app on your phone can connect to it.

Example: Access an internal admin panel.

Your staging admin dashboard runs at admin.internal.yourcompany.com:8080. Forward it:

Local Port:   18080
Remote Host:  admin.internal.yourcompany.com
Remote Port:  8080

Open http://localhost:18080 in your phone’s browser — you’re looking at the internal admin panel, from your phone, without a VPN.

Remote Port Forwarding

Expose a service running on your phone to the remote server. This is less common in QA workflows but useful for specific scenarios:

Example: Let a CI server hit your local mock API.

You’ve built a mock API server running on your phone (using a local HTTP server app) for integration testing. Remote port forwarding exposes it to the staging server:

Remote Port:  19090
Local Host:   localhost
Local Port:   9090

The staging server can now reach your phone’s mock API at localhost:19090. The staging app sends requests to the mock, and you see the responses in real-time on your device.

Real Workflow: Payment Verification in 15 Seconds

Let’s replay the opening scenario with Test Nexus Terminal:

Setup (one-time, before the test session starts):

• Open Test Nexus → Terminal → Tap saved “Staging DB” connection → Connected
• The SSH session stays alive in the background while you test

During the test:

You’re testing the Brazilian payment flow. You’ve set Mock Location to São Paulo, generated a DataHub profile with a valid CPF and Visa card, and used Autofill to inject the profile into the payment form. You tap Submit. The success screen appears.

Verification:

1. Swipe to Test Nexus Terminal (2 seconds)
2. Type: psql -d payments -c "SELECT id, status, amount, currency, card_last4 FROM transactions ORDER BY created_at DESC LIMIT 1;" (10 seconds — or use shell history: press up arrow if you ran this query earlier)
3. Read the result:

   id   | status    | amount  | currency | card_last4
--------+-----------+---------+----------+-----------
 tx_847 | completed | 1599.00 | BRL      | 4242

4. The transaction exists. Status confirmed. Amount in BRL matches the test. (3 seconds)
5. Swipe back to the app. Continue testing. (2 seconds)

Total time: 15 seconds. No laptop. No flow interruption. You verified the backend and you’re back in the app with your test context fully intact.

Bonus: Tail the Logs in Real-Time

For even faster feedback, open a second terminal tab and start tailing the payment service log before you begin testing:

tail -f /var/log/app/payment-service.log | grep "PAYMENT"

Now every payment attempt shows up in your terminal in real-time. You don’t even need to run a database query — you can watch the transaction hit the server as it happens, while the success screen is still loading on the app.

Running Server Scripts

If your test sessions involve repetitive server-side setup or teardown, write scripts on your server and run them from your SSH session:

Test Data Seeding

#!/bin/bash
# seed_brazil_test.sh — Sets up staging for Brazilian payment testing

echo "Seeding Brazilian test merchants..."
psql -d payments -c "INSERT INTO merchants (name, country, currency) 
  VALUES ('Loja Teste BR', 'BR', 'BRL') ON CONFLICT DO NOTHING;"

echo "Resetting transaction log for today..."
psql -d payments -c "DELETE FROM transactions 
  WHERE created_at > CURRENT_DATE AND merchant_country = 'BR';"

echo "Verifying PIX payment method is enabled..."
psql -d payments -c "SELECT name, enabled FROM payment_methods 
  WHERE country = 'BR';"

echo "Ready for Brazil testing."

Run it from Test Nexus Terminal: ./scripts/seed_brazil_test.sh

In 5 seconds, your staging environment is configured for the Brazil test session. No manual SQL. No copying queries from a notes app.

Post-Test Cleanup

#!/bin/bash
# cleanup_test_session.sh — Removes test artifacts from staging

echo "Removing test transactions..."
psql -d payments -c "DELETE FROM transactions 
  WHERE card_last4 = '4242' AND created_at > CURRENT_DATE;"

echo "Removing test user profiles..."
psql -d payments -c "DELETE FROM users 
  WHERE email LIKE '%@test.testnexus.com';"

echo "Test artifacts cleaned."

Run it at the end of your session. Staging is clean for the next tester.

When Terminal Replaces Your Laptop

Terminal doesn’t replace your laptop for everything. It replaces your laptop for the specific tasks that currently force you to break your mobile testing flow:

The pattern: anything that’s a quick verification, a short command, or a file transfer belongs on the device. Anything that requires sustained reading, writing, or editing belongs on the laptop. Terminal handles the former so you don’t need the latter for every backend check.

Security

Your SSH connections are secured by the same standards as any desktop SSH client:

• Key-based authentication — private keys are stored in Test Nexus’s AES-256 encrypted local database. Your private keys are encrypted at rest alongside all other Test Nexus data.
• Connection encryption — all SSH sessions use standard SSH protocol encryption negotiated with the server (AES-256-CTR, ChaCha20-Poly1305, or other ciphers depending on server configuration)
• No cloud storage of credentials — saved connection profiles, passwords, and private keys are stored exclusively on your device. Nothing is synced to any server.

Get Started

1. Open Test Nexus → Navigate to Terminal
2. Create a connection profile — enter your server hostname, port, username, and authentication method
3. Connect — tap the saved profile to open an SSH session
4. Leave it running — the SSH session stays alive in the background while you use other Test Nexus modules or the app you’re testing
5. Swipe back when needed — your session is right where you left it

🚀 Stop putting your phone down to pick up your laptop.
Test Nexus Terminal gives you SSH, SFTP, and port forwarding on the same device you’re already testing on.
Download Test Nexus →

What’s Next

• Post #07 — DataHub Deep Dive: country-specific data formats, batch generation, and export options