How to Zap Software Bugs Before It Stings Your Production Environment

by August 15, 2017

Avoid costly late rework

Pesky software bugs in production can sting your organization in many ways. But where it hurts the most is the pain it inflicts on your budget. A software defect in a live environment can costs up to 1000x more to repair than if it’s found early in the SDLC. And so, the more you shift left testing, the better you will be in gaining dramatic cost savings, because you’ll know how to address software bugs before  they get in to your production environment.

Test teams are given ambiguous requirements to begin with

Did you know that more than half the time, software defects and related challenges are introduced early in the project, specifically during the requirements phase? A big part of the problem in requirements engineering is that requirements are often unclear and incomplete, and usually stored in disparate, static formats. This doesn’t help the test teams that do test case design, as the test cases they generate are manually derived from these ambiguous requirements. This problem gets even worse as the development cycle progresses farther away from a shift left testing approach. In the end, the software often fails to deliver a good customer experience, or even worse, defects are detected later in the SDLC where they require far more time and resources to resolve. Further, because most testing teams operate manually, there is no way to automatically or easily update a test when requirements change.

Test teams are given production data to do their tests

Production do offers volumes of data, but that doesn’t mean it’s the perfect place to get data for testing. For one, you won’t get ‘outlier’ data conditions from Production. Without it, you’ll likely end up having poor coverage, inevitably introducing bugs in production.

Think about a retail sports store for a second. The cash register scans thousands of items such as running shoes, golf balls and baseball bats every day without trouble. However, what happens when someone buys a specialty throwback jersey that is a one-off stock order and he pays for it using a mix of gift and credit cards, and cash? This outlier data condition was not tested at all because it was an item that gets off their rack daily. What if this specific condition had a defect that ended up bringing the whole system down to a halt? One thing is sure to happen – your unhappy customers will leave the long lines, and go next door to your competitor to do their shopping.

Test teams continue to manually create test data

No one enjoys spending serious cycles on time consuming tasks. That includes your test teams when they have to manually create test data every time. And mind you, this task rarely results in achieving the level of quality and coverage that is required to fully test a system, before it goes live. Using manual data to test with is far from being the ideal scenario, in a true shift left testing fashion. Conversely, this practice will only lead to bugs being missed and found their way into production.

Shift left testing into the design phase

When you shift left testing efforts into the design phase, you end up mapping test cases, test data and automated tests directly from business your requirements. When user needs change, our testing tools update test assets automatically, helping you achieve rigorous testing in less time. Done right, shift left testing can help you dramatically shorten your test cycles and boost your application quality while generating the smallest tests needed for maximum functional coverage.

When creating test cases right from requirements, you’ll need to add data and expected results to the model. In this video, we’ll model a simple discount calculator and show how to create test cases right from those requirements models automatically. Watch this video to learn more.

Use Test Data Management approaches to cover all your scenarios

Using test data management approaches, you can generate ‘mock’ or ‘dummy’ data to use in your test and development environments. These rich sets of compliant data can be tailored to your requirements, providing you with the smallest amount of data you need to satisfy all your test cases. This will ensure that your tests are covered and that testing delivers a high quality, bug free, product.

Dummy data can be based on an accurate picture of your data model, making it production like. However, it will contain no sensitive content, will be based on your testing requirements and will ensure that you have the 100% functional coverage in smaller, richer sets of dummy data.

Shift left testing helps you avoid costly software defects. Start your Free Trial of CA Agile Requirements Designer today – and see how you can zap those pesky software bugs earlier than later in the SDLC.