Skip navigation
All Places > DevTest Community > Blog > 2014 > July

In our last video, Data Driven Virtual Services and Tests using Excel., Prasad Kona (konpr06 ) and I explored using Microsoft Excel as a data source for both virtual services and tests In  this short video, we discuss using CA Data Finder to build synthetic data and assist Virtual Services to behave as production services AND comply with regulations, customer privacy, and brand promise by leveraging synthetic data.



CA Data Finder is the key to helping build this clean and valid data; it provides hundred's of data scenarios to help build desensitized data and can create large volumes of data for our tests and virtual services.  In this example we leveraged only a very small portion of Data Finder's capability to create a rich data set of production-like data.  We removed sensitive content from production data, anonymized customer names and their associated physical mailing addresses (while maintaining valid State/Zipcode/City relationships) as well as creating Bank Card numbers with brand distribution (Amex, Mastercard, and Visa cards in equal distribution).  We also added credit cards to customer accounts in a random pattern of between one and three cards per customer. These rich data features; when brought to virtual services, can help construct Sandbox environments or services to validate complex data specific scenarios.

Please feel free to comment and give feedback on how this feature might assist your efforts, as always we are interested in how to make CA Service Virtualization and CA Application Test as valuable as possible for your teams.

Getting to know Stefana Muller



Title: Sr. Principal Product Manager, CA Service Virtualization


Based out of:  Islandia, NY


Former Job: Sr. Principal Product Manager, CA AppLogic


What do you enjoy about your work Talking with customers, hearing their stories about how they’ve used our product to help them deliver results. I also really enjoy working with my agile teams.  Continuously learning from the team architects and developers really appeals to the geek in me.


About your family: I am married to my amazing husband Jay for almost 9 years.  We have 2 daughters; Olivia is 6 and Ella is 2 and live in Babylon, NY on the south shore of Long Island.  We live across the street from a canal that leads out to the Great South Bay.  The whole family loves the water and this summer we learned how to stand-up paddleboard (SUP).  We have a 12.8ft board that can fit all 4 of us.


Favorite 3 movies of all time: The Matrix, Avatar & Pride and Prejudice though I’m currently forced to watch “Frozen” about 12 times a week.


Favorite book: “Pride and Prejudice” by Jane Austen and I also really enjoyed “The Tipping Point” by Malcolm Gladwell


Favorite hobbies:  Running, cycling, swimming, snorkeling, hiking, skiing, traveling, flying my drone, and now SUP.


Interesting fact about yourself: Running relaxes me so I run as often as I can.  To keep up with my training, I usually sign up for at least 2 races per month and the distance varies from 5k to 10k to ½ Marathons (13.1 miles).  I also completed in 2 sprint Triathlons and the challenging Tough Mudder with a team of folks from CA Technologies.  Some say having two young kids is enough training but I’m currently training for the NYC Marathon.  The Marathon will be my longest distance so far so I’m looking forward to it!

Control your destiny with Virtualization Driven Development (VDD).


VDD decouples teams in early development cycles by allowing changes in the virtual world, where team members are in full control of their destiny!


Background: This project (customer: anonymous) is in the middle of upgrading the end-user look & feel of the product by embracing some of the latest UI technologies. It’s a large modernization initiative involving many development teams at different layers in the architecture.

Real World: Since modern UI is the main driver, UI development team needed a lot of data scenarios (both quantity and quality) to develop and test for things like table pagination, scrolling and performance of the new portal. In this real world, developers send data requests and wait for business analysts and other teams to populate data in all different dependent systems. They wait and wait; only sometimes being lucky enough to get back a handful of useful data. The team lacks true control of their own deliverables (destiny); they are at the mercy of teams, systems and data. It’s not an easy problem to solve when you have to populate data across multiple systems of records, mainframes and also partner channels.


Virtual World: In the virtual world, instead of waiting for a real, end-to-end environment with questionable data, the UI development team decided to use virtual services in place of real systems. A team member updated virtual services for different permutations and combinations of data scenarios enabling the team to proceed with the

development and testing of the UI. As a result, the team successfully developed and tested pagination, scrolling, and even performance of the web pages without any delays. However, the fun just began - as the team made changes to the UI, they discovered changes needed in the backend services.

In the real world, they would have sent the newly discovered requirements to the backend team and waited for another sprint (or two) to integrate. However, in the virtual world, there is no such constraint. The UI development team still shared the discovered gap with the backend team, but didn’t wait for their deliverable. Another team member updated the service definitions (and associated data) in the virtual world, and the team proceeded further with the UI changes.


At the end of the sprint, they had a fully developed (and tested) UI and a reference implementation of the all the changes needed in the backend services inside the virtual world. This reference implementation was then passed to the backend services team to make sure they could validate their enhancements against these changes.


In the virtual world, the developer is king! The team gets what they want, when they want it, and how they want it, and deliver high-quality products on time. As for ruling the real world, that’s a topic for another day!

We are pleased to announce that the CA LISA 7.5.2 service pack release is generally available (GA) as of today, July 17, 2014.  This release includes both fixes to reported issues as well as enhancements to CA Service Virtualization, CA Application Test and CA Path Finder.



This service pack release contains fixes for various reported defects in addition to the following product enhancements:


The full release notes are available here:


The release is posted and available for download on our support site.  Below are instructions to download:

  1. Login to
  2. Select "Download Center" on the left navigation
  3. Type "LISA" in the product name field and the list of products you are licensed for related to LISA Service Virtualization, LISA Test and LISA Path Finder will display.  Select the relevant product
  4. Select the "Release" 7.52 and select "Go"
  5. The next page shows all downloads available for different OS installs - select the items relevant to your install.  For example, installing on Windows you would select:
    • For LISA Workstation and Server Console check off:
      • CA LISA 7.5.2 Installer Windows
      • CA LISA 7.5.2 Installer Third Party LGPL Library
      • CA LISA 7.5.2 JBoss Server with Examples
    • For Enterprise Dashboard check off:    
      • CA LISA 7.5.2 Enterprise Dashboard Windows
      • CA LISA 7.5.2 Enterprise Dashboard Third Party LGPL Library
  6. Once you check off the files you want to download, select “View Download Cart”
  7. On the next page, review the cart and then select “Checkout” to continue to the download page


For more information on this release as well as CA LISA 7.5.1, please join us on our CA LISA Community Webcast July 24, 2014 @ 11am ET | CA Communities

DevOps: It's a cultural change that starts with collaboration between people.


I bet you have heard this many times. The statement is absolutely true, but the DevOps journey doesn't necessarily begin from collaboration. In fact, there is no single recipe of success. That's the beauty of it -- everyone can make a difference from wherever they are. For any enterprise level transformation, Change Management and COE are critical concepts that can allow different business units and teams to benefit from "economies of scale" and "economies of learning". DevOps journey is no different, however, there are two interesting components that can make this journey easier and much more fun: "Standardization" and "Automation".


metaphor-car_lights_highway.jpgStandardization: Variety is the enemy of stability, and hence has an adversarial relationship with Operations. Variety means too many variables, and every variable in turn comes with its own set of dependencies. The less the variety, the fewer variables, resulting in a decrease in risk associated with fast paced changes coming down the conveyer belt.  Standardizing technology, architecture, tools, and processes has tremendous impact; it not only reduces risk but also paves the path for extreme Automation. Cloud Manager Platforms are a perfect example of how they use policy based pre-defined blueprints to establish standards across teams. They minimize the variables involved and help enforce a standard.


Automation: Most Analysts credit automation as the critical ingredient for DevOps success. It's clear that manual labor is not only slow, but also error prone because of the human capital involved. Quality issues and longer release cycles are common issues attached to manual labor. Automation has obvious benefits around improved quality and time to market. There’s a reason why you hear numerous “continuous” terms such as continuous build, continuous integration, continuous validation, and continuous delivery. Automation encapsulates every possible manual step, which can be automated - including automation of environment, releases, testing, code promotion, and even the feedback loop.


