@Gummibeer Great questions. Here are your answers:
- There is no technical limitation to sharing state between test runs, but right now we start with a fresh state on every run. We wrote the back-end execution code specifically with 'composition' in mind, which is when you specify a list of tests to execute in a specific order. For this, we'll concatenate the tests and run them together. This is how you would get around needing to login as the first step to every test. You would create 1 "Login Test" and then compose that with another test afterward. We don't support full composition yet, but it's on the near-term horizon.
We encrypt input values at rest in the DB and in transit. We obviously cannot enter encrypted values into the HTML forms, so those are plaintext. This is no different than if you hired a QA testing services firm to test your app. You might share credentials with them securely but whenever they are testing your app, the user has your input values in plaintext in their head, for example.
Anytime you want to test your logged-in experience (indeed, this is our most common use case today), we recommend you create a least privileged test user. This, again, is exactly what you'd do if you had a suite of manual QA tests that you run after each deployment.
- Test recordings and test runs have an execution limit of 10 minutes. You can test as much as you want in 10 minutes, but the idea is it'd be much better to create small, modular tests that you can compose together so that way you do not repeat yourself. So, nothing stops you from testing your whole app in 10 minutes, but if step 783 fails in a 1000 step test, do you really want to wait 7 minutes to verify you fixed the issue? We recommend much smaller tests that focus on individual components of your app. Then, use our scheduler to run all of your tests automatically and get notified on each individual failure.
- Since all actions occur within our cloud browser, we detect and intercept the file upload browser call and display our file upload dialog. You select your file, we store it, and then we inject it into the page under test. This is something we have not seen from any other competitor or vendor in the web regression space. They all require you to manually upload your file into their system first. We do it on the fly as if you were just uploading the file into the page itself. There is a limit of 10MB files right now. I know there are many use cases for larger files, but that's not our focus right now. (Of course, everything has a price 😉) Last point related to this, we automatically detect hovers in the same way as file uploads and this is something that most other vendors require the user to manually type in, including the selector. We do it all automatically.
- We'll capture pretty much any action, including oAuth, but if you're using 2FA we can't log you in since we don't have your second factor device. We detect alerts, prompts and other browser dialog boxes. I haven't used the Dropbox file-picker, but would be interested to try.
---
Thank you for the thoughtful questions!! If I missed anything or anything is unclear, please let me know. Also, feel free to create an account and let me know what you think. It's free as in free. No credit card.