After creating your first test with Quick Start, what essential tests should you create? This onboarding guide covers the most common and useful tests our customers create first.
The most generally applicable test is one that verifies your web application’s login flow. This test is typically short and concludes with a Visual Validation, which indicates that the login was successful by asserting on the appearance of elements that are only present for a signed in user. This test would include the following steps:
Additionally, you may want to create a test for an unsuccessful login to verify that the failure case messaging is correct.
Next, you should create a test that verifies a web application’s new user registration flow. This user experience typically validates that a user with no cookies or local state for the target web application visits the website and signs-up for a new account. The use cases for this test range from ensuring your marketing funnel is working to validating the new account onboarding flow.
It’s common for web applications to require that the new user’s email address is unique. This poses a challenge for the automated test execution, since the default behavior is to replicate exactly the input values recorded during test authoring. Thus, the test execution would fail because the test creation registered with the email address already. Reflect’s support for variables allows you to easily configure the email address to use a dynamically generated string. This ensures that each test execution registers with a unique email address. Furthermore, you can use the same domain name or other pattern for all email addresses to allow for easy automatic deletion of the test user registrations internally.
To use a variable to ensure a unique email address (or other value), remember to configure it during the test recording, otherwise the first run will fail. To configure a variable, enter a text input value into the web page under test normally. Then, click the test step on the left navigation panel for the text input action you just took. Click the “Use Variable” button above the text input field.
Observe the new modal which displays your account variables, as well as the “Add a New Variable” section for creating a new one.
If you choose to add a new variable, enter the variable name and definition, and then click “Add”. See the dynamic values section for information about the functions Reflect supports for generating dynamic content. Finally, click the row corresponding to the variable you’d like to use, and then click “Select Variable”. This instructs Reflect to use or generate the variable value for all future test runs.
While every web application is different, nearly all of them support the ability to create, modify and delete “data objects”, or state, at the account level. Whether it’s creating a new post or recording a test transaction in a database, these interactions often form the core user experience of your web application. We recommend creating at least one Reflect test of this nature, but ideally many more. It’s typical for Reflect customers to create a folder to organize these “core functionality” tests and a suite to schedule them to execute every day.
As an example, consider a Notes application that lets a user record entries in a list. A Reflect test to verify the end-to-end functionality of the application might include the following steps:
Not every application has an e-commerce integration, but validating the user Add to Cart and Checkout experiences are frequently tested in Reflect. If your web application has such an integration, it’s a crucial test for your peace of mind.
This test is conceptually simple, but it requires special attention to two actions. First, if your test relies on the specific product that you are adding to the cart, then you need to deterministically find that product on the website. So, either use a search bar with a specific/unique search term, or use the product’s URL as the test’s starting URL. Second, if you want to complete the checkout process, then you’ll need a fake credit card (assuming you don’t really want to purchase), and you’ll need to ensure that your back-end order processing system knows to ignore the orders placed by your tests.
Apart from those two details, however, this test is straightforward, and might include the following steps:
Finally, many web applications have an account settings page where the user can configure various attributes for their account. While this page doesn’t change often, its importance to the user makes it high-value and worth validating frequently. We recommend a simple test to verify that the user can execute configuration actions such as changing their name or profile picture. Of course, be sure to revert the account back to its original state to avoid breaking tests depending on the account being in a certain state.
In summary, to get the most out of your Reflect subscription, create tests for the essential user experiences in your web application first. These experiences are the highest value to your users and cost the most to you if they break. Don’t forget to use Reflect Suites to run your tests daily and receive email notifications immediately when things break.
For any questions or support along the way, please email us at firstname.lastname@example.org so we can assist. We’d love to hear of any other tests that you recommend users create first!