How many times must a test case be run over and again because the data does not work for the test case? Some other times, the test case executed correctly, but when the code gets into production it crashes because of an unexpected “data behavior” to later discover that the set of data used to test that apps’ slice was not complete?
Having relational data is as important as having a well-defined set of test cases to have a successful test iteration. The whole idea of creating synthetic relational data is to simulate the same structure the data would have when using a subset of the production data removing all risks and efforts of doing so.
Creating relational synthetic data may sound like a complicated and painful task, and I must say that most of the times it is. The TDM team job is to replicate the basic rules on how the tool manage the data, and for that they will need to understand and replicate the business rules it will be following. In order to do so, the team needs the more information they can get, and most of the time teams do not have any documentation or knowledge about how the system works.
Now just because it is hard, it does not mean it is not worthy, like most things in life “If there is no pain, there is no gain”. The TDM team will have to suffer while they:
- Understand the database relations.
- Analyze the objects the system uses.
- Meet with the people that created/know the business rules (sometimes this people does not exist).
- Meet and work with the testing team to identify their needs.
However, when all that suffering comes to an end, they will have an almost perfect understanding of the system.
What will come after you have all this understanding? You will be able to create the data that is needed when it is needed and how it is needed.
What will happen when a peculiar scenario is requested? Since the team already knows the rules, they can create explicit data with almost 100% integrity meaning that you will be testing just what you need to test.
What about changes? Implementation can be more efficient since you will know which piece is affected each time.
However, this is all about relational data, why is it important? Think about a car, when a company is creating a new model even when they are working on different modules independently, they need to make sure that all of them fit in at the end. If the wheels are too big to fit the rear axle, even if the model is fantastic, it will not work. The same happens with an application; if all the parts do not communicate by the same structure the work will be worthless.
Think about “My Products Online Shop”, a company that has been in the online shopping business for a long time. A few years ago the IT team decided that all their website need a “full transformation” in order to stay on the top of the business. The IT team started with the project plan to know how they would split the job, they decided to create four modules: Registration, Sales, Catalogue, and Promotions.
This was a major development and testing project, they knew that more people were needed and that the integrity was crucial for success, a weekly meeting was proposed to collaborate and discuss any issue that may appear. For the first few months of the project, the meetings were held, but soon enough, they were cut out of schedule. This change made the teams work independently, each team focussed on their needs.
Each team had their set to run a testing phase that was independent of each other. Also, teams were so big that almost no one knew what the rest of the teams were working. The project came to the integration phase, and the significant issue appeared: most of the things each team had were not compatible between them. Each team had its structures, its test cases, and its data. If that was not enough trouble, no documentation was available, and the latest version of the components was not available.
Testing began even with all these problems and things that were working fine started to report defects: the Sales teams never took into account that the end user would need specific information when validating the registration process. The Catalogue team never thought of how the sales team was going to need to handle the information when an order was placed, just to mention some of the issues.
New data pools for testing were created, sometimes new subsets from production were easier to request, but the possibility of getting new delays was high. The worst scenario became real: the existing components had only been updated to work at the moment. Creating patches of the patches led to a painful maintenance path that generated more expenses, more work, worse documentation, & more time to market.
So, what if someone were in the middle helping them work “integrally”? When a TDM team comes to the picture, you can not only say that they are creating the testing data, they do more than that: They are in charge of maintaining the integrity on the requested data, they work as a mediator between what each team wants and how they want it.
Another way the TDM team will help is to keep track of the changes and maintain different data set versions available to test multiple phases, leaving the testing team solely focused on making sure that everything is working as it should. In the end, all teams will always have integrated data that will work in every way, the lack of integration, integrity and quantity will never be an issue again.
If you want to learn more about Test Data Management and how can it help your team, take a look to our webinar “Gain a Competitive Advantage with Test Data Management” and if you want to learn what tools can help you set relational synthetic data on an effective and efficient way please take a look to “Grid-tools Test Data Management Overview & Demo”
