Skip to main content
Before a Proof of Concept (POC) kickoff, verify the items below are in place. QA.tech runs the same checks during project setup and will flag anything still blocking before you start creating tests.

Testing a mobile app?

Native iOS and Android POCs have separate requirements — APK/simulator builds, mobile IP ranges, and backend allowlisting. See the Mobile POC Setup Checklist.

​
Before kickoff — verify these are ready

​
What to verify, and effort if not ready

Work through these in order. Network access usually takes the longest when IT is involved.

​
1. Network access

Biggest blocker. If QA.tech cannot reach your staging URL, nothing else matters. Start here — especially if your app is behind a VPN, firewall, or IP allowlist.
QA.tech browser tests exit through a fixed pool of outbound IPs. Your CDN, WAF, or firewall must allow traffic from these addresses.

​
Web testing IPs

Get the current list from Settings → Network or the Get Outbound IPs API. Copy the addresses into your CDN, WAF, firewall, or IP allowlist.
IP addresses can change. Always use the live list from Settings or the API — never rely on a static copy.
Forward to IT: Email pre-filled request to your IT team Or send the request to your contact person at QA.tech, who can help coordinate with your IT team.

​
Private or VPN-protected environments

If staging is not on the public internet, set up an SSH Tunnel Proxy through a bastion host and whitelist QA.tech IPs on the bastion’s SSH port.

​
Your team verifies

  • Staging URL loads in a browser from outside your office network (or via the jump server)
  • IT has applied the IP allowlist and changes have propagated (allow 5–10 minutes for CDNs)

​
QA.tech verifies during setup

  • Environment is reachable from QA.tech infrastructure
  • A simple navigation or login test completes without 403, timeout, or CAPTCHA errors
Platform-specific guides: IP Access · SSH Tunnel · Cloudflare

​
2. Authentication

Dedicated test accounts let the AI agent log in without manual steps. Create them in staging, then share credentials with QA.tech for Configs. Configs in project settings
1

Create test accounts in staging

One account per role you want to demonstrate (admin, standard user, etc.). Use credentials that exist only in non-production environments.
2

Verify login on your staging environment

Log in manually with each test account before the kickoff. Fix any account, SSO, or rate-limit issues on your side first.
3

Share credentials with QA.tech

QA.tech adds them to Settings → Configs during project setup. Or send them to your contact person at QA.tech, who will add them for you. See Authentication for 2FA, OTP, and magic-link configs.
Config credentials are not encrypted and are passed to AI models during tests. Never use production credentials.

​
3. Email delivery

Flows like signup verification, password reset, OTP, and magic links depend on your app delivering email to QA.tech inboxes (@qatech.email). Email inbox config

​
Allow @qatech.email

Your IT team needs to allow the entire @qatech.email domain in signup restrictions, email gateways, and spam filters. Forward to IT: Email pre-filled request to your IT team Or send the request to your contact person at QA.tech, who can help coordinate with your IT team.

​
Your team verifies

  1. Create a test account using a @qatech.email address (or ask QA.tech for the project address)
  2. Trigger a verification or magic-link email from your app
  3. Confirm the email arrives within a few minutes

​
QA.tech verifies during setup

  • Email inbox receives mail from your staging environment
  • An email-based login or verification test completes end-to-end
The agent waits up to 3 minutes for emails during a test run. See Email Inbox.

​
4. Environment & test data

​
Environment

Provide a staging or QA URL — not production. QA.tech adds it under Settings → Applications & Envs. See Applications and Environments. If your POC spans multiple apps (customer frontend + admin panel), share each URL separately.

​
Test data

The environment must contain scrubbed, non-sensitive data:
  • No real customer PII (names, emails, addresses, payment details)
  • No GDPR-regulated personal data unless anonymized through a documented process
  • Repeatable state — accounts and sample records for the journeys you want to demo
Seed login accounts, sample records, feature flags, and sandbox modes for third-party integrations (payments, SMS) before kickoff.

​
5. WAF & bot protection

If staging sits behind deployment protection or bot detection, configure bypasses before the POC. Vercel Firewall rule for QATechBot For HTTP Basic Auth popups on staging, enable Use for Basic Auth on a Username + Password Config.

​
Getting help

Contact QA.tech Support or your QA.tech contact with your staging URL, how it is protected, which auth methods you use, and any error messages from failed tests.