Double down on Automation: The problem with automation is that it still requires manual labor i.e. the process of automation itself is Manual. For example, manually automating test cases is also slow and error prone -- automating regression tests can take weeks and/or months and still results in questionable coverage. In this era of self-driving cars and fast-paced feedback loops, automating the automation is not a far-fetched goal. In fact, DevOps data mining uses the feedback look to auto-generate regression baselines, which not only shrinks months to weeks and days, but also keeps your test coverage close to 100% at all times.


Has Standardization or Automation enabled you to gain speed in your DevOps initiative? Have you tried doubling down on automation? Are you interested in telling others about it? You could have the opportunity to speak at CA World with a sponsored event registration!

Many organizations have all the data they need, but are seldom able to bring that data to bear in the right places and at the right time.  Businesses leverage Excel and csv files for many operations.  Prasad Kona (konpr06 ) and I discuss how to leverage data from Excel to enrich your tests and your virtual services.


For access to this powerful Extension for CA Service Virtualization and CA Application Test contact your PreSales/Sales team or Services team.

Do you have a need to validate your web based UI across multiple browsers? With LISA 7.5.1 we have

added the capability to drive execution of Selenium-based Web UI test scripts. One of the coolest feature of

Selenium WebDriver is the ability to run the same test script across multiple browsers. I created this short video

to demonstrate execution of Selenium-based tests not only across different browsers, but to show how to

leverage cloud-based testing platforms like Sauce Labs from within CA Application Test framework for your

Web UI testing needs.


Getting to Know Jeff De Meyer


jeff de meyer lisa.jpg

Title:  Senior Technologist, American Family Insurance


Based out of: Madison, Wisconsin


Former Job: Computer Technician, American Family Insurance


What do you enjoy about your work:  I enjoy finding unique solutions to unique challenges


About your family: I am married (16 years) and have one daughter (8.5 years).  My wife is from Dublin, GA.  I met her while taking a class in Program Design and Development at a technical college in Athens, GA.  I grew up in Wisconsin although I was born in Cass County Missouri and lived in Washington D.C. until I was 5 (my Dad was Marine).  I grew up in Stevens Point, WI and joined the Air Force upon graduating from High School.  The Air Force landed me in Georgia where, as stated above, I met my wife!


Favorite 3 movies of all time: Must I only pick 3?  I used to work at a movie theater and I see lots of movies even to this day!!  But, if I must stick to three: Forrest Gump, Jaws, Braveheart.


Favorite book: Believe it or not, I don't do a lot of reading (don't have time).  However, I have enjoyed reading  (more than once) "The Lion, the Witch, and the Wardrobe" by C.S Lewis.


Favorite hobbies: Fishing, bowling, cooking, watching movies.


Interesting fact about yourself: I was a meteorologist when I was in the US Air Force.  I spent four years doing that job.  The job took me to the Middle East during the Persian Gulf War (1990 - 1991).  I got to set up satellite communications for transmitting weather info in Saudi Arabia, Qatar, and the United Arab Emirates.


The attached photo is a family photo. From left to right is me, my daughter, Kayla, and my wife, Kristi.

It’s a completely inappropriate children’s book title, but fitting for enterprise software.


My code is my baby—I’ve conceived it. I’ve even nurtured it through sleepless nights. I want it to grow up and play nicely with others. When it runs around in my dev environment, it behaves perfectly. However, when it goes off to the testing environment, the trouble starts. I start hearing stories of misbehavior and admittedly, I’m quite incredulous. How can it be? I know every single line of this code and I’ve tested it locally; I know it works. Earlier in my career, I may have even cast a few askance looks at my QA colleagues who badmouthed my baby. I was in denial.


Over the years, with some resignation, I have faced the fact -- my baby behaves differently when it’s not home -- and this is BAD! But what can I do? It’s all grown up and out the door, hanging out in strange new environments with testing folks who are paid to give my code a hard time. As I struggled to recreate the testing environment and steps to reproduce the bugs, I was failing to deliver on stories that I had committed to at the beginning of the sprint.


Brace yourself... here is my pitch for a more pleasant and productive way to write software.


Step 1 - Ask your operations folks to attach a CA Path Finder agent to each application server in your staging environment.

