Don’t let flaky tests undermine the value of your test automation Learn for free
This course demonstrates the process of setting up and applying Data-Driven Testing with Katalon Studio. By using just one test script to run with different data from multiple sources, you can increase the test coverage with fewer resources and maintenance costs.
In three chapters, you will learn about:
00:05-00:38
In this first chapter, let's quickly go over the concept of Data-Driven Testing and the benefits it offers for test automation. Then, we'll move on to using Katalon Studio to set up and run data-driven tests. Let's start off with this scenario. When applying automated testing to verify a login screen's functionality, you need to perform tests using dozens of accounts, even hundreds, with different sets of credentials and user roles to increase the confidence level when shipping this login screen to production.
00:39-01:05
If you're new to test automation, here are several approaches that you could think of. The first one, you create ONE automated test script and manually change the credential values every time you run the test with a different account. So, 100 accounts mean 100 test runs and 99 times of changing data manually before running the tests. This sounds like the worst solution ever!
01:06-01:36
The second approach, you create an automated test and then duplicate it. Each duplication is for an account that you're going to test with. So, 100 accounts equal 100 test cases... Put them into a test suite and run. This is still very time-consuming and results in a lot of duplicate scripts. Not to mention that when the UI changes, you need to update all of the test cases... This approach isn't better than the first one.
01:37-02:23
The third approach, and also the right one, is to apply Data-Driven Testing. Meaning you create ONE automated test case, using variables for inputs and expected results, and prepare an Excel file to contain all the test data. If you want to test with 100 accounts, then the file will have 100 rows of credentials. What you need now is to code the script to get the test data from the Excel file and run the tests one by one. And that's the concept of Data-Driven Testing - running the same automated test case or test script with different test data that can be stored and read from a separate source, like an Excel file or database.
02:24-03:03
Then, why Data-Driven Testing? Well, first of all, more test data means higher test coverage and higher chances of bug detection. Second, Data-Driven Testing saves up time and resources since you don't need to create and run many test cases for each set of test data, hence, minimizing the duplicate codes and work. Also, it's easy for you to maintain. Test data, including test inputs and expected outputs, are stored separately from test scripts. You can change, update, or add new data to the data file without changing anything in the script.
03:04-03:23
Moving on to how Data-Driven Testing really works. Based on the concept I've mentioned earlier, you might have guessed it. Instead of using hard-coded values, a test script reads and uses test data stored in external files or database management systems to test a given AUT.
03:24-04:07
For Data-Driven Testing, Katalon Studio supports various types of data files to which you can bind variables, including internal data in Katalon Studio, external data files such as MS Excel and CSV files, and any Java Database Connectivity (also known as JDBC) sources like PostgreSQL, MySQL, Oracle, and MS SQL Server. That's all you need to know about the concept. In the next lessons, we're going to show you how to create an automated test case and bind data to apply Data-Driven Testing using Katalon Studio. See you.
00:05-00:43
Hello. Here I have my Katalon Studio ready. Just a quick reminder, you can go to Katalon.com/download, install the tool, and follow along. Let's start by creating a new test case. Right-click on the Test Case folder > New > Test case. Give it a name. For this course's demos, we're going to test the search functionality of the Airbnb website. So, I name mine ''Find a place.''
00:44-00:58
With Katalon Studio, you have several ways for you to automate your tests depending on your programming skills and experience. You can use Record & Playback, built-in keywords in the Manual mode, or using the Script mode to write your test script.
00:59-01:48
In this case, I'll choose Record & Playback. Click on the Record Web button on the toolbar. Paste in the URL to the Airbnb website. Then, hit Record. It will open a browser window and navigate to the Airbnb website. Every manual action you take and every object you click on will be recorded and turned into automated test scripts. Let's search for Atlanta. Check-In... 3 days. Then, select Search... Now, I'll choose this text ''stays in Atlanta'' for verification. Now, stop recording.
01:49-02:24
Here we have all the recorded steps. Everything seems good. Let's go ahead and Save Scripts. This window pops up, giving you the options to save these new test objects. On the right is the folder structure of my existing repository. On the left, you can see the test objects are organized under a Page-Object model. I will create a new folder to save them. Name it ''Airbnb pages.'' Select it and click on OK.
02:25-03:00
You can further rename the pages in the object repository for better visibility and maintenance. I will rename this one to ''Page_SearchResult'' and the other ''Page_Search.'' You can also quickly locate a test object by double-clicking on it (in the test case). For instance, this ''Check-in'' object is in the ''Page_Search'' folder.
03:01-03:33
Alright, I'll run this test to see how it goes. What I just showed you is basically how to use Record & Playback to quickly automate a simple test. To learn more about this low-code approach, you can check out our Katalon Studio: Record & Playback course. Well, after finishing this course. Our test run is finished. And it passed.
03:34-04:00
Now, what if you need to test with more test data - with more cities? You can double-click on the Input column in this test case and change the value. Make it ''Tokyo'' for the city input. Change it to ''Stays in Tokyo'' for verification. And, let's run this again.
04:01-04:18
This is the first approach we've mentioned earlier. You change the value in the test case every time you want to test with new data. But it's really time-consuming and seems to go against the core benefit of test automation - which is supposed to save time and resources.
04:19-04:58
Okay, so this is when you need to apply Data-Driven Testing. To do this, your test case needs to use Variables instead of hard-coded values. Select the test case. Click on the Variables tab. Select Add. This first variable is for city input. I will name it ''city'' and type in ''Atlanta'' for the default value. Add another one used for verifying. I name it ''expectedResult'' and ''Stays in Atlanta'' for the default value. We use this value because the input city for searching is Atlanta.
04:59-05:30
Back to our test case. Click on the Input ''Tokyo'' here, change the Value Type from String to Variables. Select city for the value. And do the same for the verification step. I will change it a bit, switch the value type to Variables, and choose expectedResult. Don't forget to save it. I'll run this test and see how it works.
05:31-06:22
It will use the default values added for the 2 variables to fill in the location and verify the text on the search result page... So, it passed, as expected. The first step is done, setting up variables. Let's move on to put this test case into a test suite and continue to prepare our data file. At the moment, the current Studio version I'm using, 8.2.5, only supports Data-Driven Testing at the test suite level. However, in the next versions, from 8.3.0 onwards, it will also support the test case level. That means you will be able to bind test data to both test suites and test cases, depending on your test scenario and needs.
06:23-06:49
Alright, I have already created a suite here. Click Add and choose the test case to put it in. Next, click on Show Data Binding to map test data with the corresponding variables. You can see that the two variables we created have already been loaded for the Variable Binding. Right above is the Test Data section. Since we haven't created anything yet, it's all blank.
06:50-07:50
To create a data file, right-click on the Data Files folder on the left > New > Test Data. Give your data a name. I name it ''100 cities''. Here we have many data types. But let's go for Internal Data first. Then, choose OK. It will open a tab for us to work on our data. Click on the Add icon to create a new data column. This first column is for the city input. I name it ''city". For the second column, I name it ''result'' - which will be used for verification. After that, add in some values for these columns. Let's go for 3 cities: ''Atlanta''... ''Stays in Atlanta'', ''Tokyo''... ''Stays in Tokyo'', and ''New York''... ''Stays in New York''. Again, don't forget to save it.
07:51-08:17
Back to our suite and data binding. In the Test Data section, click Add. Choose 100cities data, which we've just created. Click OK. As our data has been added, continue to select Map all. It will bind the variables of the test case to the data column with the exact same name in the data file. Here it says, ''Found 1 match(es).''
08:18-08:41
Looking at the first city variable, it has been bound to the data in the city column. But the expectedResult variable is still the same. This is because it cannot find the column in the data file that has the exact same name as the variable. Our column name is ''result,'' not ''expectedResult.''
08:42-09:27
If it's just 1 or 2 variables, you can choose to do the mapping manually. First, choose the Type. Here we have several options. Let's go over them quickly. If you leave it as Default - it will use the variable default value in the test case to run data-driven tests. Data column - it will take the column name as value. Data column index - it will take the column number as value. For example, in the last value column, if I type in 2, it will bind the variable to the second column in the data file. For script variable, we'll skip it for now as it involves a Variable Value Builder.
09:28-10:33
I'll go for Data column. Next, select our '100cities' data and finally, choose the result column for the value. Save it and run this test suite to see how it goes. This test case will be executed 3 times, each time for a data set, or we can say there will be 3 iterations. An iteration is a test case executed with a row of test data. The first test is looking for a stay in Atlanta... Done and close. Then, it opens a browser again and continues with Tokyo. Lastly, New York. All the steps are mostly the same.
10:34-11:18
The test run is done and now it's preparing the report and uploading it to Katalon TestOps. Looking at this, all of the tests passed. You can see more details below under the Log Viewer tab. Run 3/3 - Passes: 3 - Failures: 0. You can click on the Result tab to see the executed tests' report. Since I've already set up video recordings, here I also have an option to rewatch all the executions. Or you can click on the Report folder on the left, select the executed suite to see the same report.
11:19-12:00
We have a separate course for using Katalon Studio for test reporting and TestOps integration. Make sure to check it out if you want to know more about working with test logs and other features for troubleshooting. Alright, that's the end of our chapter. You have learned how to use variables for your tests, create internal data, and map them together to apply Data-driven testing. In the next lessons, let's try out Excel and CSV files and also JDBC databases. I will also show you how to combine data from these sources to run data-driven tests. See you.
,,
thanks for katalon team
Bbioof
good
Good
Good
Good
30-DAY PREMIUM TRIAL