🎱 Scripted vs No code
Scripted testing and no code testing have their pros and cons, your context will determine which approach is the best fit for you!
Choose No-Code...
When the QA team cannot influence code
In some organizations, the QA team is very remote from the developers working on the mobile app. Sometimes the closest common manager is more than 3 degrees away. This makes collaboration extremely difficult between these teams.
In such a situation, Waldo’s no-code approach shines because the quality of the tree and the robustness of the similarity algorithm enable the QA team to record resilient test scenarios even when they lack clear and easy-to-use locators.
When you want the maintenance to be distributed and visual
A graphical interface in the cloud makes it easy for anyone to fix tests.
Choose scripted...
When the no-code approach is too limited
While Waldo’s no-code engine enables you to create complex scenarios, including API interaction with your backend, sometimes you need more. You may need to manipulate data or have very fine control over what you want to do. In these cases, nothing beats the power of code.
When you want your tests and your code in the same place
This organization helps a lot with heavy branching and significant refactoring.
When the app developers maintain the tests
Of course, when you want to script your tests, test creators and maintainers must know how to code. And when they have write-access to the app code, it makes test writing and maintenance easier.
For instance, adding an “accessibility identifier” to a UI element that you want to interact with in your test is an excellent solution to make your test rock solid!
Updated 5 months ago