Effective Data Management #3: Cutting the testing overhead

Emma Frame 22nd July 2019

In the first two instalments of this blog series about effective data management I introduced the Delphix data virtualisation and masking technologies and followed up with how Delphix delivers the right test data available on demand in a DevOps environment and practically eliminates idle wait time for developers and testers.

This time I will explore how using Delphix can reduce the testing workload and accelerate the route to live (RTL) for software.

Most organisations follow a prescribed route to live that might include the following test gates:

Unit:                                  usually performed by the developer on new and changed code

Integration:                     developer or tester verifying the interfaces of the changed code

System:                            testing of the change in a wider system context

Regression:                      to ensure no inadvertent changes have been introduced

User Acceptance:          to sign off against the business requirements

Pre-production:              to sign off against operational requirements (operational acceptance)

The purpose of testing, regardless of the stage, is to ensure the quality of the change as it progresses along the RTL. Defects can be found at any of these stages and will trigger sending the code back down the RTL for fixing and retesting. It is self-evident, but the longer it takes to identify a defect, the later work starts to fix it and it is often more complicated to fix because you have to be sure not to break anything else that has already been successfully tested and the whole testing cycle has to be repeated.

The result is that the later defects are found along the RTL the more expensive they are to fix. It is also common to find more defects in the middle and later stages of the testing cycle than in the earlier stages.

We have seen how easy and quick it is to provision a full-sized virtual copy of production data with Delphix. While this saves developers and testers from unproductive wait time, they also get quick access to high quality up to date data, improving the quality of the testing and so identifying defects much earlier in the test cycle.

This is referred to as the Shift Left effect as the defect distribution curve is shifted to the left.

Using Delphix, testers and developers can create a bookmark (or checkpoint) in their virtual data and share it with other users who can then open their own copy of the virtual data.

Let me explain further. Imagine that as you are testing a change and you hit a defect. You bookmark your copy of the data at that time, notify the development or support team, and share the bookmark with them. They can then open their own copy of the data at exactly the right point. This saves time because they do not need to recreate any of the data to trigger the defect and so can identify the fix much more quickly.  And, because the developer is working on his own virtual copy, you can carry on testing in your independent copy.  When the developer eventually promotes the fix back for testing, you can quickly rewind your virtual copy of data back to the bookmark to verify that the defect is resolved.

In summary, using Delphix to provision high quality data at each stage along the RTL means:

  • Less wait time between test cycles
  • Higher quality, more effective testing with production-like data through the RTL
  • Earlier testing with production-like data uncovers bugs more quickly
  • Defects addressed earlier because they have “shifted left
  • Defects resolved more quickly because data points (bookmarks) can be shared
  • Fewer defects present in later testing phases because they have already been resolved

The net result is earlier and speedier resolution of defects with a reduction in testing and re-testing along the RTL.

Next time

I’m sure that you will have spotted a major flaw in that cunning plan to provision copies of real production data to use in test and will be asking, “But what about the GDPR and other data protection requirements?”. You are quite right to ask but hold that thought and next month I’ll explain how you can handle that using Delphix.

By Chris Glynn, Principal Consultant

Found this interesting? Why not share it: