Broadcom Test Data Manager Reviews

We use the solution to manage test cases. 

The solution has a portal where we can create data. We can also create synthetic data with the help of the product. We can use it to create a new data set in the database, eliminating many issues. The product helps with data accuracy and availability. 

The benefits of doing something like the data creation is that you are going to be able to totally have control of your data from the get-go. You are not worrying about "what you see is what you get" kind of results from a production set. Instead you are just using all sorts of built-in functions, seed lists, or data calls which are live at that moment to be able to really manipulate your data and create exactly the data set that your testers need. That is very powerful. 

Then on the vTDM side, which is the database cloning, the ability for them to have full control of their environment is the most important aspect of testing sometimes. Now, you do not have to worry about what is on your left, what is on your right, and who you are going to be hurting by trying to do the best testing that you can. Instead you have just you are own set that you can work with. You can spin it up and burn it down when you are done. 

TDM has tons of great solutions involved in one package. For me personally, what I find to be most valuable is its ability to do synthetic data creation. I love that because it has a lot of flexibility and you do not have to worry about one specific database or how you are going to manage all the data points. What you can do is  instead of taking everything from production and wondering what you are going to get from there, you can just create it all from the get-go yourself. That is a beautiful thing to be able to do. 

There is other stuff that they are working on right now, and that includes things like the vTDM or Virtual Test Data Management. That is where they have the ability to do test data clones. It is really neat because after doing some of that creation, or if you are going to do some subsetting, then you have a great looking database. What you can do now is you can take really small copy, actually a full size copy but really small in size, and you can send that out to any of your testers to be able to use personally for their testing. That is cool because it gives them an expanded way to do their testing. They can do tons of unit tests, functional tests, and destructive tests, and they do not have to worry about the environment around them, because this is just their copy. 

We use a lot of creating data mods and test matching features. We did establish the subsetting cloning process as well, but based on the client requirements. Creating data mods and using test matching features are something which we have found fits our purpose. We use most of the test matching features in our testing processes and also the integration with App Test is something we heavily use.

We can always get different sets of data and obtain the most recent data. They have production refreshers, where we can get data subsets of that data and to do our testing. We can also lock it down for a particular user's test or generate data. E.g., if the data is not there, there are multiple forms and variables through which data can go through and so we can generate it. 

When I run my App Test, I can directly connect with TDM. I can publish all my data into one table in TDM,  then run my App Test directly. Essentially, my one test runs like 100 sets of data, I just click one test and it runs with 100 sets of data. 

I like the integration a lot. We also use the test matching feature and the ability to make and find data.

The benefit is that it's something you can repeat over and over again, once a solution is in place. You can benefit from it as often as you want to and without having to constantly looking for support.

The most valuable feature of this solution is data quality, that ability to provide data for testers and developers that is actually usable.

There are a lot of great features with Test Data Manager. It's allowed us to really revolutionize the way that we are doing our testing. We use Test Data Manager to create synthetic data for our testing purposes. We have a legacy application that has been around for a very long time, and a lot of the people that originally developed it are no longer with the company, so we've had to do a lot what we call, "Data Archaeology," to go in and recreate our data model. Test Data Manager has allowed us to do that, capture that model, and then create that data on demand, saving us a huge amount of time and money in the process.

It's really allowed us to focus on the craft of testing, and not focus on the creating data, spending time setting up the scenario that we need, or trying to find that sort of thing. It's allowed us to be more focused on our efforts, it's allowed us to be faster. We run an agile shop, and so we've been able to use that data in our pipeline as we deliver stuff in a CICD world. It's been great.

TDM is something people do all the time. You cannot say it is something you're going to do from scratch. For every client, there is a different scenario. There are a lot of use cases. But a couple of use cases are common everywhere. One of them is the data when it is not there in production. How do you create that data? Synthetic data creation is one use case challenge that is common across the board.

In addition, the people who do the testing are not very conversant with the back end or with the different types of databases, mainframes, etc. And most of the time they don't write very good SQL to be able to find the data they are going to do their testing with. So data mining is a major concern in most places. 

The use cases are diverse. You cannot point to many common things and say that this will work or this will not. Every place, even though it's a TDM scenario, is different. Some places have very good documentation, so you can directly start with extraction, masking, and loading. But for most places that is not possible because the documentation is not there. There are multiple use cases. You cannot say that one size fits all.

In the testing cycle, when there is a need for test data management tools, we use CA TDM to put up the feed.

If you take DevOps as an example, suppose development has happened and the binary code has been deployed to a certain server. To do continuous testing or continuous integration, you need the test data. CA TDM has a feature where it can generate the required data beforehand and keep it with your test cases however you need it. If you are using JIRA it will put the test data in JIRA. If you are using ALM it will give data to HPE ALM. Once you are running your test cases in an automated way, the data is already there. 

And the data provided will work for all the results. For example, if you want to do a set of automated scenarios, it will work with that. If you want it to work with various regression cycles, it will work with that. And the same data, or maybe a different set of data that you provide, will work with the unit cycles as well. CA has the ability to provide all the data on-demand as well as on the fly.

The solution used for DevOps Pipeline.

For us to sell TDM, we look for specific key differentiators. For instance, TDM only requires a little infrastructure compared to Intel Six, Informatica or other solutions requiring hardware resources. TDM can be connected with DevOps and easily plugged into the DevOps pipeline with the available APIs. Plus, there is an inbuilt automation-friendly API and an inbuilt automation tool to automate the tedious task within TDM.

Broadcom Test Data Manager is used for test data management requirements, along with data generation, data masking, data subsetting, and service virtualization. Also, the solution can be connected to your automation tool.

Data generation, data masking, and data subsetting are three key features of this tool. So, all these three features come in a single tool.