Testing that uses data-driven methods is a slightly different approach from testing automation. When you create a standard test, you include any required data in the test itself. But in data-driven testing, you connect your test to a data source to get information. You can use many different data sources, such as CSV files, XML, and even full-featured databases like MySQL.
Choosing a data source:
A structured text or CSV file can be used for simple scenarios. If you want to test your login with a set of username and password pairs, this would work well. For more complex tests, XML may be required, in order to add additional information to the test data. You may need to use a proper relational database like MySQL in large automated test suites. This is helpful when you want to set up your tests.
Connecting the data source
Once you have a data source, you should link it with your test. This can be done with Selenium quite easily. Let’s say you’re writing a Selenium test in Java. If you want to import your test data from a CSV file, you can just add steps without using any third-party libraries. Afterward, you create a loop that loops through each entry in the data source. If the scenario is more complex, it may be better to use XML as a data source.
Examining the result
One of the biggest challenges is how to look at the result. Sometimes there is only a single choice, but there are many possible outcomes. To compare the actual outcome with the expected outcome, one way would be to use case statements. If the expected outcome is more variable, you may want to use XML to provide a richer description. Ultimately, this is where your test automation engineers will showcase their skills.
When should I conduct data-driven testing?
A data-driven testing approach is ideal for any scenario where the same test steps need to be repeated with different data. These tests usually test the application’s logical functionality. For instance, you might want to test the login flow, or you may be testing that your shopping cart functionality is correct. Let’s look at a couple of situations where DDT would be good.
Shopping cart:
E-commerce sites like eBay or Amazon employ a complex shopping cart logic system. It is important to test this carefully since any errors could be costly. The cart must calculate the total cost correctly. This implies that you need to test with multiple collections of items. Secondly, you should evaluate the logic surrounding special offers like “buy one get one free”. You may also wish to test voucher codes properly, including any logic relating to their validity. Finally, there’s usually some complicated logic about delivery costs.
User management:
You should thoroughly evaluate your user management flows. For example, you should test the user registration flow with valid and invalid data. Furthermore, you should be testing changes and updates to user data. It is possible that you will need to test permissions.
Is data-driven testing the right approach for you?
Here are some simple rules for deciding whether or not to use DDT
- How often do you repeat the same test steps multiple times in different tests? This is usually the case for many users flows in your UI.
- Do you need to test multiple variations of the same information? When you are testing application logic, you should be able to vary the input data.
- What types of data will result in different outcomes for a test? For example, login flows that either let the user log in or not.
- Are there multiple tests running simultaneously on the same system? If that is the case, you may want to ensure that you use different data for each test.
In order to answer most of these questions, you should consider data-driven testing.
