As you've seen in recent posts here, most of our discussions around Service Virtualization center around the lack of availability of systems, environments, etc. -– i.e. the "Over-utilized" problem. A Virtual Service Environment (VSE) is a solution that helps eliminate these constraints and therefore can dramatically reduce the time to market, and/or infrastructure costs. Also, once these constraints are removed, testing (functional and performance) can be done much earlier, and therefore greatly improve the quality of the released software.
We also talk about the use of VSE to enable parallel development. Being able to simulate dependencies that don't exist, and allowing testing and development activities to happen in parallel. Again, this can greatly reduce time to market, costs and improve overall quality.
However, there is a value of VSE that we don't talk as much about. An issue that has applicability in almost every enterprise environment, is one related to Test Data challenges. Let me explain.
There are at least 4 Test Data related challenges that Service Virtualization helps solve or assuage:- Data Scenarios are difficult to create. In the modern application, data required to support scenarios will have to be synchronized across multiple systems. Not only is that highly time consuming, but due to access constraints, or skill constraints, or various other reasons, creating and synchronizing that data could become a near impossible task. This may either elongate the testing cycle or, even worse, encourage the testers to reduce the number of scenarios that the system is tested under.
- Data is Volatile. This is partially related to (1). In a lot of cases, the systems being tested go directly against systems that are either in-production or are being shared by other teams. This causes the data to be volatile (changing randomly and often). This makes the testing process impossible, because any results of the testing against these volatile systems cannot be validated.
- Data needs to be Desensitized. In a lot of cases, data challenges could be reduced by using production data. However, production data may have sensitive information like credit card numbers, social security numbers, etc. Not only is this a problem for the direct employees, the challenge is greatly magnified when offshore or outsourcing contractors are used.
- Data should not impact production systems. Some test scenarios result in transactions being created that can mess up a production system. For instance, if a test scenario requires a new order getting placed, the order once generated will have to be traced and deleted from the production systems. This is a major pain for the testers, and for the operations personnel.
As you can see from the above examples, Test Data Management challenges represent a huge constraint on the productivity of almost any enterprise software development project of significant scope.
Here's how we have found customers can approach these challenges using Service Virtualization:
- Reduce the number of points that need to be synchronized, by capturing relevant transactions, chaining them together into scenarios, and creating a virtual model that can be manipulated without programming.
- Stabilize the data so that the test results are actually valid, for instance, maintaining the relevance of variables like changing dates and varying types of customer data entry.
- Desensitize the data so it does not violate security and privacy policies.
- Substitute a Virtual Service for the production system, so there is no need to impact the critical live system of record to retrieve data. This can be done alongside ALM tools and Service Registries for SOA - essentially routing a known test data request to the VSE instead of the real thing.
Comments