Before you read this article, you should have uploaded your app to Waldo, so you have something to test! If you have not done this, please see our article “Uploading you app” for a step by step guide.
When it comes to creating your first test, there are a few core steps:
- Make sure your build works in Waldo using Waldo Live
- Know what kind of test you want to build first as your “Foundational Test”
- Finalize and validate your test
- What kind of test should I build first?
- Creating your first test in Waldo
- Finalizing and validating your test
Try it out first
Waldo Live allows you to test the functionality of your build in real time on simulated devices.
If you are able to interact with your app on Waldo Live, you know that your build is stable. You can proceed to building tests with confidence!
If not, please contact Waldo support.
There are several tests that can serve as solid foundational tests for your suite in Waldo. Your foundation test determines the entry point into your app, and the user state. The two we are going to walk through as good candidates for foundational tests are:
- Sign Up
- Sign In
Starting with Sign Up
If possible, we recommend starting with a Sign Up flow: something that you can use to test initial entry into the app, basic navigation, etc. This will also ensure that you do not run into repeatability issues with this same test in future runs.
Overview: a fresh new user with every run
- Fresh app state every time you launch a run
- Create read & write tests
- Unlocks concurrency faster to save you time
Requirements for a successful Sign Up test
- Generate a different user every single time
- This can be done using Waldo’s variable generator
- Deactivate random marketing modals in signup flow
- Automate SMS/email verification to be automatically validated by your backend with recognizable input (i.e., automatically verify any accounts ending with @testing.waldo.io)
The verification process can’t be re-created in a repeatable way within Waldo. This method will potentially require you to add some logic in your backend or app to bypass SMS/Email verification as part of your Sign Up Flow.
If you’re not ready to implement the necessary logic, you can pick another method that suits your current situation and needs better.
For more guidance on selecting your first test, click here.
Overview: quick time-to-value
- One concurrency only, resulting in slower run times
- Doesn’t require any backend or app work
- Specific users can be created in your backend to test different user state in Waldo
Requirements for a successful Sign In test
- Deactivate random marketing modals in sign in flow
When creating your first tests, remember that your user has to begin each test in the same fresh state.
For example: your have a test requires a user to add their first profile photo to their account.
This test may work the first time as the account does not have a profile picture yet.
However, during subsequent tests (especially if you are using the same user credentials) the account will register as already having a profile picture and Waldo will not be able to complete the same action.
To manage user state effectively, you would need to delete the photo from that user account after each test run.
For more on managing user state...
Check out our article on user state management for more information, examples, and tips.
- Navigate to your Testing page using the sidebar menu
- When you land on your Testing page, click in the upper right hand corner on “Create a Test”
- Name your test and provide a brief description so you can easily identify it as your suite grows.
Select the build you would like to use for the test
a. If you have only uploaded a single build at this point, it will auto-populate
Your app will then be loaded into the Waldo Recorder
a. From here, you can begin to interact with your application on a virtual device, the same way you would manually
b. More details on the Recorder can be found here.
- This will provide you with a step by step walkthrough of available functions and buttons. If you prefer to reference that documentation directly, scroll down.
c. More details on interactions can be found here.
You probably already have a good idea of what option suits you best right now. As you can see, there are multiple ways in which you can create your foundational test. You can use the below decision map according to your situation.
If you have a sign-up flow in your app AND
Your sign-up flow requires verification steps (2FA, email or SMS confirmation, etc.) to navigate the home screen, then:
- You have the bandwidth to bypass these > implement changes and use Sign Up
- You don’t have the bandwidth to bypass these > use your login instead, until you implement scalable USM
If you have a sign-up flow in your app AND
Your sign-up flow doesn't require verification steps to navigate the home screen:
- You can use Sign Up right away without additional work
If you DON'T have a sign-up flow, but have a SIGN IN flow in your app...
- If your backend allows the same user to connect on different devices at the same time, you could be able to unlock concurrency.
- If your backend doesn't allow the same user to connect on different devices simultaneously, you won't be able to run tests concurrently.
**Do you currently have the bandwidth to implement a scalable USM tool in your backend?
👉 In our experience, this works usually takes ~1-3 hours of development time
- After you have finished using Waldo Recorder to create your test, you will be taken to the screen pictured below, and prompted to validate your test.
- When you click validate, you will be taken into Waldo Live, where your test will be played back in real time on your screen
- The benefit of validation is that it exposes flakiness in your test early on.
- This validation function replays your test a minimum of three times on each device configuration.
- Each test must pass validation before becoming part of your test suite.
- Similarly, your test must pass validation to be usable as a dependency for another test.
- 🎉Congratulations! 🦙 You have completed your first test build in Waldo!
Chaining tests and testing dependencies
Updated 4 months ago