Eliminating the Dog-Ate-My-Data and Other Testing Excuses
Eliminating the Dog-Ate-My-Data and Other Testing Excuses
What must it be like to be working in QA or development and have to explain why a defect made it into production?
Join the DZone community and get the full member experience.Join For Free
Read why times series is the fastest growing database category.
After reviewing my teenage son’s grades one night with him and getting a list of excuses for low marks and missing assignments, I started to wonder. What must it be like to be working in QA or development and have to explain why a defect made it into production? It’s sort of funny to think about the parallels at first, but how do you overcome them?
Excuse #1 – The dog ate my data.
The dog actually did once shred my son’s homework to bits, but he was able to quickly reproduce it. If only data was as easy to reproduce.
Lack of test data continues to be one of the biggest challenges for testers. CA has found that testers in fact can spend up to 50% of their time looking for data.
But getting the test data you need when you need it no longer needs to be a legitimate excuse for delaying testing. Test data management enables a company to generate needed data and store it in an on-demand warehouse accessible 24 x 7 – so even when the dog does eat your data you’ll be able to reproduce it and get your tests done on time.
Excuse #2 – Nobody told me that.
Unfortunately communication challenges are not only limited to our children. Poorly documented requirements can create serious challenges. As requirements change, testers have no way to identify the impacts on testing schedules.
To overcome this many orgs have tried to use tools like Visio to visualize requirements but this still requires a lot of manual effort to create and update as things change. Using a tool that is designed solely for requirements and test case management can greatly improve communication. CA Agile Requirements Designer (ARD) maps requirements to visual flowchart models, helping orgs eliminate ambiguous requirements. As requirements change, CA ARD will automatically find and repair broken tests, automatically creating any new tests needed to maintain 100% excuse-free test coverage!
Excuse #3 – That application was before my time.
Testing dependencies with legacy systems can create a myriad of challenges for an organization, especially when the systems are not well documented and the people who developed them are long gone.
Just imagine giving your 16 year old a set of encyclopedias to write a research paper. Would they even know where to start? This is one of the few areas where you maybe forced to rely on manual testing.
But once the initial manual tests are created you can then start to improve processes with technology. CA Continuous Application Insight is an innovative technology that can be used to “follow” a test and discover interactions happening related systems. It can use this data to document the transaction flow and auto-generate new tests.
In addition, manually created tests can then be loaded into CA Agile Requirements Designer that can then deduplicate and visualize them.
Excuse #4 – I didn’t have the right build.
Using the wrong build will surely affect testing. But who’s responsible for ensuring development and testing are working with the current build?
This is where release automation comes into play. With release automation manual steps are removed and nobody is burdened with telling the test team what build to use – it’s all documented within the system itself.
CA Release Automation can also automate the running of the test scripts or initiate the actions of automated testing tools like CA Application Test, making it part of the deployment workflow and automatically promote the application to the next stage based on a successful test completion. Test environments can also be provisioned and configured within the workflow (including virtual environments) and then destroyed upon completion to free up resources.
Excuse #5 – It worked fine on my machine.
An oldie but a goodie. In today’s world of composite applications, APIs and microservices, the only way to accurately test code is to test it in as close to production as possible. The standard approach to mimic production systems in development calls for creating mocks and stubs.
But with mocks and stubs you’re still relying on the developer’s knowledge of and access to the related systems, which then need to be updated by the developer and are still limited in the types of testing they can be used for.
And this is why many clients who are serious about agile development and “shift-left” testing are embracing service virtualization.
Service virtualization eliminates many of the reasons why defects make it out of development. Unlike mocks and stubs, the virtual services are created by recording the actual service and can be placed into Virtual Service Environments (VSEs) that multiple developers can then access. This not only increases productivity but also test consistency and quality.
CA has helped many clients deliver a “Test Environment in a Box” to their development teams. This provides them with an on-demand test environment that can be accessed via their machine. It can even provide them with needed test data.
With CA Service Virtualization, “It worked fine on my machine” is one excuse you will hear a lot less. According to a study by the Voke group, 46% of participants reduced total defects by 41% or more using service virtualization.
Join us on our May 10 webcast with TechWell to learn more about how to “Make Testing More Agile and Eliminate Excuses.”
Published at DZone with permission of Heather Peyton , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.