Test StudioT2 Dark_1200x303

Finding a way to master your automated test suite keeps every tester busy probably not only during working hours. Yet, does it have to be so hard?

This blog post presents a selection of test recording techniques every tester should consider in an effort to build a more stable, reliable and easily maintainable automated test suite.

Getting a tool is often the path organizations choose for their teams. However, the tooling does not automatically solve the problems at present. The people using the tools do. The role of tooling within an organization is to help people find a smarter way of getting things done, argues the author of a Forbes article on the critical aspects to consider before adopting a new technology.

To make things easier for you, especially if you’ve just started building your automated test suite with Test Studio, I’ve prepared a selection of testing techniques that our test engineers recommend to always consider while creating automated tests.

Spoiler Alert! Keep reading as there might be eye-opening information further down the article.

Call this basic, but mastering the fundamental techniques of test recording is where you should start. You already know everything about recording? Well, knowing a few more hacks can only help you master your test automation skills.

Remember, all of this will be about building the smartest, not the fastest tests. Adding the appropriate timing and the necessary check-ins along the way, for example, might slow down your tests a bit but will pay off in the long term by making them more stable and easier to maintain.

I promised hacks, and here we go!

1. Adding the Right Verifications at the Right Time

Mastering the art of adding verifications is the first principle behind stable and reliable automated test suites. Aside from the fact that we still see tests without a single verification added, which is almost the worst thing that could happen to you as a tester (because it leads to a very fragile strategy), it is vital to understand when in your test to add verifications and which verification to choose in a particular scenario.

Start by having a clear goal. For the purposes of the demonstration, let’s say that we want to create tests that we would never have to record again or—worse—to switch back to testing the target functionality manually.

Capture actions as part of your test with the Element Highlighter from the Test Studio recorder. This is where you will be adding your quick verification steps from. The recorder provides you access to a predefined set of quick verifications that are there for a purpose.

These are the most common functional verifications. If they don’t pass, the test fails. That is how we get an indication when the test detects issues on a functional level and can take appropriate action—investigate further, log a bug or detect a script issue to be fixed.

If you need more advanced verifications like image comparison, style validations, etc., the Advanced Recording Tools part of the Recorder is the place to find them.

Besides the Test Recorder, you will be able to add other verification steps later in your test from the Step Builder. This is where you will find all sorts of non-functional (!) or cosmetic verification steps—for example to verify if an element has the right color, etc.

This can happen even if you don’t have the application under test started. Just select an already recorded element from the Element Repository and add any action or verification for it.

Another important rule is to consider adding verifications when a certain result is expected. When changing pages or going from one page to the next is typically where you should be consistent in adding verifications to make sure that the correct content has been loaded in the UI.

We said in the beginning that you start by adding functional verifications during recording but always have the option to add verifications later. Imagine having a very long test and yet you need to go back and add more verification steps. A useful feature to take advantage of in such cases is “Run to here.” It allows you to run the test up to a selected test step and add additional steps right where needed.

2. Building Test Steps Efficiently

While the Test Recorder lets you create tests easily based on visual interaction with the UI of your application, it is important to know how you can enhance your tests.

The information that you get access to in the Recorder is a snapshot of the current state of the DOM tree of the page under test and all its elements. For example, when you add verification steps, you can see the attributes of the element you will be verifying with its values.

The Step Builder, which is accessible inside Test Studio, on the other hand, gives you a whole new bunch of powerful capabilities. It lets you build additional test steps when you don’t necessarily have to be in record mode.

Let’s look at the available options to build a step. There is a significant difference between the build step function in the Recorder and the Step Builder. Again, it’s important to have a clear goal for what you want to achieve and how you are going to achieve it.

After a major recent UX/UI update of Test Studio, all Common Steps from the Step Builder are available in the Advanced Recording Tools, right at your fingertips during recording. Yet, to modify your tests to meet specific scenarios, it is recommended that you get yourself familiar with the Step Builder.

Let’s look at an example.

You can build a step from an already recorded element. At some point we’ve captured these elements during recording, and they’ve been added to the Element Repository. Select an element from that repository and you can add more actions or verifications from the Step Builder.

You can use the Step Builder when you want to add a step that is not tied to an element—i.e. conditional logic. Remember that if/else or while/loop steps will rely on verifications. There are other useful steps to be added—for example, clearing browser cache, capturing the browser, adding execution delays or checking for JS errors. All of these are available within the Common Steps tab in the Step Builder.

Let’s look at another example.

You know where you need a step for an element, but your test is very long. You don't want to wait 10 minutes until all steps are executed until you get to the element for which you need to add a step. You can use the Step Builder “offline” or outside record mode to do that if you have the element already recorded in a previous test recording session.

