Skip to main content

TesterNest Getting Started

Use this guide as the product SOP for the current TesterNest flow. It explains how a new user moves from sign-in to application setup, SDK connection, tester operations, engagement review, release assessment, and sign-out.

What This Guide Covers​

  1. Sign in with the current authentication flow.
  2. Open the workspace and understand what it is for.
  3. Register an application using the current product flow.
  4. Move through Overview, SDK Setup, Testers, Engagement, Beta Assessment, Settings, and Support in the right order.
  5. Sign out cleanly when you are done.

Current Product Flow At A Glance​

  1. Open https://testernest.com/signin.
  2. Click Continue with GitHub.
  3. Land on the auth success page and click Go to Dashboard.
  4. Open Workspace.
  5. Create or open an application.
  6. Start on Overview.
  7. Open SDK Setup and connect the SDK.
  8. Add a build update and generate an invite.
  9. Use Testers to manage the cohort.
  10. Use Engagement to read behavior and usage trends.
  11. Use Beta Assessment for release-readiness review.
  12. Use Settings or Support only when needed.
  13. Sign out from the user menu or auth success page.

1. Sign In​

The current live sign-in flow is GitHub-based.

  1. Go to https://testernest.com/signin.
  2. Click Continue with GitHub.
  3. Complete GitHub authentication.
  4. After login, TesterNest opens the auth success page.

What you should see next:

  • A Login successful state.
  • Your GitHub avatar and account details.
  • A Go to Dashboard button.
  • A Logout button.

2. Understand The Auth Success Page​

The auth success page is a short handoff screen between login and product use.

  • Click Go to Dashboard to open Workspace.
  • Click Logout if you authenticated with the wrong account.

If your session is not active, the page shows You are not signed in and sends you back to Sign in.

3. Understand The Workspace​

Workspace is your application hub, not the operational dashboard.

Use it to:

  • See all applications you already created.
  • Search by app name or identifier.
  • Open an existing application.
  • Register a new application.

When you click Open on an app tile, TesterNest routes you into that app dashboard, usually at Overview.

4. Register A New Application​

From Workspace, click Register new application.

The current product flow is Android-first in Workspace.

Required Fields​

  • Project name
  • Platform
  • Package ID for Android
  • Framework for Android
  • Timezone
  • Consent

Android Options Available Today​

  • Framework
    • Native Android (Kotlin/Java)
    • Flutter
    • React Native
  • How do you want to run your test?
    • Open testing
    • Publishing campaign
  • How will testers join? for publishing campaigns
    • Tester email list
    • Google Groups

Important Notes​

  • Use the exact Android package ID from your build.
  • Timezone matters because day-based reporting and analytics use it.
  • Google Group, Play opt-in, and Play Store links can be added later from Overview under Build update.

After successful creation, the app appears in Workspace and can be opened into the dashboard.

5. Start With Overview​

Overview is the best first page after app creation because it tells you whether setup is complete and whether the app is already sending signals.

Use Overview to check:

  • App details
    • app name
    • platform
    • package ID or identifier
    • public key and other app metadata
  • Setup checklist
    • configure SDK
    • create and share an invite
    • receive first events
  • Build update
    • build URL
    • build version
    • notes
    • Google Groups onboarding links when applicable
  • Invite testers
    • invite link
    • shareable invite message
  • Latest activity / web events for web flows
  • Beta campaign status for campaign-based Android testing

Recommended operating rule:

Do not move on too quickly if Overview is still empty. Usually the missing step is one of these:

  • SDK not connected yet
  • no build update added
  • no invite generated
  • no tester has opened the app
  • no event has reached TesterNest yet

6. Open SDK Setup​

Once the app exists, go to SDK Setup from the left navigation.

This page gives you the values needed to connect your app:

  • Public Key
  • Base URL
  • A docs link that points to the matching setup guide

Use SDK Setup to:

  1. Copy the public key.
  2. Copy the base URL.
  3. Open the matching SDK doc.
  4. Add the SDK to your app.
  5. Initialize it before rollout.

Continue with the stack-specific guide after this:

7. Add A Build Update Before Inviting Testers​

Back on Overview, use Build update to keep the cohort aligned with the correct build.

Add:

  • the latest build URL
  • build version
  • release notes
  • Google Group / Play testing links if you use the Google Groups flow

