Welcome!

Service Virtualization and API Testing

Cynthia Dunlop

Subscribe to Cynthia Dunlop: eMailAlertsEmail Alerts
Get Cynthia Dunlop via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, DevOps Journal

Cloud Computing: Blog Post

Relationship Between Risk & Continuous Testing By @Parasoft | @CloudExpo

Continuous Testing Q&A with Parasoft's Wayne Ariola

Stickyminds' Cameron Philipp-Edmonds recently interviewed Wayne Ariola (Parasoft Chief Strategy Officer and co-author of Continuous Testing) about how Continuous Testing provides a real-time, objective assessment of the business risks associated with an application under development and allows both business and technical managers to make better trade-off decisions between release scope, time, and quality.

The interview covered topics such as:

  • The relationship between risks and Continuous Testing
  • Common misperceptions about Continuous Testing
  • Who should care about Continuous Testing
  • How we are all in a new era of testing
  • Why now is the best time in the history of software to be a tester

The following is a brief excerpt from the interview...

"There are basically four major points associated with continuous testing. One, is the business expectations associated with that application need to be defined. So the business risk associated with the application, the team, or the release candidate needs to be very well defined. When those business expectations are defined, we are able to act upon them.

The second thing is defects associated with those business objectives or business expectations are automatically prioritized versus those business drivers. We understand what errors have been injected. We have very distinct isolation techniques to isolate the defects at any particular point in time and when one of those defects are found, basically the priority of them are automatically categorized so they don't just slip away.

The next thing that we need, and this is point three, is there needs to be a very distinct ownership associated with workflow and defect remediation. So today when a potential defect is found, you go through a huge iterative process associated with can you recreate it, can you define it, can you have an environment associated with recreating the error. Can development recreate it and can you fix it. And today we have mechanism to collect the information, but we don't have very distinct clear paths for ownership and remediation. That is one of the biggest areas where we can actually collapse the remediation cycle time and save a lot of time.

This leads to the last point, which is when we do find that there are trends associated with defects that are found, we need this feedback loop for defect prevention. Let’s say an organization is exposing more security issues than they would like. We should look at that pattern, understand that pattern, and then create defect prevention strategies to eliminate those classes of errors in the future. These priorities will obviously shift versus the business expectations.

When you ask the question, can you do more? I don't think the question is, "do more?" I think the issue is more about putting this idea of testing better in line with the business. Delivering information in which the business can make better trade off decisions associated with an application or its release versus extending time or scope. With that being said though, a lot of people say well, we do manual testing, we can't be continuous. It doesn't matter, you can have a continuous testing mindset and be a 100 percent manual testing organization as long as you're achieving the business demands associated with the organization. This is something we always try to think about because we think that everything needs to be automated. Automation is great by the way—automation gets us there a lot faster, by the way, without necessarily relying on humans who can inject errors as well. But if the business demand or the application demand itself has a very strong kind of environment in which manual testing achieves the goal, then manual testing is it. What we want to do, is we want to fit the practices to the business not what we have been doing in the past, which was to make sure to fit the tool into the business. We want to make sure the practices meet the business demand."

...

During the interview, Ariola and  Philipp-Edmonds also chatted about topics such as:

  • Is there a law of diminishing returns for continuous testing or is it "a more the merrier" approach?
  • How does Continuous Testing apply to teams that perform only manual testing?
  • What are some emerging trends in software quality?

To hear what they had to say, read (or listen to) the complete The Relationship between Risk and Continuous Testing interview at Stickyminds interview (no registration required).

More Stories By Cynthia Dunlop

Cynthia Dunlop, Lead Content Strategist/Writer at Tricentis, writes about software testing and the SDLC—specializing in continuous testing, functional/API testing, DevOps, Agile, and service virtualization. She has written articles for publications including SD Times, Stickyminds, InfoQ, ComputerWorld, IEEE Computer, and Dr. Dobb's Journal. She also co-authored and ghostwritten several books on software development and testing for Wiley and Wiley-IEEE Press. Dunlop holds a BA from UCLA and an MA from Washington State University.