Broadcom Test Data Manager Reviews

When it comes to use cases for Broadcom Test Data Manager, clients may use it for data masking.

From a service provider perspective, regarding the data masking, data subsetting, and data virtualization features, many products in the market provide the same services. From a technical side, it's a very fake application. In the bigger solution, if this application was stuck, it's because we didn't design the relationship between tables and databases on the database layer; we designed this relation between tables on the application layer. This makes the data retrieval in and out from the database to the application much faster and more useful. Any application regarding data masking needs to read this relationship between tables to build a background for ERD. The best solution for data masking, data subsetting, and data virtualization is to work in the database directly, reading a value from a table directly and transforming it, which will be useful and fast and use the same database infrastructure specification servers.

Any other application in the market working in this solution is a fake solution, useful only in small- and medium-sized companies, not big sizes like telecoms, banking, or financial solutions. My point of view is based on working with many applications which perform similar functions, and they read tables from the database, read the values, and generate another set of values in a different schema, which is not useful as it requires a lot of operations. The effort to read the relationship between tables and build an ERD diagram necessitates expertise to ensure the relationship is correct. Therefore, why bother to build this relationship when I can read the table directly from the database, transform the values into another table directly for masking?

The last feature I'm speaking about is called the synthetic data generation feature.

Overall, this can definitely be the advantage of the product, and I'm happy with these functionalities that Broadcom provides. I totally recommend any application working on the database layer directly and I don't recommend any applications from other external vendors to perform the same function. Oracle and PostgreSQL have similar applications and they both work directly in the database, reading directly from the database, transforming values in another table within the same database, making it easy to run.

The solution is saving me time and money in general because this application saves money and a lot of effort. I can generate any amount of data from Broadcom Test Data Manager, which has a lot of information and equations regarding this task. It saves money because my testing team needs this data to create use cases tested on realistic data. Broadcom Test Data Manager adds great value to my organization, but I believe it can be afforded only in international, large-sized companies. It is not affordable for medium or small-sized organizations.

In terms of areas for improvement in Broadcom Test Data Manager specifically, I recognize that building the ERD diagram after connecting to the database is very difficult and requires improvement efforts, but this is the necessary point if Broadcom does some effort here, Broadcom Test Data Manager would be the application number one in the world.

The challenge with connecting the Broadcom Test Data Manager solution to the database lies not in the actual connection but in how it builds the relationship between tables after establishing the connection. This is the aspect that needs improvement.

I'm using Broadcom Test Data Manager for two years.

It is stable overall, but I do face issues with latency; however, this is related to reading information from databases, especially when dealing with multiple databases containing more than 10 terabytes and 5,000 tables. Broadcom Test Data Manager takes a lot of time reading this information.

Regarding technical support from Broadcom, I find them very helpful.

Positive

The initial setup and installation of the Broadcom Test Data Manager solution is not complex; it is easy to install and easy for scalability because it supports Docker and Kubernetes for both horizontal and vertical scaling.

Broadcom Test Data Manager is scalable; it supports Docker and Kubernetes, allowing for quick horizontal or vertical scalability.

If I were to rate their support from one to ten, I would give them a ten.

Let's divide the question about Broadcom's standing compared to other vendors. If we talk about Oracle, PostgreSQL, or any company with its own database that performs the same function, Oracle and PostgreSQL will lead in situations with very big data. Broadcom Test Data Manager does not perform well with big data. If there are more than 5,000 tables or over 10 terabytes of storage, Broadcom Test Data Manager does not play well in this area. Test Data Management related to Oracle plays better than Broadcom, and PostgreSQL applications perform better than Broadcom Test Data Manager. However, if we're considering applications provided by other companies as external applications that read data from databases, build ERD diagrams, and perform functions such as synthetic data generation, Broadcom is number one.

On a scale of one to ten, I rate Broadcom Test Data Manager an eight out of ten.

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. 

Broadcom Test Data Manager is for data management. I would like to see some extension with data warehousing concerning ETL. It should also integrate with Jira or other reporting tools. Currently, after creating data, we update tickets and other information in various tools. This would enable us to attach relevant files or information to specific tickets. 

I have been working with the product for seven years. 

The tool's stability is eight out of ten. 

Broadcom Test Data Manager's scalability is nine out of ten. 

Sometimes, I feel there are issues and concerns that people address through calls and support. However, the turnaround time for support is currently on the higher side.

Neutral

The tool offers a synthetic data feature we want to explore for its potential benefits. Apart from synthetic data, the tool provides various other features. Additionally, the tool comes with its own data importer, enabling us to manage different scenarios and enhance self-service settings, among other functionalities.

The initial deployment was a bit complex. It is straightforward now. We have migrated from SQL, Oracle, and Google Cloud in the last five years. 

We have seen ROI with the product's use. I work in a company with around 2,000 to 5,000 people across different verticals and products. We managed to cater to the needs of all the teams with a single team, creating data centers and scheduling effectively. While it's challenging to achieve 100%, we were successful in providing accurate and timely testing for about 80 to 90% of the scenarios.

The tool's pricing is high. 

It's entirely driven by your organization's needs and understanding what you require before deciding on a feasibility schedule for any tool. However, I would say that the Broadcom Test Data Manager has almost all the features we're looking for in a testing tool. It aligns well with the market in terms of capabilities and functionalities. You can get 80-90 percent of features and capabilities within the product. I rate it a nine out of ten. 

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.

The solution is very user-friendly. For instance, if I wanted to create a project with Data Generation, Data sub-setting, Selective sub-setting, and Data Marketing, it can be easily done in TDM. And if you want to export these project definitions from one system to another, it can be done with just one click.

I would request to extend the data source support because there are a lot of cloud-native SaaS-based solutions in the market. Like, Azure has its data sources, Amazon-specific data sources, and there are a lot of proprietary data sources outside as well. I recommend the team to expand the data source support.

.

Most of the CA products go through a lot of compliance and certifications. So they apply secure coding and secure build; hence the product stability is too good. And apart from that, there is a community outside. It's a publicly available community, and it's very responsive. You don't need to drive the ticket in the portal if you have any issues. You can paste your queries. In the community, you'll immediately get the response because a dedicated team handles the community.

It is a scalable solution. Go with a classic VM-based installation. You can do horizontal scaling, like adding resources, you can do that, and you don't need to have any downtime. But with the Kubernetes edition, you can have other vertical and horizontal scaling, and auto-scaling is available.

There are no dedicated resources for TDM, but one can go and paste their queries on the portal or erase a ticket on the community portal. The team is very responsive and active. A dedicated team for support is in progress.

Positive

The initial setup is straightforward. There is a wizard, and one needs to click it and set up the solution. And you can run it on a desktop machine; there is no need to have high-end servers to run or install it. The good part is that it has a Kubernetes edition, which is amazing. If you look at the trend, there are many tools you need to place on On-Prem, or there could be a SaaS version also. But Broadcom TDM has a Kubernetes edition so you don't need to consume a lot of cloud infrastructure. So as and when there is a demand, it can make a scalable number of forwards and do a Kubernetes scalable masking, which I don't think any other system in the market delivers these kinds of options capable of. As TDM is delivering a Helm Chart so, once the prerequisites are ready, it just takes a few minutes to deploy it. For the deployment, the main thing is taking role-based Control, and there is a dedicated guy. We can have for creating definitions for data generation and sub-setting, you can have a dedicated guy for creating the masking definitions as well.

Mainly, we compete with the IBM team and Informatica, and if you compare the license cost, Broadcom is too flexible. Depending on the customer's budget, we suggest they buy only respective SKUs, and it's much cheaper compared to others because we have gone over multiple deals where pricing was never a factor in differentiating products.

TDM provides the option of choosing your Kubernetes environment and whether it is managed Kubernetes environment or a classic On-prem Kubernetes environment. You can put it over there because it is primarily customers' preference, especially banking customers, who want the On-Prem version as they don't want to allocate more resources. And suppose a company wants to have a cloud partnership that can use Azure, AWS, or any other Managed Kubernetes environment. In that case, the idea is you don't consume the entire cloud resources because if you look at masking a job, it will only happen sometimes. So here's the idea on-demand, scale it up to the maximum, and once the job is done, you scale down. It saves a lot of money.

The users should keep a futuristic view for TDM because, at some point, you may need to decide where it can be deployed in Kubernetes and in which version. Because going forward, you'll shift to some other cloud, or you might have a private cloud within your organisation, and you don't want to use the classic deployment options. So whenever you find a solution, you need to look at a futuristic solution where it can be deployed. If you are deploying in VM today and tomorrow, if you want to change, installing it in the Kubernetes environment should also be viable.

I rate it nine out of ten.

I rate Broadcom Test Data Manager a nine out of ten.

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.

Regarding improvements in the solution, we always need to customize Broadcom Test Data Manager because every customer and every organization is different. So, a few changes are always required, for which we get support from Broadcom.

Stability is an area in the solution that has room for improvement. In general, the price, stability, and scalability could be better.

I have been using Broadcom Test Data Manager for a year and a half. Also, I am using the solution's latest version.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution between seven to eight out of ten since there are so many systems and databases, and the scalability of the solution depends on them. But it does support a lot of databases and applications. Right now, there are three users using the solution in my company. Also, we don't plan to increase its usage.

We contacted Broadcom's customer service and support in our company. The technical support has been really nice. They have been very much supportive.

I would say that the initial setup is not that easy, but it's not that difficult, either. An average level of complexity is involved in the setup phase. Installation doesn't take time. However, installing, like, a full-fledged data management solution can take years, depending on the organization and complexity. Regarding the deployment process, we started the data masking, and then we moved on slowly to synthetic data generation and data subsetting. So, these steps could be difficult to elaborate on because it depends upon the organization's requirements and what they really want to implement.

The staff required for the deployment to maintenance would really depend on the organization. But typically, it should depend on a minimum of three to five resources, and then it can go on based on the requirements.

My company makes yearly payments toward the licensing costs. So, I consider the licensing costs to be expensive, especially considering what I have heard from my colleagues. They say that there are so many vendors in the market now for TDM, and Broadcom is one of the costlier ones in the market.

I would say implementing test data management requires a lot of effort and time. Many organizations fail to provide sufficient support and time since most organizations think that they have the tools, licenses, and people to solve their problems. However, that's not the case. Even if you have experienced people, it takes time. So, in my first organization, it took almost four years for us to give synthetic data generation capabilities. Certainly, we should implement Broadcom Test Data Manager, but the organization doing so should have time and patience.

Overall, I rate the solution a nine out of ten.

Broadcom TDM's best feature is the self-service portal.

Broadcom TDM takes a long time to import documents, which wastes time that could be spent on other things. It also hasn't evolved much in the last ten years. In the next release, Broadcom should add more mining, search, and variable capabilities.

I've been using Broadcom TDM for eight to nine years.

Broadcom TDM is stable.

Broadcom TDM is scalable.

The initial setup was challenging, and I would rate it 1.5 out of 5.

An ROI is easily achievable with Broadcom TDM and can be achieved in two-and-a-half years. I would rate the ROI as four out of five.

I would rate Broadcom TDM's pricing as four out of five.

I would give Broadcom TDM a rating of eight out of ten.

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 combination of extract, mask, and load, along with synthetic data, is what is generally needed by any of our clients, and CA TDM has really good compatibility in both of these areas.

CA is one of the few tool suites that has end-to-end features. Whatever role you are playing, whatever personality you are trying to address, it has that feature. For example, CA Service Virtualization goes hand-in-hand with TDM. In addition, TDM has automation. CA has most features that complement the whole testing cycle.

CA TDM has open APIs. If we are going to use a set of Excel data and pull out the feed and we want to help the Service Virtualization by providing a set of dynamic responses to the request that that service layer is getting, how do we do that? We can use the API layer at the moment the whole process stabilizes, after three months or so. In other tools, that takes longer. This open API capability is good in CA TDM.

There are multiple things which can be improved in CA TDM. It has a feature called TDM Portal, where testers can find test data by themselves, based on multiple models. They can reserve the data so that it belongs to one group or individual. Obviously, that data is not available to anybody else. Without this tool, if somebody goes through the back end, via SQL and pulls that data, you can't do anything. But through the Portal, if somebody reserves the data, it's his. This feature is for one environment. But if a different group of testers wanted that data for a different environment, they can't use it via CA TDM. That feature doesn't exist. You have to build a portal or you have to bridge the two environments. That is a big challenge.

Three to five years.

You can envision TDM happening at three layers. One is the application layer, the second is a cluster layer, and the third is an end-to-end layer. The data required for the first level and the second level are pretty different. You can't use first-level data in the second level. And the data required for the third, for end-to-end testing, is very different from the first two layers.

