Spend less time building tests, more time benefitting from them.
Waldo makes it possible for development teams to own, improve, and automate mobile testing without worrying about infrastructure maintenance.
Automate UI/UX testing for a majority of manual QA use cases, maintaining full coverage in a fraction of the time.
Set up automated regression testing suites that prevent bugs from ever merging, and even test every pull request without creating bottlenecks.
Create a fully automated test in minutes just by clicking through your user flow, and build out your testing suite over time.
Created by developers for developers
Waldo comes with all the critical features required to support automated testing at scale out of the box.
Take the pain, and wasted time, out of test creation and maintenance
Review and share what you are building in real time
Full video playback of your user flow with network requests
Stop worrying about different results from the same test
Decide when to run each test for efficient results
Share tests with your team through version control
Can’t find the answers you are looking for? Reach out to our team for more help.
How do you automate mobile app testing?
Let’s start by defining the term “automation” in the context of testing. Automation is not just mapping human behavior to code. Automation should be considered from an engineering perspective: looking at constraints and requirements for repeatable flows.
In order to automate your testing, you must first ensure your app is built to support this.
App features and capabilities must be specifically designed for repeatability. Changes in the UI need to be verifiably functional, testable, and predictable. The best way to do this is by designing methods for controlling the application and the user state. Developers can build their apps with additional configuration layers (e.g. a “super admin panel”) accessible via a “test mode.”Building configuration layers allows the state of an app to be deterministic and controllable. They also enable an app to be automatable.
However, it’s not just the app that needs automatability: the back end also needs to support automation. Since back-ends are custom-built for apps, it takes careful design and intention to ensure the back end honors requirements for successful testing via the app’s front end.
What are the types of mobile testing?
There are three key categories, or layers, that together make up the Mobile Testing Pyramid:
1. Unit Tests
2. Integration Tests
3. End to End (E2E) Tests
Unit Tests allow you to test small, specific, exception cases.
Integration Tests allow you to increase the complexity of your text by sending real payloads to real API endpoints to ensure all your systems are working together as desired/expected.
End to End (E2E) Testing allows you to test the application as the end user would experience it, ensuring that user interaction produces the desired/expected flow through your application’s most popular functions on real devices.
What is the purpose of mobile testing?
The end goal of mobile test automation is to produce higher quality builds that result in superior mobile applications. It is not about taking manual testing behavior and turning that into a script. To make this a reality, your tests need to be three things:
1. Deterministic: performing an action on the state of a user should always yield the same resulting state.
2. Isolated: no matter what else is being tested, the test must still provide the expected resulting state.
3. Repeatable: no matter how many times you execute a test and no matter what else is being tested, the test must still provide the expected resulting state every single time it’s executed.
User state management is critical to manifesting these three key requirements for successful mobile test automation.
What are the different strategies for mobile testing?
For mobile testing, there are several different methodologies or approaches a team could take. Waldo’s recommended principles when developing a testing strategy are this:
1. Tests should be simple
2. Tests should be nimble
3. Tests should be respected
Tests should be simple: Do not try to test everything, and do not try to automate everything. The number one barrier to a successful, scalable, and deterministic testing automation strategy is noisy, complex, polluted tests. Know what you are testing for, and know what answer you are trying to find. This will help limit flakiness, test runtimes, and general instability.
Tests should be nimble: Your tests should continue to function as your application evolves and changes. This means you need to anticipate and account for changes in your application that are a bi-product of use, and build tests that allow for this use to occur. Your testing approach needs to be nimble enough to account for these adjustments.
Tests should be respected: Testing is a way to know what your end user experience with your application will be. If you build tests that allow you to observe and protect the end user’s access to critical functionality within your application, you can preserve the core elements of the user experience with every release.