Test as Step

An essential element of the Step Builder is the test as step option, which is the one technique you need to modularize your tests.

You can even go as far as having entire tests made of multiple tests as step. This feature allows you to create a parent/child test hierarchy, which is easy to maintain and accounts for immense flexibility and stability of your tests.

Let’s look at how you run an existing test as a single step, within another test. That allows you to reuse common automated test steps across your project. You build easily maintainable test projects by creating smaller tests and using them as steps in other tests.

Any web/desktop or API test can be used as a step in the same project. You can do that under the “Common” tab within the Step Builder.

Why is Test Modularization Good for Your Tests?

Let’s look at the following scenario. You have an application in which you always need to log in before you do anything in terms of automation. That would mean that you need to integrate the login scenario throughout all of your tests, as that is where the user journey starts.

Imagine now that you have created all your tests one by one, by always starting with logging in. If your username or password changes, you will have to go through all tests where the login element is involved and change it manually.

Not in Test Studio though, where you have the test as step option. The only thing you need to do is record two or three simple steps of “input username”, “input password” and “click login button”. You then save these two or three steps as a test as step in the Step Builder so that you can add the single test as step throughout your tests wherever you need it.

Always remember to add a verification step after clicking the login button, to verify that you have actually logged in. It could be a step to verify that the post-login/welcome message is visible or whatever your application does to indicate successful login.

If your username or password changes, you update these once in the test as step and the changes will automatically apply to all tests that reuse that test as step.

What’s the easiest way to apply that scenario?

You start your test, go get your login test as step, use the “Run to here” option and start recording from there. Run to here is going to get you logged in, from where you can proceed with recording your test.

Login is a very powerful illustration of the advantage of reusing existing tests as steps within other tests—the key principle of test modularization.

3. Using BaseURL for Running Tests Against Multiple Environments

The idea behind using BaseURL takes us back to the project settings. Testing is almost never done on a single environment, and that is the idea behind the shift-left mindset. Fortunately, we at Test Studio see more and more teams automating testing for their projects against multiple environments: staging, UAT or prod.

The effort to configure your automated tests for execution against multiple environments might be immense, depending on your application’s infrastructure and testing infrastructure.

Setting BaseURL in Test Studio allows you to reuse already recorded tests to run against multiple environments, which are typically available under slightly varying but sometimes completely different URLs. Defining your BaseURL on the project level will help you execute the same tests within different phases of your application development lifecycle.

Now let’s look at the project settings. One of the first things you see in the recording tab within the project settings is BaseURL. The Compare Mode as well as the BaseURL structure are explained exhaustively in the Recording Options documentation.

BaseURL can save you tons of time if applied correctly on your project as it helps you avoid rewriting all your tests from scratch to make them work with a different server address.

Why is the Compare Mode important?

As you are creating tests, you are recording elements. Those elements are being located/categorized under the pages that are recorded. The way Test Studio recognizes the page is based on the Compare Mode. If it is being too specific, it might create duplicates. If it is looking for “FullpathandQuery” for example, it will create duplicate pages and elements. When looking for “Fullpath” only, that won’t happen.

Final Thoughts

I hope this article has helped you better understand how to make the most out of Test Studio while building your automated test suite. We have barely touched the surface though and will make sure to walk you through more of Test Studio’s performance-boosting features in some upcoming blog posts.

We like to say that Test Studio will integrate seamlessly into your automated software testing needs because of its ease of use and powerful capabilities. But remember what we said above about the people and the tools? Testing should be driven by real use cases, and real use cases are created and solved by people and the people’s genuine need to do things smarter.

If you haven’t tried out Test Studio recently, it might be a good time to do so. All recent releases brought great new additions to its test automation capabilities such as OCR and PDF validation features, headless testing, test storyboard capturing and more!

Your free 30-day trial will also give you access to free on-demand online training and product support. What’s more, our automation experts will make sure to support you with what you need for a successful evaluation—be it a personalized demo, consultation or a PoC.

Try Now

Check out our recent post on “5 Ways to Speed up Your End-to-End Tests.”

Asya Ivanova
About the Author

Asya Ivanova

Asya Ivanova is the Product Marketing Manager for Telerik Test Studio. A passionate technology enthusiast, she has product experience within BIM, Master Data Management and pro audio. Together with the Test Studio team she keeps an eye on ways to make test automation easier for the QA engineer. Asya is a hi fi geek, spending her time with some good old and new album records. Connect on LinkedIn.

Related Posts

Comments

Comments are disabled in preview mode.