So when we look at scalability, we have to see how we are creating the "journey" from one layer to another. For example, if we are working in the customer area and then we jump to payments, we have to see what the common things are that we can scale and what areas we have not tested and address them.

The initial setup is always complex. I have been working in testing environments for the last 10 or eleven years. From what I have seen, most companies lack the basic building blocks for testing.

Suppose I have a system, and that system gives data to system Y, and Y gives data to system Z. Nobody has a clue how that data gets there for testing, because that end-to-end testing has never happened. We cannot give someone data which will be rejected from system Z. We have to give him data which will pass across all the systems. And that means we have to understand the mapping file behind it. However, the mapping file is often not there so we have to create it.

We have to talk about the various models, are they logical or physical? Somebody may have created a set of logical data models 20 years back but it is not usable now. We have to work with the tool to create that set of data.

We also have to consider the scheme of values. If it's IMS, that is different from RDBMS. We have to find out what segment has more data, which segment is completing and which segment is giving data to systems. When we talk to the people who are working on that data set, one that is 20 years old or 30 years old, 90 percent of the time they don't have a clue. They are working with various tools but they don't have a clue how it is happening.

So there are always multiple challenges at the start. But then we do due diligence for six or eight weeks and it clears up all the cobwebs: What is there, what is not there, and the roadmap. That puts a foot forward so we cna say, "Okay, this is how we should move and this is what we should be able to achieve in a given timeline."

The initial deployment will take a minimum of three to four weeks.

The second step is a PoC or a pilot to run with a set of use cases.

Apart from CA TDM, I've used IBM InfoSphere Optim, which was number-one TDM tool for quite some time, and I've used Delphix. Now, a couple of more tools have come into the market, like K2View. At one point in time, about two years back, CA TDM was only tool that could do synthetic data.

CA TDM and Optim have different ways of working. CA TDM vs Optim has the major advantage of synthetic data creation. No tool was able to do that. Only in the last two years has IBM Optim come up with synthetic data capabilities, but what they are doing is creating a superset. If you have sample data, it will create a superset of that data. That is not the case with CA, as well as other tools.

There are multiple sites that also create synthetic data, but the major challenge comes into the play once you need to put that data back into the database.

There are, let's say, five market-standard tools you can choose from. If you choose CA TDM, you need to bring out all your questions for your PoC journey. You have four weeks to get answers to whatever questions you have. There is a set of experts at CA and partners have expertise as well. Both will be able to answer your questions.

Next, you need to supply a roadmap. For example, "I need X, Y, and Z to be tackled first." And the roadmap that comes out of the due diligence needs to be followed word-for-word. So proper planning is essential.

There are three teams which are at the base of your TDM journey. One team is a central data commandment team, one is a federated team, and the third is for creating small tools that you might require at that point in time. To start, you need three to four people. But we have gotten into all types of data: Big Data, RPA, performance; etc. Wherever data is needed, our team is providing the data. In a bank, for example, where I did two rounds of due diligence, one lasting eight weeks and the other, three years later, lasting six weeks, we even implemented bots. When we started there the team was 50. Even though we automated the whole thing, more than what anyone might have even imagined, the team is still 40-plus.

We use it for enterprise-level solutions.

While we are testing, when there is data that's not accessible or we need to quickly generate data, TDM comes in handy. We can create batch files as well. We can write scripts which automatically create data and we can integrate it with the automatic Dev scripts. This feature is very good. We have used these kinds of features for smaller solutions, although not at a very large scale, because of the complexities involved in the enterprise-level data.

The entire tool is good and I like the synthetic data generation, that's really good. It's valuable because you don't have Prod data so, instead, you can create multiple copies of similar data. You can write rules and create permutations and combinations according to your needs. Or you can take a snippet of the Prod data and replicate it. All of that is really helpful.

The UI could be improved and I see they are going to web-based. That's still in progress but I really hope all of that happens pretty soon and the entire UI gets migrated from the desktop to web-based.

The integration with various utilities is also really important. That still has to happen. That's a major area for improvement.

Three to five years.

It has become pretty stable over the past couple of years. When it started it had issues but right now, I don't think there are any major issues.