Step 2 - Write and test, business as usual.

Step 3 - A business transaction failed or is reported slow in the test environment, a.k.a. bizarro world. No problem, open up the CA Path Finder web UI and lookup the failed transaction. Examine the details of each captured call and trace the details of the failed business transaction through all the tiers of the application. Use Path Finder to examine exceptions and to log messages both in the context of a business transaction path.

Step 4  Fix the bug, move on to other stories and finish the sprint strong!



You may be thinking -- sure this will work for some bugs, but what about mandelbugs and heisenbugs? True, we have a debugger for a reason: some bugs are tough and need heavy duty root cause analysis. There may not be enough details in the captured business transaction details to deduce the exact cause of the bug. With a few extra steps you can use Path Finder to generate a test that you can use to reproduce the bug in your code on your dev box. Your code depends on backend systems -- if these are not available, use Path Finder to generate virtual services to fill in for the unavailable backend systems. You have your app and the virtual services running, attach the debugger, run the test and debug as usual.

As developers we can’t anticipate and test every scenario our code will experience in the wild.  A more productive use of time is to precisely monitor how code behaves differently in other environments. With Path Finder, you can be more involved in your code’s upbringing. 

I remember the good old days, when development teams used to have the luxury of planning 9-16 month releases. We would take our time to plan the release from soup to nuts. Generally developers would take a good amount of time to build the software while testing was considered to be throwing over the wall event. In majority of the cases, testing phase (stabilization) used to take much longer than anticipated. Fast forward 10 years, and now we can no longer afford that luxury.  With the changing realities in this application economy, we need to not only be faster but also be much higher in quality-- slipping dates is not as much of an option, and our customers are not forgiving on quality.


Agile methodology has promise, but being able to deliver working software at the end of each iteration is easier said then done. QA efforts still can be a bottleneck: how can you test something which does not exist yet? Traditionally, QA had been focused on UI testing to verify software functionality. However, in the beginning of the project, UI either is non-existent or very fluid making it almost impossible to do any sort of test automation a reality and it goes on the back burner. For agile teams, the “Aha!” moment came when in his book, “Succeeding with Agile”, Mike Cohn introduced the testing pyramid concept.


Cohn argued that for test automation, we have been targeting wrong place. We will have a better luck in automating if we focus on Unit Testing and services layers to validate the application functionality.

Let’s see if this testing services layer approach for automation can also help us achieve our First Day Test Automation goal. I will illustrate it through an over simplified project example below.


Requirement: We need to build this awesome “Calculator” which can Add, Subtract, Multiply and Divide 2 numbers. I would want my end users to interact with the calculator via a web app (which supports IE, FF and Safari), as well as through native Android and iOS Apps. Also partners are interested in consuming our “Calculator as a Service” using an API. I also want my end users to be able to see which functions of the calculator are more popular.


Design: My fellow architect takes this requirement and comes up with the architecture below.


At the release planning meeting, we started drilling down on the stories and high-level architecture. The architect explains he is using the DB to store the API usage statistics. We ask the team to estimate the work. The API developer says it’s going to take him approximately 20 points to get to the state where he has the basic service up, and he may potentially finish Add and Subtract in sprint 1. The UI and Mobile developers are sitting there thinking, “I can start basic application stuff…but finalized interfaces can only be achieved after the services layer is in place.”

My QA reviews the architecture and acknowledges that with CA Application Test he can invoke and verify each layer individually as well as combinations of multiple layers (WebUI, Mobile, APIs or JDBC). “But wait a minute. I also need these components available before I can start building my automated test cases!” At that point, a light bulb goes off in QA engineer’s head and he suggests that let’s quickly agree upon the API interfaces and create a virtualized calculator service using CA Service Virtualization which can be used by me but also by UI/Mobile developers. 

That did it! The architect creates  the virtualized service and hands it over to the engineering teams. By using this virtualized service, we not only achieved parallel development of both the services and presentation layers, but also enabled QA to start creating automated test cases right from sprint 1.

Do you strive for First Day Test Automation in your organization? What are the tips and tricks you use to achieve this goal?