At Leaptest, we are always looking for smarter ways to solve tasks, and we often use our own tool to help us do that. This post is a real-life example of how we in our marketing department built a...

At Leaptest, we are always looking for smarter ways to solve tasks, and we often use our own tool to help us do that. This post is a real-life example of how we in our marketing department built a simple automation case with significant efficiency gains. Specifically, we designed an automated test case for checking hundreds of domain names from a list with mock contact data.

Using fake contacts as test data

Whether it is for trying out a new email integration in your CRM system or demonstrating how something works in your Marketing Automation application, fake contacts are useful test data.

For enhancing understanding, it helps if the fake data seems like real contacts. To achieve this, you need to make the contact properties like name, company, and email address, seem like real entries. This gets a little tricky when it comes to email addresses and website URLs as you want to avoid listing domain names that actually exist.

Of course, you can type the domain entries from your contact list into your web browser and check if they exist, one by one. But what if your contact list includes hundreds of domain names?

Building a test case for domain checks

In relation to the launch of an app to be used in product demonstrations, the marketing department at Leaptest was tasked with creating a list of hundreds of fake contacts for the app which is a mock CRM system. To enhance the app’s usefulness for training purposes, we wanted the contact list to be relatable and thematic rather than just relying on placeholder data. However, this also meant that we had to create hundreds of fake email addresses which could potentially include domain names owned by someone – and we wanted to avoid that.

An excerpt of the thematic list of fake contacts.

We used the Leaptest Automation Platform to build a simple automation case for testing whether the domain names exist. Below is a screenshot of how the case was designed in Leaptest Studio, and then a walkthrough of the steps involved.

How the automation case looks like in Leaptest Studio.

1. Start Web Browser

We wanted a web browser to be opened automatically, so that the website URLs could be checked. In this example, we used the Chrome browser.

2. Read Excel

The list of fake contacts lived in an Excel sheet with a column called ‘Domain’. The sheet was uploaded to the ‘Read Excel’ building block, and then the property ‘Domain’ was mapped as the data input for the next step in the flow.

3. Navigate Web

We wanted our web browser to navigate to the URLs provided in the Excel sheet. Instead of typing in the URLs in the Web address field, the ‘Domain’ property served as a dynamic input to this building block.

4. Get Web Text

In this step in the task flow, we defined a value used for validation. In this case, the success criterium was for a URL to return an error message stating that the given domain does not exist – because we did not want the domains in our list of fake contacts to be owned by anyone.

To indicate whether a domain exists, we asked Leaptest Studio to look for a web page header (an H1, specifically) with the text: “This site can’t be reached” as that is the Chrome browser’s default error message for domains that don’t exist.

Defining the validating value.

5. Log Web Screenshot

If the web text defined in step four was not found on a given web page (meaning that the given domain does exist), then Leaptest Studio was set to log a screenshot of that page.

Iteration

This case was set to test all the hundreds of URLs listed in the Excel sheet. We did this by choosing the ‘Iterate’ method in the ‘Read Excel’ building block.

Using the Iterate method in the Read Excel building block.

When Leaptest Studio had run through all the domains to be checked, the case was done. Because of the ‘Log web screenshot’ action, we now had a list of screenshots with all the domains which did in fact return a website, and which could not be used in a fake contact list. We could also quickly scan the screenshots for whether the URLs host domain-vendors, in which case they were fit for use.

Leaptest Studio after case execution. The case run has been recorded as a short video, and the automatically logged screenshots are easy to go through for validation.

Efficiency Gains

The efficiency gains achieved by this case were quite obvious.

What’s more, if the contact list consisted of 1000 contacts, it would still only take around 5 minutes to build the automation case with Leaptest. On other hand, the time needed for doing this task manually would keep increasing with the number of contacts, as a human would reach a limit to how fast a domain name can be pasted into a browser and checked.

Other Use Cases

This case can also be used inversely for real contact data. Say you have an offline list of contacts, of sales leads for example, and before uploading the contacts into your CRM system, you want to check the quality of the contacts by testing the validity of their email domains. You would just need to define the inverse success criterium, and then log any domains that return an error message.

Finally, If you are looking for a web domain for your business, and you have a long list of suggested domain names, you could also use this case for easily checking which ones of them are available.

To learn more about the concept of flowchart-based automation, and how you can use it for easily obtaining efficiency gains, read the report “The Codeless Future of Automated Testing”.

View Entire Post