It's a tool so scalability depends on you use it. Scalability is pretty relative. It provides a lot of features and it's up to you how you utilize them. It's pretty scalable. It has automated features and I don't think there is any other tool in the market which provides such a level of automated solutions. The demand in the industry, with respect to enterprise solutions, is pretty complex and CA TDM is pretty good. It is scalable but not to the extent that a foolproof enterprise solution can be provided using this tool.

Support is pretty good. We get answers to problems most of the time and, if we don't, they get in touch with the tech team and we get on a call with them and we figure it out together.

The setup is of medium complexity. It's been a long time since I set it up. I have had it on my laptop for a long time, but this is what I remember. The configuration does not happen by clicking a button and then you can start using it. It has its own steps. You register the depository, etc., to get into the tool. The installation itself is fine, but configuring it and getting it ready to use could be better.

The time it takes depends. At times I have installed it in a couple of hours, but if I get stuck... I don't remember all the issues I have faced, it's been a while, but I do remember that I had issues.

Every project and every implementation have to have a strategy. There are a few basic things that we look for and we follow a checklist to see if the project is feasible for TDM or model-based testing or some other solution. As far as implementation strategies are concerned, they are very specific to the client and the kind of ecosystem the client has. The basic strategy would be to not go "big-bang," to start with the basic and medium-complexity tests to show the ROI, and then roll it out one-by-one across the enterprise. But there can be a lot of nuances in the strategy document.

In terms of the number of staff needed for deployment, to start with we would not need more than two people to perform the PoC and do due diligence on the requirements. We would need two to three people in a bigger organization and one person for a smaller solution It depends on the requirements and on how much work is involved. To maintain it, one person should be enough.

Nothing happens quickly. It requires six to eight months to show a return on investment, minimum. You are going to invest in the tool, then you are going to do training, then you are going to do roll it out. And organizations have different project teams. They have to change the mindset. That process takes time. It's good when it happens. Once you have the system in place, after something like a year-and-a-half you'll see a good enough return on investment. That's the strategy we have. But we have to convince the client so that they understand this approach.

The problem is that the cost of this tool is pretty high. Even if an organization likes the tool, at times it becomes difficult for us to sell the license. CA provides licenses for different utilities like masking but even if you break it up, the pricing is still high.

IBM Optim is one competitor as is Informatica. IBM has come up with the synthetic data feature in the last years although I don't recall the name of the tool they acquired. Informatica vs IBM Optim does not provide synthetic data yet.

Normal TDM features, like masking, are provided by both IBM and Informatica. People usually go for Informatica because it is easier for them to adopt the tool. Informatica is a very popular tool on the market for basic TDM-related activities and it's not as costly as TDM.

I have been acquainted with this tool for three-and-a-half years and, since it was acquired by CA, we have worked pretty closely with CA to give feedback on what is expected out of the tool. We have worked very closely with the developers, as well, to enhance the tool.

We have two or three clients using it.

We use it for data generation, for performance testing, and other test cases. We also use data masking and data profiling for functional testing. Data masking is one of the important aims in our procurement of this tool because we have some sensitive data in production. We have to mask it to use it in a testing environment. Our real concern is masking and we are learning about this subject.

CA TDM is valuable for us because we use relational databases where it's problematic to sustain the relationships, foreign keys, and indexes. TDM obeys all the relationships and does the masking and data generation according to those relationships. 

Also, the testing team is using TDM to write the rules. Using this tool, our knowledge of data discovery skills has increased. That is an advance for our company.

In terms of performance testing, before TDM, preparing the data and data generation took a week for 20,000 sets of data. Now, with TDM, it takes just one day, which is great. We haven't had much experience with masking yet, we are in the adaptation phase, but data generation has increased our performance by about 60 percent.

The tool has strong data generation functions. When we needed special function that is not in the list, the support team has generated these functions and added with patches in a limited time frame.

For performance testing, we needed large amounts of data. The effort for data generation for this purpose has also decreased specifically.

Depending on security politicies and regulations we have to obey, we needed masked production data for testing. With the help of this tool, considering data integrity we can mask the data in a variety of ways (like shuffling, using seed list, using functions etc.)

There are different modules for masking. There is a portal and there is a standalone application as well. The standalone application is more old-fashioned. When you write rules on this old-fashioned interface, because it has more complex functions available for use, you can't migrate them to the portal. 

