Take your SAP test data to the next level

Good afternoon to you all. My name is Berg van der Stowen. I'm a sales director at Socied Megalon, within OT engineering and testing. And, today, a very warm welcome to you all in this session, with APUs Labs and Sociede. And, it is about bringing your test data within SAP to a next level. And today, we have Paul and the pain in the session, and they will take you towards the point where, where we're gonna inform you about all that we will have in the white paper that we will bring out. After the session, we will ask you to, or we will answer your questions. So if you do have questions, please put them in the chat and I can remind you that you will also or you will, receive the white paper. And, of course, if there are any questions popping up later, we are more than happy to help you. For now, the floor is yours, Paul and Quebec. Thank you, Barry. Thank you, Barry. I'm hoping, I'm very good audible for everyone. Welcome, my name is Pepijn Papp, I'm the Associate Manager Expert of SAP Testing within SoGiti. A lot of experience with SAP projects, globally, implementations, green fields, upgrades, rollouts, you name it. I think I've seen it. And yeah. But it's always a big challenge and that's also the topic today is test data, the availability of test data, SAP test data, test data in all end to end chain, for a complete end to end processes. Can it be more effective? Can it be more efficient? So today, we will have a natural conversation with Paul from EPUSE. And hopefully, we'll we can answer a lot of your questions. And our, yeah, main input is actually the, the white paper, which you will get after this, after this webinar. So we will talk a little bit about that, and we will also talk about a lot, actually about test data and test data in particular related to SAP. So, Paul, a warm welcome from Sociedad Netherlands. How are you doing today? I'm very well. Thank you, Pippe. It's great to be here. Thanks for inviting us. Yep. Yeah. Before really deep diving into, know, all the details, tell a little bit about you and your experience with SAP and SAP test data management. Sure. So I'm based in the UK, based in Manchester, and I've been working with SAP for just over twenty years and eighteen of those years with FPUs. And I've spent the majority of my time working in and around a product called DataSync Manager. So I'm the channel product owner for DataSync Manager, but I've been involved in numerous projects leveraging the technology to help organizations in a wide variety of industries try to solve the test data management challenge. Yeah. Yeah. That's very nice. I think also a lot of experience. So together with my experience from, not from the functional side and with your experience from the technical and the tool side, I think we can answer a lot of questions here. So when we look into, data management, how do you see that test data management can help you, particularly with SAP projects, to make the shift left approach? So there's kind of two ways in which we've traditionally enabled people to provision data for SAP for testing. The first approach that we started with is what I would refer to as a data on demand approach. And that piece of the technology is now referred to as object sync. And that allows the people who will actually use the data to go and pick out just the part that they want and to copy that in isolation. And the way that the technology is designed is to allow them to do that without impacting other users of the system. So it's a very, very specific technology, but it requires somebody with good knowledge of what it is they're actually looking to test and what data supports those processes. To the other side, we have a technology that we refer to as client sync that actually allows you to build a entire client, or in some cases, you would be replacing the system as well, and there's tooling for that. But really refreshing a test client or system based on the production data, but with a time slice or what we also refer to as an enterprise slice is another option. So if you think about the traditional approach that people use for creating test data, often it is a system copy type approach. And a lot of the data that is being copied back will simply sit in that test system completely untouched. Any transactions that are more than a year old, master data that's now, been marked for deletion, it sits there until the same time next year. It gets replaced with itself again, and then it sits there for another year. So with client sync, we actually use the knowledge of the object model that we have in order to allow you to build a test client that looks like production and behaves like production, but only has, say, three months of transactional history, a most recent three months. But because we built on top of the knowledge of the SAP data model, we can also filter the data that we're bringing back from production based on an enterprise structure choice. So you can actually create a client that is, specific to a particular company code or set of company codes, and the technology will go and find what's the related plants, purchase orgs, sales orgs, and so on, and it will filter the data. So in terms of allowing people to shift left and do that testing left, you can use the technology to make an additional testing client in a development system, or you can use the technology to bring down specific sets of data from production. So particular materials or sales orders, accounting documents into that development system. And even if you are moving your data into, an additional client in that development system, you can move your configuration changes between clients of the development system. Yeah. So it's not only transactional data. It's also the configurational data and the master data, maybe historical data as well. It's all based on your you know, the scope, the time slice, the three months, or the particular, sales order or company code. Exactly. So you do essentially take this kind of small snapshot of production and build it as an additional client in the development system, and then you could move your changes for the project into that client and do your testing there on a very representative set of data. And we've seen them Looking at speed and agility, then actually, this is, no. A press on the button on demand and, no, we are within five minutes, I could have test data available to test in my test environment. Yeah. And it could even be that you're creating a test client specifically for a particular project with Client Sync. So you know that this project is only going to impact a particular company code. And, therefore, why do we need data for other company codes in the test client? There's also the option there to say, I only want the master data in customizing. So if you were doing a project to build out a new distribution center, you may realize that actually existing transactions from the production system aren't relevant for the distribution center because it doesn't have any transactions yet. It's still being built. So in that situation, you can build a very, very lean client with just master data and customizing limited to the company code that will be affected, then do the configuration for the distribution center and start doing initial tests, creating transactions for that new distribution center. Yeah. Based on this story, a lot of questions pop up at the moment, because no. I think it's very interesting what you say. You can make the time and slice and, especially specifically, maybe the supply chain or maybe for finance. But then is this tool suitable for everyone? So will everyone use this tool, or do we have a specific stakeholder within the project or maybe within your organization or support organization who will execute this for because we, as a tester, and especially me as a test manager and my team with the test executors, they using the test data, or are they also generating this copy from production or time slice? So it's those two, distinct users, I would say. The client sync where you're creating or refreshing an existing client is typically the domain of the Basis team. So whoever was doing system copies previously, they will generally hold on to that capability. Not always the case. Some organizations do have, separate teams that manage test data and will give that access. But for the most part, it's the more technical teams, and it's designed so that they don't need to know the underlying data model. They don't need to know the table structures. They need to make choices that could affect the consistency of the client. That side of the product is entirely, catering for someone without that knowledge. The other side is typically the object sync side. The data on demand side is what is great to put in the hands of the testers to be able to say, you can go pick a specific set of materials as they currently are in production or in a preproduction, bring them into your testing situation, run your tests, and then either you might decide you want to reset the same data and run some different tests, or you may decide you want to slightly adapt your test set. Maybe you've realized from the testing there's an area of testing that you want to go into that actually needs something else, something you haven't originally thought of. So it's really catering for those two different types of user. This doesn't also mean that, for example, for HR and finance and supply chain, I need three different, basis team members to, to operate this because it's specific knowledge for ADR. It's also specific knowledge to get all the objects from finance. So the way that it works is actually by including what we call integration points. So when it comes to the functional user, if they go and they know that they want to test on, let's say, some business partners, it actually has in what we call integration points to related data. So if those business partners that they've selected, maybe they have a list of business partners. If some of those business partners are, for vendor masters, it will pick up the vendor master. If some are for customers, it will pick up the customer. If some are for employees, it will pick up the employees. So it's taking care of those relationships that exist within SAP Mhmm. That could cause problems in the testing if the user isn't aware. But there is still that bit of functional knowledge and understanding that I would expect testers typically have anyway. And whilst they can focus on their domain, the domain they're testing, technology is giving them the potentially related data that they might not be aware of that's happening in the background. My experience with this is, I've used the tool maybe two times in my life in a previous project on the HR module, and I was trained in that. I was still an old fresh, young professional many ages ago. But there, I was confronted with, a lot and the tool probably is evolved way better right now. But at that moment, I was a little bit lost with all the, options I had with technical objects where I had to select or not. I didn't know what kind of impact that had. So on a typical business user, they know the functional process, but the technical side, and that's, you know, which stakeholder will do what. And I think that's evolved right now, but, I think that's still a challenge. Or isn't it? It is a challenge just because the underlying domain is so complex. I mean, a SAP system has so many tables involved. You know, the client dependent tables are over sixty five thousand. The data model is incredibly complex. So the mappings that we have, even for what looks like relatively simple objects, there can be twenty or thirty or fifty plus different tables that are actually making up the data. And the links that we can have to other areas is really quite profound in what it can impact the testing, with. So we have that, that integration point technology that kinda pre prompts the things that we think might make sense. But, of course, it also will depend on a particular system and also the industry that the organization is working in. So as well as us providing the integration points that we think should be on by default, we also allow what we call templates. So if you have a particular testing scenario where there is a set of data that you want to use and you typically want to bring the latest version of that data down from production, you can create a template where you can change what those default selections are. So if, for example, we decided that we didn't think, the vendor master should be on by default with the business partner, but the process that you're testing will actually vendor in the background. You can create a template for provisioning data for that process where you include the vendor in your selections. And then the only thing you need to do is to update it with the latest time slice, for example. So we, you run it daily or maybe once in a quarter. Then you get the latest quarter, and you get the data refresh. You can do that. So we do have organizations that have certain key sets of data that they want to refresh every week. So it's an automatic job. It just runs in the background and updates that data. But keep in mind, this difference between client sync where you are replacing an existing client potentially or creating a completely new client where everything is coming in. So you've got customizing, you've got master data, and it's gonna wipe out what's already there that is the basis type user. And that's where the time slicing would typically come in. On the data on demand side, you're going in and specifically saying, I want these sales orders, and you can enter the keys. You can have a list of sales order numbers, or you could pick a posting date. I want all sales orders created between this date and this date. But it's generally for much smaller samples of data that are allowing you either to test with that data or the actual process of it copying that data is testing your system in some way in itself. And that's particularly relevant when it comes to transactional data. Yeah. Yeah. But it's also interesting. So we could say, if we take this slice or know the dataset from the version, we put it in the test environment, normally then, is it erasing the old data and replacing it? Or is it on top of it? So my test database will still grow over time? Nowadays also from sustainable, view, will the data database grow, or will we keep it limited only to the three months or whatever time flight we use? So with the object sync side, it's appending the data to what's there, but it could be replacing. So if you're copying a set of materials, it will replace the same material numbers that are there. So the master data is typically replacing the transactions. It will create new transactions on top. On the client sync side, it is a complete replacement. It will clear out what is already there, and it will then bring in the data that you've chosen. And that's actually, I would say, a necessity. So we do we often have people ask the question, can they have a test system that has three months of data, three months of transactions, and it always just keeps three months. So as a new month comes in, it rolls along and takes last month out. The problem with that is you essentially have a test system that has a life of its own, and, of course, your production system has a life of its own. So if you imagine, if you set up a test system, maybe with data for the first three months of the year, so January, February, March. In March, in that set of data that we've copied, you might have a sales order. And in production, that sales order actually gets canceled in April. So after we've done the copy, that sales order, forget it, new order created, new process started. In your test system, someone might process that open order all the way through to cash, and it's updated your stop levels. It's updated your controlling analysis, everything else. So if someone then said at the end of April, we want to bring down the data for April and maybe remove the data from January in our test system, what do we do with that sales order? How would we be able to know where to put the stock back on the shelf? How would we, update profitability analysis and so on? And the fact is you would have to choose. Only one of those sales orders can win and go forward. And that's why we don't allow that incremental rolling of data because it will create inconsistencies. And, you know, the last thing you want is a project being delayed because people can't effectively test or there's a defect that they don't get to the bottom of. And when they actually realize the cause, it was the way they provisioned the test data. That's the reason to find you. And an interesting follow-up question on this is, of course, test automation. Test automation is typically using, you know, a standard set of data to be used? And if we have a rolling forward of this data, how do you see that work? Or what kind of solutions are there? So you can look at test automation and having a kind of static set of data. We've talked about bringing data from production all the time, but you could also create data that you want to use for a particular test and then export it to a file and basically reimport it each time to set that test, to reset that test. But my view is because systems are changing more quickly, the rate of change is undoubtedly going up. The innovation that's going on is undoubtedly going up. I would argue that rather than trying to look at retaining a static data and replacing that static data, you should be looking to try and automate the process of selecting the data for testing. So looking at what characteristics do we need. So if it's a, utilities industry, do we need people with both a gas account and an electric account? Do we need people who owe more than two hundred euros on their bill? Work out the criteria for your test and then actually dynamically select somebody in production that meets that requirement at the time you want to do the test. So essentially linking characteristics to the test catalog to be able to select and trigger the copying of data down. Yeah. So thinking upfront, creating a test strategy, that's always now the enabler to do successful test automation, but also now test data, transfer. Absolutely, I agree. And another challenge, what I actually see is we mentioned a couple of times now, we copy production data. But does this solution also work if you don't have a production, environment? So for example, we do a greenfield implementation. We may be we do the upgrade tool to s four, and we don't have a real life production environment yet. What are the options over there? Yeah. Absolutely. So if you've created a set of data or you've done some additional data loading in your project and you want to move that test data from one system to another or you want to create an additional client for testing on a system, that can absolutely be the source. It's normally when the project is live and the system is more mature, people tend to then take production as the, as the starting point for test data in the SAP world. So in the early phases before it goes live, absolutely, you could be moving data even from a development system into a QA system as you go through that process of building out the landscape. But then we have the challenge with data consistency, isn't it? So of course, I think when you say the, production data is way more mature and, evolved, if we copy, development data, inconsistencies or there are flaws in there or, maybe there are not, generic policies to create your data. There are naming conventions, just give an easy ones. No, teasing some crap, things like that. But if you copy that, that is still a challenge. Absolutely. 00:22:31,045 -6ds3wtazto,{""english_name"":""English""