> ## Documentation Index > Fetch the complete documentation index at: https://docs.qa.tech/llms.txt > Use this file to discover all available pages before exploring further. # POC Setup Checklist > Prepare your web application before a Proof of Concept with QA.tech Before QA.tech can run meaningful tests during a Proof of Concept (POC), your testing environment needs to be reachable, populated with safe data, and configured for automated access. Use this checklist before kickoff. Most delays come from network access, authentication, or email delivery. Native iOS and Android POCs have separate requirements: simulator or APK builds, mobile IP ranges, and backend allowlisting. See the [Mobile POC Setup Checklist](/getting-started/poc-mobile-setup-checklist). ## Quick checklist Work through these in order. Network access usually takes the longest when IT is involved. | Area | What to verify | Effort if not ready | Details | | - | - | - | - | | Network access | QA.tech can reach staging (IP allowlist, SSH tunnel, or CLI tunnel) | 1-5 days (IT) | [Network access](#network-access) | | Authentication | Dedicated test accounts exist and log in on staging | Hours | [Authentication](#authentication) | | Email delivery | `@qatech.email` is allowed and a test email arrives | Hours (IT) | [Email delivery](#email-delivery) | | Environment | Staging or QA URL is shared; not production | Hours | [Environment](#environment) | | Test data | Data is scrubbed, non-sensitive, and seeded for the journeys you will demo | Hours-days | [Test data](#test-data) | | Bot and WAF | CAPTCHA, rate limits, and deployment protection do not block test traffic | Hours (IT) | [Bot and WAF protection](#bot-and-waf-protection) | | QA.tech project | Applications, environments, and configs are set up | Minutes-hours | [QA.tech project](#qa-tech-project) | ### Who verifies what | Your team verifies | QA.tech verifies during setup | | - | - | | Staging URL loads and IT has applied IP allowlisting | Environment reachable from QA.tech | | Test accounts log in on staging | Login test passes | | `@qatech.email` is allowed and a test email arrives | Inbox receives mail from staging | | Test data is scrubbed and accounts are seeded | Crawl and initial smoke tests run | | WAF and CAPTCHA bypasses are in place if needed | Tests complete without bot blocks | *** ## Environment QA.tech needs a URL it can visit repeatedly without affecting production users. For a POC, use a staging, QA, or preview environment, not production. Pick an environment that mirrors the flows you want to evaluate. Staging or QA is the usual choice because it is stable, has test data, and carries lower risk than production. See [Projects](/core-concepts/projects) and [Applications and Environments](/core-concepts/applications-and-environments) for how QA.tech organizes URLs. If the POC spans a customer app and an admin panel (or a third-party OAuth or payment page), create a separate application for each domain. See [Multi-App Flows](/core-concepts/applications-and-environments#multi-app-flows). If the POC includes API-first journeys, add an [API application](/core-concepts/api-testing) in addition to the web app. Confirm the URL loads in a browser. If it is behind a VPN, firewall, or private network, complete [Network access](#network-access) before running tests. *** ## Test data QA.tech's AI agent reads page content, forms, and emails during test runs. The environment must contain data that is safe to expose to an automated testing system. * **No production PII.** Do not point QA.tech at databases or environments containing real customer names, emails, phone numbers, addresses, payment details, or government IDs. * **No GDPR-sensitive data.** Remove or anonymize personal data subject to GDPR or similar regulations. Scrubbed copies of production data are acceptable only after a documented anonymization process. * **Dedicated test accounts.** Create accounts used exclusively for QA.tech. Never store real user credentials in Configs. * **Repeatable state.** Tests should be able to run more than once without manual cleanup. | Strategy | Best for | Trade-offs | | - | - | - | | Scrubbed production copy | Realistic data, migration testing | Requires an anonymization pipeline | | Static staging database | Persistent POC setup | Data can drift over time | | Seed scripts with reset | Isolated, repeatable runs | Seed data may be less realistic | Config credentials are stored unencrypted and are passed to AI models during test execution. Use test-only accounts with limited permissions. See [Configs](/core-concepts/configs). ### What to seed before the POC Prepare data and accounts for the user journeys you plan to demonstrate: * Login accounts for each role you want to test (admin, standard user, and similar) * Sample records the tests will create, edit, or delete (orders, projects, users) * Feature flags or plan tiers needed to reach the flows under evaluation * Third-party integration stubs or sandbox modes (payments, SMS, identity providers) * Files for upload flows, using a [File Upload config](/core-concepts/configs) if the demo includes attachments Document data conventions in [Knowledge](/core-concepts/knowledge) so the agent generates appropriate values (for example, "always use Swedish addresses in staging"). *** ## Network access If QA.tech cannot reach your staging URL, nothing else in this checklist matters. Start here, especially if the app is behind a VPN, firewall, or IP allowlist. QA.tech test traffic originates from a fixed pool of outbound IP addresses. Your environment must allow connections from these IPs, or you must route traffic through an SSH tunnel or CLI tunnel. ### Public environments If the staging URL is on the public internet: Copy the addresses from [**Settings → Network**](https://app.qa.tech/current-project/settings/network) or the [Get Outbound IPs API](/api-reference/infrastructure/get-outbound-ips). Add those addresses to your CDN, WAF, firewall, or IP allowlist. Allow 5-10 minutes for CDN changes to propagate, then run a login test to confirm access. IP addresses can change. Always use the live list from Settings or the API. Do not rely on a static copy. **Forward to IT:** [Email a pre-filled request to your IT team](mailto:?subject=Whitelist%20QA.tech%20IPs%20for%20staging\&body=Hi%2C%0A%0AWe%20need%20to%20whitelist%20QA.tech%27s%20outbound%20IP%20addresses%20so%20their%20automated%20testing%20can%20access%20our%20staging%20environment%20during%20our%20POC.%0A%0ACopy%20the%20current%20IP%20list%20from%3A%0Ahttps%3A%2F%2Fapp.qa.tech%2Fcurrent-project%2Fsettings%2Fnetwork%0A%0AOr%20via%20API%3A%20https%3A%2F%2Fapi.qa.tech%2Fv1%2Foutbound-ips%0A%0AAdd%20those%20addresses%20to%20our%20CDN%2FWAF%2Ffirewall%20allowlist.%0A%0AQA.tech%20traffic%20identifies%20as%20QATechBot%20in%20the%20User-Agent.%0ADocs%3A%20https%3A%2F%2Fdocs.qa.tech%2Fconfiguration%2Fip-access-control%0A%0AThanks) Or send the request to your contact at QA.tech, who can help coordinate with IT. Platform-specific instructions: [IP Access](/configuration/ip-access-control) (Cloudflare, AWS WAF, and others). Mobile test traffic uses a separate IP range. Find it under **Mobile Testing IP Whitelist** in [Settings → Network](https://app.qa.tech/current-project/settings/network). See [Mobile App Testing](/test-features/mobile-app-testing#network-access). ### Private or VPN-protected environments If the environment is not publicly reachable, choose one of these: * Set up an [SSH Tunnel Proxy](/configuration/ssh-tunnel) through a bastion or jump server. Allowlist QA.tech IPs on the bastion's SSH port, and confirm the jump server can reach the application over HTTP or HTTPS. * For a local or developer machine, expose the app with [`qatech tunnel`](/cli/commands/tunnel) and point the run at the tunnel URL. ### Your team verifies * The 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 ### QA.tech verifies during setup * The environment is reachable from QA.tech * A navigation or login test completes without 403, timeout, or CAPTCHA errors *** ## Email delivery Many authentication and onboarding flows depend on email: account verification, password reset, OTP codes, and magic links. QA.tech provides built-in inboxes on the `@qatech.email` domain. Your application must be able to send mail to these addresses. Email inbox config ### Allow `@qatech.email` Allow the entire `@qatech.email` domain in: * Signup and registration restrictions, so test accounts can be created * Email server and gateway filters, so inbound mail reaches QA.tech inboxes * Spam and security tools, so outbound mail from your app is not blocked or quarantined Addresses you may see during testing include: * Project emails (`prj-xxxxx@qatech.email`) * Magic link addresses (`magic-login-xxxxx@qatech.email`) * Single-use addresses generated per test run (`test-automation-abc123@qatech.email`) For a stable address you can pre-approve, use a **Fixed / Project** email config. See [Email Inbox](/test-features/email-inbox). External inboxes are not supported. The agent cannot read Gmail, Outlook, or other personal email accounts. Email-based test flows must use QA.tech-managed addresses. **Forward to IT:** [Email a pre-filled request to your IT team](mailto:?subject=Allow%20%40qatech.email%20for%20QA.tech%20testing\&body=Hi%2C%0A%0AWe%20need%20to%20allow%20the%20%40qatech.email%20domain%20for%20our%20QA.tech%20POC.%0A%0APlease%20allow%20%40qatech.email%20in%3A%0A-%20Signup%20and%20registration%20restrictions%0A-%20Email%20server%20and%20gateway%20filters%0A-%20Spam%20and%20security%20tools%0A%0ADocs%3A%20https%3A%2F%2Fdocs.qa.tech%2Ftest-features%2Femail-inbox%23whitelisting-email-addresses%0A%0AThanks) ### Confirm email flows work Before kickoff: Use a QA.tech email address, or ask QA.tech for the project address. Send a verification or magic-link email from your application. Open [**Settings → Inbox**](https://app.qa.tech/current-project/settings/inbox) and confirm the message arrives within a few minutes. The agent waits up to **3 minutes** for emails during a test run. If delivery is slower, investigate your mail pipeline before relying on email-based tests. *** ## Authentication Set up authentication so the AI agent can log in without manual intervention. Configs in project settings Provision accounts in staging for each user role you plan to test. Use credentials that exist only in non-production environments. Log in manually with each test account before kickoff. Fix account, SSO, or rate-limit issues on your side first. Go to [**Settings → Configs**](https://app.qa.tech/current-project/settings/configs) and create a config for each account. The agent uses these when it encounters login forms. You can also send credentials to your QA.tech contact to add them during project setup. If you test more than one environment, add [config environment overrides](/core-concepts/config-environment-overrides) so each URL gets the matching credentials. ### Auth methods that need extra setup | Method | Setup | | - | - | | OTP via email | Email config plus `@qatech.email` allowlisting | | Magic link | Pre-register a user with the project's magic-link address | | 2FA (TOTP) | 2FA config with the `otpauth://` URI from the QR code. See [2FA setup](/best-practices/handle-auth#two-factor-authentication-2fa) | | API-based auth | [API Call Configuration](/test-features/api-calls) to fetch tokens before UI tests | | HTTP Basic Auth | [Environment basic auth](/core-concepts/applications-and-environments#basic-auth) scoped to your staging or preview domains, or **Use for Basic Auth** on a Username + Password config | | Method | POC consideration | | - | - | | CAPTCHA | Not supported directly. Allowlist QA.tech IPs on staging to bypass. See [IP Access](/configuration/ip-access-control). | | BankID / national ID | Stub in the test environment, or use manual auth via live stream. See [SE BankID](/applications/se-bank-id). | | SSO / SAML | May need a dedicated test IdP, bypass route, or seeded SSO session. Coordinate with your identity team. | | OAuth (Google, Microsoft) | Use sandbox or test OAuth apps, or stub the provider in staging. Create a separate application for the provider domain if the agent must interact with that UI. | ### Rate limits Parallel test runs can trigger authentication rate limits and log users out mid-test. Before running several tests at once: * Review provider rate limits (Supabase, Auth0, Firebase, custom auth) * Increase limits on staging, or disable aggressive throttling for QA.tech IPs * See [Authentication Rate Limits](/configuration/auth-rate-limits) for Supabase-specific guidance Only relax rate limits on non-production environments. Production rate-limit changes reduce protection against abuse. *** ## Bot and WAF protection If staging sits behind deployment protection or bot detection, configure bypasses before the POC. | Protection | What to configure | | - | - | | Cloudflare WAF / Turnstile | [Cloudflare WAF & Turnstile](/configuration/cloudflare-waf-turnstile) | | Vercel deployment protection | [Vercel Preview](/configuration/vercel-preview-protection): enable Protection Bypass for Automation | | Vercel Firewall | [Vercel Firewall](/configuration/vercel-firewall): allow QATechBot traffic | | Basic auth on staging | [Environment basic auth](/core-concepts/applications-and-environments#basic-auth), or [Configs](/core-concepts/configs): enable **Use for Basic Auth** | Vercel Firewall rule for QATechBot QA.tech identifies itself as **QATechBot** in the User-Agent. See [QA.tech Bot](/bot) for verification details. *** ## QA.tech project In the dashboard, create the applications and environments you will test: Go to [**Settings → Applications & Envs**](https://app.qa.tech/current-project/settings/applications). Create an application for each distinct app (for example, customer frontend vs admin panel) and add the environment URL. Assign login, email, and API configs to the tests you will run. See [Configs](/core-concepts/configs). If the POC includes responsive or mobile-web layouts, create [device presets](/test-features/device-presets) before the kickoff session. *** ## Additional preparation These items are commonly overlooked and often block POC progress. ### Crawling and test creation QA.tech builds a knowledge graph by crawling your application. Before creating tests: * Confirm the features you want to test already exist. The agent cannot test features that have not been built yet. See [Creating Tests](/best-practices/creating-tests). * Run an initial login test, then ask the [AI Chat Assistant](/core-concepts/ai-chat-assistant) to crawl after login (for example `/crawl` or "Crawl the admin panel"). Past sessions are listed under [**Settings → Crawling**](https://app.qa.tech/current-project/settings/crawling). * Add product context under [**Settings → Knowledge**](https://app.qa.tech/current-project/settings/knowledge): terminology, navigation paths, and data conventions. ### Site accessibility The agent uses DOM structure and visual models to interact with your site. Reliability improves when you: * Use semantic HTML (`