Adopting AgileEnsuring Success

Copyright 2013 Coverity, Inc.

2

More. Better. Faster.• Customers demand new, innovative features

• And quickly

• Features are often implemented in software• Size of software projects is exploding

• And often includes third-party/open-source code

• Security and stability cannot be compromised

Today’s Reality

In other words: software organizations must provide

more, with excellent quality, security, and stability, using

reliably less time

3

A popular way to address these challenges

Many organizations are adopting practices commonly associated with Agile:

• Development via rapid iteration over bite-sized, self-contained work units rather than large process phases

• Automated testing: unit, regression, etc.

• Continuous integration builds

• In some cases, even continuous delivery

Agile

4

Business Benefits:

• More easily manage change

• Better align IT and business objectives

• Accelerate time to market

Development Benefits:

• Visibility: Discover problems sooner

• Efficiency: Fix problems more quickly and easily

• Predictability: Avoid late-stage schedule disruptions

Why Agile?

5

Theme: Avoid large backlogs; get early feedback• Test code as it is written, minimizing significant last-

minute disruptions

Practice/Benefit

Shorten Cycles, Distribute the Load

►Split development cycle into bite-sized sprintsImprove responsiveness, predictability

►Developers code, test, designAll team members are experts with the code; improve efficiency

►Use small, fast, automated tests like unit testsGet early feedback about whether the code is working properly

►Routinely integrate, build, test code changesGet early feedback about whether the product is in a working state

6

Adopting AgileWe need to go Agile—it will

solve our development

problems!

We can’t put the business on hold to rebuild

R&D, Bob!

7

• Even with a plan and support, adopting Agile practices often encounters resistance

• Business Risk: How to maintain developer productivity while onboarding testing responsibilities?

• Culture: How to convince developers to actually write tests?

• Adoption: How to enforce adoption of the new practices?

• IT: How to manage infrastructure?

• Politics: How to assure QA that their jobs are safe?

• Governance: How to manage the transition to ensure it is successful?

It’s Not Always Easy

8

Justifying Agile

We don’t have to! We’ll ease in,

starting with our new code and new projects.

We can’t put the

business on

hold…

9

• Business Risk (productivity with new testing requirements)

• Ease into Agile, e.g. focus on new code/projects first

• It’s not all-or-nothing, so plan a transition

• Culture (developers must write tests)• Enforce testing standards for important/high-risk code

• Phased deployment convinces skeptics and provides escape hatch

• Adoption (new practices stick)

• Automate enforcement as part of standard process

• Politics and Governance• Provide visibility into the new process

• Reassure stakeholders—process enables them to fulfill their mission, e.g. independently verify quality or security; not police R&D

Overcome the Resistance

10

• How do you determine if code is sufficiently tested?• It’s not practical (or possible) to automate tests for all code

• Are you testing all of the important code?

• Are you wasting effort testing unimportant code?

• How do you enforce testing of changes to legacy code?

• You need to require tests for all important code

• Without trying to boil the ocean

• How do you eliminate manual interpretation and noise?• You need to reduce adoption barriers and increase confidence

• Visibility without sufficient context is (worse than) useless

But…the Devil’s in the Details

11

Is Code Sufficiently Tested?

Sweet, safeClose() is fully tested now! I’m glad I don’t need to

test that catch block—I’m not sure I can even trigger an

IOException there.

12

dbgStub()

Partial Visibility is Worse Than Useless

Only 86% coverage for safeClose()? That untested 14% worries

me…

Why are we wasting time

testing dbgStub()?

Hey Bob, we need to

fix this!

13

• Leverage static analysis to get early feedback about common coding errors

• No need to invest time writing test cases for these issues

• It’s critical to automate, look for important problems and configure for minimal noise

• Don’t simply measure testing coverage

• Enforce a testing policy that focuses on the important/high-risk code

• Focus on certain components, modules, classes or functions

• Test all code impacted by recent changes

• No need to test debug, logging or exception-handling code

• Recognize field-tested code; consider code complexity

• Leverage SCM systems (age, author), testing artifacts, etc. to improve accuracy and automation

Let Your Tools Do the Heavy Lifting

14

Make It Easy On DevelopersJust add a

test covering line 1084 and I’m

golden. Glad I don’t need to test those

aborts!

Don’t need to be tested

15

• Automate, automate, automate

• Use a consistent workflow for all types of issues

• Generate prescriptive work items for identified problems• Automatically interpret and prescribe action

• “Here is your problem. Do this to fix it…”

• AVOID: “Does anything look wrong in this output? Don’t forget to check the build logs and the test output, too.”

• Provide easy access to all information, especially the source code and context relevant to the problem

• Automatically assign to appropriate team members for accountability

• E.g. by most recent SCM committer, or component owner

Make It Easy On Developers

16

Visibility With Context is Priceless

Awesome progress on our

improvement goals!

Development is right on schedule

17

• Measure coverage in the context of your testing policy and definition of “important” and “high-risk” code• Eliminate manual interpretation

• Measure performance against objective, meaningful standards

• All stakeholders will understand the reports

• Automate development testing in your process• Objective, meaningful assessments enable you to automate

with confidence and accurately fail the build when something is wrong

• Developers become accountable for code quality/security

• Gain visibility into pending problems and completeness

• Gain scheduling predictability

Visibility and Governance

18

Bob, you did a great job fixing

our development problems. I’m giving you a

raise!

Want to try Coverity on your code? For a free trial, visit:

www.coverity.com