In this article, you will learn the techniques for promoting shift-left testing with Autify NoCode Web using two of its features: Autify Connect and URL Replacements. This article is useful for:

• QA engineers who want to promote shift-left testing and be involved in development from an early stage
• Developers who want to use Autify NoCode Web tests when developing in local environments.

Features used in this article

For more information on the Autify NoCode Web features used in this article, please see the guides below:

• Autify Connect Overview | Autify Guide
• Autify URL Replacements Guide | Autify Guide

Moreover, Autify CLI allows access to a variety of useful features, such as using Autify Connect on single scenarios. To use Autify Connect, we recommend using Autify CLI.

Shift-Left Testing

The term "shift-left testing" can mean a variety of things depending on the context, but for our purposes, we'll define it as computer-automated testing that's carried out early in the development process. When you picture the development timeline that flows from left to right, testing as early as possible would be to shift it as far to the left as possible. That's why it's called “shift-left”.

A common model for execution environments for web systems is to have three environments: a local environment, a staging environment, and a production environment.

• A local environment is an environment that runs on the developer's local development machine
• Staging environments are used by the team to validate systems and are almost identical to production environments
• Production environment is the environment that users actually use

We develop Autify NoCode in this configuration.

Under this model, the codebase deployment pipeline can be illustrated as follows:

One of the most typical ways to use Autify NoCode Web is for regression testing in the staging environment, which is done before deploying to the production environment. Testing here ensures that there are no degradations, allowing you to release safely.

If you've already created test scenarios for staging environments, Autify NoCode Web's URL Replacements feature allows you to run it directly in other environments, such as the production environment.

Based on the deployment pipeline mentioned earlier, this test can be illustrated as follows. Testing in the staging environment was a regression test to catch issues before release, whereas testing in the production environment is more about monitoring the system. The testing approach that focuses on different aspects in a production environment is also called shift-right testing. In this sense, running tests in a production environment using URL Replacements is a shift-right way of using Autify.

Speaking from personal experience, when I check the test results in the production environment first thing in the morning, and they are all green (passed), it's a great start to my day. There's been many times when testing in the production environment has helped me detect problems in the system early on.

Now, let's look at the other side: the local environment. Development environments within a local network cannot be accessed from the Internet, so you usually can't run tests using Autify NoCode Web. However, Autify Connect makes this possible.

Autify Connect is software that runs in the test execution environment. It provides a secure connection directly between any network environment and Autify execution environment's network.

This technique allows you to create and run test scenarios before deploying to any environment. This is useful for checking a feature you're developing before submitting it for code review, for example.

Also, as with testing in the production environment described earlier, test scenarios created in the local environment can be reused in both the staging and production environments by using URL Replacements.

Now, we've built a shift-left pipeline where a test scenario created early on is used for the developer's self-check, then for determining whether it's release-ready before releasing to the production environment, and finally for monitoring after production release.

Portable test scenarios

The previous section described how Autify NoCode Web can be used under ideal circumstances. However, to make it possible, there are prerequisites and things you should know, which is what we will discuss in this section.

Test runs almost always involve resources (data). For example, consider a test on a resource called user. A test scenario that updates the user's name will consist of the following four steps:

1. Create a user named Harold Hivecraft in the environment
2. Verify that the user's name is Harold Hivecraft
3. Update user's name to Oliver Golden-Honeycomb
4. Verify that the user's name is Oliver Golden-Honeycomb
5. Delete the user (in preparation for the next test)

The lifecycle of a test resource can be summarized as create, use, and delete. In this article, we will call a test scenario that includes this sequence of steps - from creating the required resource to deleting it -  a “portable test scenario”.

What if we cannot automate the actions for creating a user in an E2E test for some reason? For instance, let’s say creating a user requires registration and authentication using a physical device, which is difficult to automate. Even in these cases, “update the user's name” can be tested by manually adding the test resource to the database or by creating it programmatically in advance. In this case, the test scenario itself does not include creating the resource. The “update the user’s name” test scenario could look like this:

1. Verify that the user's name is Harold Hivecraft
2. Update the user's name to Oliver Golden-Honeycomb
3. Verify that the user's name is Oliver Golden-Honeycomb
4. Change the user's name back to Harold Hivecraft (for the next test)

This would require preparing test resources for each environment, which would require extra effort for data management. If we were to use a common test scenario and utilize the URL Replacements feature as described above, we can summarize the difference between portable and non-portable test scenarios as follows:

To run a scenario in multiple environments, which is the topic of this article, we want to ideally create portable test scenarios whenever possible. So, what is the prerequisite for achieving portable scenarios? It is that, out of the CRUD operations (create, read, update, and delete), the test resource can at least be created, read, and deleted. Even if user-facing functionalities don't have all these, having an API that adds and deletes data for E2E testing will help create concise and manageable scenarios and increase the chances of achieving a more effective test.

Conclusion

With Autify NoCode Web, you can use the URL Replacements feature to run a single scenario against multiple environments. Also, Autify Connect extends test creation and execution to the developer's local environment, making it so that assets - test scenarios - can be utilized earlier in development for self-checks (shift-left). In addition, the ability to create, read, update, and delete test resources helps create portable test scenarios and maximize the effectiveness of E2E testing across multiple environments.