Post-upload requirements
After you upload a build, tell Pie how to sign in, what to focus on, what to avoid and which files your app needs. Update these when your test accounts or environments change.
Before you start
- Upload a build first. See Prepare mobile builds.
- Create a dedicated test account for each user role you want tested. Never use a production account or an account with access to real user data.
- Write a short list of the flows that matter most in your app.
Add test credentials
In Settings, open Credentials Manager and add a credential for each role. Give each one a name that says its role, a test login and its password. See Credentials for every field.
Two-factor authentication can stay on for the test account: store a fixed test code in the credential’s Password / OTP / magic link field.
Login steps go in App Instructions, in the next step. Describe any non-standard login there, such as social login test accounts, single sign-on, magic links or email verification.
Pie can’t receive a code sent by SMS. For a test account that asks for phone verification, store a fixed test code or turn the verification off.
Write your testing boundaries
In Settings, open App Instructions, write your guidance, and select Save Instructions. If a suite has its own instructions, they replace App Instructions for that suite.
Cover three things:
- Features to focus on. Key user journeys, recently updated features, and complex workflows. For example: “Focus on checkout, user profile creation, search, and push notification settings.”
- Areas to avoid. Work-in-progress features, known broken functionality, admin-only sections, and actions that trigger alerts. For example: “Avoid the admin panel, payment processing with real cards, and social sharing.”
- Critical user journeys. End-to-end workflows that must work. For example: “New user signs up, completes a profile, browses products, adds an item to the cart, and completes an order.”
Send custom test files
Skip this step if your app needs no files. Otherwise, list the files it needs, such as documents, images, media, data files or sample datasets. Send the list to support@pie.inc with how each file should be used.
Add optional context
More context helps Pie test your app. Add any of these to App Instructions:
- Expected behavior: How critical features should work. For example, a badge with the item count appears on the cart icon.
- Known issues: Bugs or limits that don’t need reporting.
- Specific scenarios: Situations to try, such as an empty cart at checkout, a very large image upload, or a lost network connection during a form submission.
- Edge cases: Unusual inputs, such as very long usernames or many items in favorites.
To keep it organized, start from this template:
TESTING FOCUS:
- Key features: [list critical features]
- Avoid: [list areas to skip]
- Critical journeys: [describe main workflows]
OPTIONAL CONTEXT:
- Expected behavior: [key behaviors]
- Known issues: [documented bugs]
- Test scenarios: [specific scenarios]What you’ll see
Your credentials are in Credentials Manager and your guidance is in App Instructions. Edit either one in place when something changes.
Best practices
Security
- Use dedicated test accounts created for automated testing.
- Make sure test accounts have no access to production data or real user information.
- Use test environment credentials only.
- Never put passwords, production API keys or secrets in App Instructions. Store logins in Credentials Manager.
Clarity
- Be specific: “Test the checkout flow” is better than “test payments”.
- Use examples: Show what you mean rather than only describing it.
- List steps: Break complex workflows into numbered steps.
- Highlight priorities: Say what is most important to test.
Account management and environment details
Create test accounts that have the permissions the tested features need, won’t trigger rate limits or security alerts, and hold realistic test data. If your app has different user types, store one credential per role and name each for its role.
Tell Pie about your test environment in App Instructions: its address, when it resets, what’s in test mode, and how long test data lasts. For example: “Database resets nightly. Payment processing uses test mode. Email notifications are disabled.” Also note account expiration dates, password rotation, and maintenance windows that affect test accounts.
To seed or reset data during a run, use scripts.