We also have some security policies in our company that needed adaptation. For example, the people writing the rules would see all the production data, which is a large problem for us. It would be helpful if there was an increase in the ability to apply security policies.

The tool is stable. This was one of the reasons that we chose it. We haven't had an issue with any unknown problems or issues, so it has paid off.

Scalability is a matter of how you use your systems. Our requirements required using it for MS SQL Server, Db2, and LUW Db2. We scaled the tool with all the databases we have, so it's scalable.

Technical support is okay. We haven't had many issues lately, but we had a bug at the proof of concept stage and they solved it.

We did not have a previous solution.

The initial setup was straightforward. One of CA's consultants came to our company and did the installation in about two days. We use mainframes here, and mainframes are very complex. Still, the consultant did it in two days.

We worked with a CA consultant to do all the adaptation over the course of about two months. We were happy with him.

Part of the licensing is dependent on whether you want to use the portal. It's based on floating users. The other part is dependent on what type of system you are using. We are using mainframe, so we paid good money for a mainframe license. It's okay because, for us, the main work of this tool is on those systems. The mainframe is a critical system, so the cost is okay.

We looked at IBM Optim and Informatica TDM.

It's important to know the requirements of your system, for example, the security policies you have to observe. The requirements may include a concern about relational or other database systems. You have to know your systems. Depending on your system, consider using one or more consultants, because we had a problem just using one. Also, compare all the tools by doing proofs of concept. That's important.

We have been using it for three months, but before that we also did a proof of concept in stages for about a year.

Regarding future use, we plan to use it in automation testing with content integration tools. Before running the automated tests, we will prepare our generated data with TDM. We also have a future plan for storage virtualization and use of Docker applications. It is possible that for Docker we would also use the TDM rule set. I want to believe it's scalable.

We have five testers using it to write rules. We also have 20 business analysts using and running these rules. In terms of maintenance, two developers would be enough. Our consultant coached our developers regarding our requirements. A testing engineer would also be okay for maintenance.

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 relationship between cables needs to be added.

A lot of research, data analysis, and work needs to be done on the source system in the tool which requires a data expert. This tool definitely requires a senior person to work on this issue, as it might be a challenge for a tester.

There have been major upgrades in the last couple of years. There was a stability issue, when I started to work on it. After we upgraded to 4.0, a lot of these problems were solved and there were advanced features, as well. With 4.0, the product is now really stable, and working fine.

The stability issue was that we used to log in and see errors. We had to work around them. For example, we would log through the admin, then run some queries, and log back in again. After the upgrade was done, everything now appears to be fine. 

When we publish a lot data into the target, sometimes it is not able to handle it. What we do normally is we create the data margins of the source and we try to publish short sets of data into the target. Many times the publish will fail. I think the reason is because of huge sets of data that we publish. I am not sure if it is the tool issue, but I have seen this a lot of times before, where it is not able to publish a huge set of data (thousands and thousands of sets of data). With a few sets, it works. When we try to publish a lot of data, every time there is a publish error. Though, I have not tried it lately, we have seen this before.

Tech support for TDM is fine. I have logged maybe one or two issues for TDM. Most of our issues are for App Test. 

We did not use another solution before TDM.

The setup was pretty straightforward.

Know all the data requirements before buying this product. There are a lot of features for this tool, which may or may not be useful to a particular company. Make sure of what your requirements for your data are. 

I would certainly recommend this product, because of the vast variety of data it provides for testing and its different features, like subsetting and cloning. I have heard of products which can do cloning and similar stuff, but there are many additional features in this tool, which is very useful for the testing and finding defects. 

We found we mostly use one or two features, so we need to be very clear on what we need before choosing a product. Test Data Manager is good, and there are a lot of advantages that you get from using the tool, especially for testing and incubating with the App Test, which is something that we use a lot. 

Test Data Management solution for our DevOps model, which is very useful. Data privatization (GDPR enable), synthetic test data generation, and test data provisioning are its main interesting features.

On-time production and real time data for DevOps testing environment and CI/CD pipeline.

Data privatization, provisioning, and generation for DevOps and CI/CD pipeline. 

• More features on Big Data environment data privatization. 
• Synthetic data generation on domain specific. 
• SAP test data generation for SAP testing.