Continuous Testing

Continuous Testing provides a real-time, objective assessment of the business risks associated with an application under development. Applied uniformly, Continuous Testing allows both business and technical managers to make better trade-off decisions between release , time, and quality. Generally speaking, Continuous Testing is NOT simply more test automation. Rather, it is the reassessment of software quality practices—driven by an organization's cost of quality and balanced for speed and agility. Ultimately, Continuous Testing can provide a quantitative assessment of risk and produce actionable tasks that will help mitigate these risks before progressing to the next stage of the SDLC. What you'll learn You will learn how Continuous Testing can help your organization answer the following questions at the time of the critical “go / no-go” decision for a software release candidate: * Are we done testing? * Does the release candidate achieve expected quality standards? * What are the quantifiable risks associated with the release candidate? * How confident are we that we won't end up in the news for software failures? Who this book is for This book is written for business executives and development practitioners who need to achieve the optimal balance between speed and quality with software that interfaces with customers... and ultimately revenue. It provides a technical perspective on how to accelerate the SDLC and release with confidence. From Alan Zeichick, SD Times "Ariola and Dunlop nail the target: It’s all about risk. That’s what insurance is all about, that’s what attorneys are all about, that’s the sort of decision that every business and technology manager makes all day, every day. We have to live with risk and make tradeoffs. More testing? At some point, indeed, we have to cut it off. It’s difficult if not impossible to assess the business risk of software quality. Yes, software quality is expensive. The higher the quality, the more time it takes to deliver software, and the greater the resources you must spend on software quality. And yes, it is expensive to have software failures—you might lose money, lose customers, suffer lawsuits, damage your brand, end up on the front page of The Wall Street Journal. Not good... Ariola and Dunlop make a good point in their short book: We mustn’t accept that the trend toward accelerating the development process will magically improve software quality; indeed, we should expect the site. And if we are going to mitigate risk in today’s environment, we need to reengineer the software development process in a way that considers business risk to be one of the metrics, along with the other traditional results of our automated testing and Continuous Integration systems."

undefined