Self Service Introduction
In this lesson, you will be introduced to the 5 GenRocket self service components and learn how they can be used to provide on-demand, real-time data for your Agile sprints.
Centralized Self Service and Distributed Self Service
In an agile world, which most organizations are going to, there is a real need for speed and need for quality.
Centralized Self Service
We think of the traditional Test Data Management approach where we copy a production database and mask the copied data.
Then we have a Test Data Management Team that is going and hunting in that production database for useful data. Often, that data is placed within a test data portal for retrieval by an engineer or quality team.
This is defined as self service, but really it is very much centralized self service and not true self service.
Distributed Self Service
In the GenRocket approach, it is very much more of a distributed self service approach where a QA or Engineering team can use the GenRocket tool to design the test data that they need. GenRocket is providing the graphics, ease of use, and automations that is needed to make this easy.
Yes, there can be a centralized team helping with that as well, but more of the burden, more of the usability shifts to the team themselves.
Of course, there is huge cost savings advantages over that model and real speed advantages, because in an Agile environment, where we are running a two-week sprint, the data is needed very quickly and in this GenRocket Model, that is very possible.
5 Self Service Components
GenRocket’s 5 Self Service Components are used to control and condition generated test data and work together to do so.
For example, a Test Data Case (or G-Case) can contain Test Data Rules (G-Rules) and/or a Test Data Queries (G-Queries). This allows real data to be queried and included in the generated test data. It also makes it possible to apply rules that condition the generated test data.
Cases can then be combined into Stories and even further, if we want to fully populate a database, an application, or UA test, we can even run a Test Data Epic, which is a combination of Test Data Stories.
Test Data Cases in an Agile Sprint
If you start to visualize this, you think of your Agile Sprint where you are defining your User Stories, you are defining your Test Stories, and of course you need test data.
So that is the moment where you bring in your needed test data. This is often as simple as saying “Ok, this is the Test Data Case I need.” You call it and its going to deliver on-demand, real-time data into your Test Case at the time it is needed.
Sometimes, that is all you need. In some instances, you might need to run a story or a full epic. The concept is that the data is being delivered just the way you need it.
Below, is a visual representation on how Test Data Configurations with the 5 Self Service Components can be used for different testing needs.