This matters because invite links are tied to the current onboarding flow and build context.

8. Generate Invites And Start The Cohort​

Use the Invite testers section on Overview.

You can:

  • generate an invite link
  • copy the invite link
  • copy the invite message

If invite creation is blocked, TesterNest tells you to add a build update first.

How To Think About Invites​

  • Use invites only after SDK setup is complete.
  • Use invites only after the latest build details are added.
  • For Google Groups campaigns, make sure onboarding links are present.

Success looks like this:

  • testers receive the invite
  • they install or open the app
  • they begin producing activity signals
  • the cohort starts appearing in TesterNest

9. Use The Testers Page​

The Testers page is where you operate the cohort.

Use it to:

  • search testers
  • review tester quota
  • review Events (24h)
  • review Device coverage
  • filter by last seen window
  • filter by live or recent activity
  • jump to At Risk testers
  • export tester event data
  • generate a snapshot
  • manage or delete testers

Important concepts on this page:

  • Connected means the tester is sending usable signals.
  • Joined (waiting to connect) means the tester joined but activity is still limited or pending.
  • Live / Recent / Stale helps you judge momentum quickly.
  • At Risk highlights testers inactive beyond the threshold window.

Use this page to answer:

  • Who is active right now?
  • Who has stopped testing?
  • Which devices are covered?
  • Who is still on an older build?

10. Use The Engagement Page​

The Engagement page shows whether testers are actually using the app over time.

It includes:

  • active tester trend
  • event trend
  • top pages
  • range filters
    • 24h
    • 7d
    • 14d
    • 30d
    • custom range

Use Engagement to answer:

  • Did the latest build increase usage?
  • Are testers returning after the first session?
  • Which pages or screens are getting exercised most?
  • Is activity growing, flat, or dropping?

This is the page you should check after invites go out and after every new build.

11. Use Beta Assessment For Release Decisions​

The Beta Assessment page is the release decision cockpit.

It combines:

  • readiness score
  • decision summary
  • onboarding funnel signals
  • first-time experience signals
  • problem screens
  • release blockers
  • confidence bands
  • release call
  • readiness timeline

Use Beta Assessment after there is enough real tester activity. If the app is brand new and nobody has tested yet, the page is too early to guide a real release decision.

Best use:

  1. Review Engagement first.
  2. Confirm the cohort is active enough.
  3. Open Beta Assessment.
  4. Read the recommendation and blockers.
  5. Decide whether to continue beta, fix issues, or widen rollout.

12. Use Settings Carefully​

Use Settings for app-wide operational controls.

Current settings functions include:

  • changing the reporting timezone
  • deleting the project from the danger zone

Important:

  • timezone changes affect daily analytics boundaries
  • deleting a project removes testers, invites, events, devices, and feedback

Use Settings only when you intentionally need a configuration change.

13. Use Support When The Product State Does Not Match Reality​

Use Support if setup or analytics do not match what you expect.

Current support guidance asks you to include:

  • app name or dashboard URL
  • what you expected to happen
  • screenshots or error text

Support contact:

Use Support for issues like:

  • login or access trouble
  • billing issues
  • tester activity not updating
  • setup or onboarding confusion

14. Sign Out​

There are two current sign-out paths:

  1. From the auth success page, click Logout.
  2. From the in-app user menu, click Logout.

Logout clears the current session and returns you to the public experience.

  1. Sign in with GitHub.
  2. Open Workspace.
  3. Register the application with the correct package ID and framework.
  4. Open Overview and confirm the app record looks correct.
  5. Open SDK Setup and copy the public key and base URL.
  6. Complete the matching SDK integration.
  7. Return to Overview and add the latest build update.
  8. Generate the invite link and share it with testers.
  9. Watch Overview until first activity appears.
  10. Use Testers to monitor who joined, who is active, and who is at risk.
  11. Use Engagement to understand usage quality over time.
  12. Use Beta Assessment when you need a release-readiness decision.

Common Mistakes To Avoid​

  • entering the wrong Android package ID
  • skipping SDK verification and inviting testers too early
  • forgetting to add the latest build update before generating invites
  • reading only total activity and ignoring at-risk testers
  • using Beta Assessment before enough real activity exists
  • deleting a project from Settings without confirming the impact