facebook.com/telerik

@Team_Pulse

gplus.to/teampulse

Philip Japikse (@skimedic)

phil.japikse@telerik.com

www.skimedic.com/blog

MVP, MCSD, MCDBA, CSM, CSP

Agile Practices Evangelist, Telerik

AGILE SOFTWARE ENGINEERING

WHERE’S THE BEEF?

• Engineering practices are still relevant

• Agile is NOT 6-8 Developers:

• Holding hands

• Wearing Birkenstocks

• Singing Kum-Bye-Ya

8/15/2012 3

WHAT’S STILL RELEVANT

• Core Engineering Practices

• Requirements Engineering

• Quality Engineering

• Human Factors

8/15/2012 4

CORE ENGINEERING PRACTICES

8/15/2012 5

SOURCE CODE CONTROL

• Commit early and often

• EVERY TIME you are green!

• Update after every check in

• Run tests on each commit (CI)

6

AUTOMATED BUILD PROCESS

• Run all unit tests with every build

• Builds should be run at least twice a day (striving

towards Continuous Integration)

• Failed Test = Failed Build = Doughnuts

• Integration tests should be run at least once a day

8/15/2012 7

PAIR PROGRAMMING

8/15/2012 8

• Slightly reduces productivity

• Increases code quality

• Should be polygamous

• Don’t do it full-time

DEFINING “DONE”

8/15/2012 9

• All (Dev, Users, QA, etc) must agree on definition of Done

• Developer

• Unit Tests, Documentation, Code Reviews, etc

• QA

• Integration Testing, Black Box Testing, etc

• Users

• UAT

• Will be different based on the product

• NASA vs XBOX

SOLID

• S – Single Responsibility Principle

• O – Open/Closed Principle

• L - Liskov Substitution Principle

• I - Interface Segregation Principle

• D - Dependency Inversion Principle

8/15/2012 10

FINALLY

• Last Responsible Moment

• YAGNI

• DRY

8/15/2012 11

REQUIREMENTS ENGINEERING

8/15/2012 12

REQUIREMENTS

• A good requirement is one that you can wrap a test

around

• All Backlog items need to be defined well enough that:

• Developers can understand and code the intent

• QA Resources/Testers can validate the code

• Incomplete items are removed

8/15/2012 13

WIREFRAMES

8/15/2012 14

• Used to visually layout the User Interface

• All proposed screens

• Important to not look “finished”

• Tools:

• http://www.mockupscreens.com

• http://www.balsamiq.com

• http://tinyurl.com/mssketchflow

USER STORIES

• User Stories

• As an [X] I Want [Y] So That [Z]1

• X is a role, Y is a feature, Z is the benefit 1http://dannorth.net/introducing-bdd

• As an Account Manager, I want to be able to Edit a Customer’s Address so that we can Effectively Communicate with them

• Include success criteria

8/15/2012 15

SUCCESS CRITERIA

• Must be testable

• Use Given/When/Then syntax

• Given 2000 customers

• When selecting one

• Then the form should open in < 1 second

8/15/2012 16

CONTEXT SPECIFICATION1

• When Editing a Customer’s Address for the benefit of

improving communication

• It Should Load in < 1 sec with 2000 customer

records

• It Should allow an Account Manager to edit the

address 1Behavior Driven Development (Code Magazine) - Scott Bellware

8/15/2012 17

TEST DRIVEN REQUIREMENTS

• Driving the Rapid Feedback Loop at the Requirements

stage

• Using MSpec or similar tools

• Removes ambiguity upstream

8/15/2012 18

QUALITY ENGINEERING

8/15/2012 19

MICHAEL FEATHERS

“The main thing that distinguishes legacy

code from non-legacy code is tests, or rather

a lack of tests.”

20

UNIT TESTING MOTIVATION

• Cost of correcting a defect (by phase)1:

• Requirements = $139

• Design = $455

• Coding = $977

• Unit testing targets coding -> deployment and maintenance

• System Testing = $7,136

• Maintenance = $14,102

1B.Boehm and V. Basili, “Software Defect Reduction Top 10 List”, IEEE Computer, January 2001

21

WHY REALLY?

• The Team

• Confidence

• Courage

• Cadence

8/15/2012 22

TEST/BEHAVIOR

DRIVEN DEVELOPMENT

8/15/2012 23

• Development needs to be Test Driven

• QA personnel need to understand what that means

• Successful T/BDD development teams build confidence in themselves and with others

• QA shouldn’t have to test that

• Math.Add(2,3) returns 5

• QA can focus on the bigger picture

• Making sure the requirements are met

• Integration Testing

TDD VS BDD

• Test Driven Development

• Test blocks of code

• Behavior Driven Development

• Test Behaviors

8/15/2012 24

IT’S *NOT* ABOUT TESTING

• Tests are used to

• Drive design of the API

• Confirm success with rapid feedback loop

• Validate changes don’t break code

8/15/2012 25

T/BDD BENEFITS

• Less Code

• Only develop enough to meet the requirements

• Cleaner Design

• Code is written in small increments in direct

response to need

8/15/2012 26

T/BDD BENEFITS

• Higher Code Coverage

• Once code is developed, often there isn’t time in the

schedule to go back and improve coverage

• Measurable Impact of Future Changes

• How many tests break with a change?

8/15/2012 27

T/BDD BENEFITS

• Goal is “zero” defects

• Defined by code not matching documented

requirements

• End Result = Faster Time to Market

8/15/2012 28

COMMON FRICTION POINTS

• It’s Hard.

• <Fill in the blank> doesn’t want me writing “twice as

much code”.

• I don’t have time for it.

• My code doesn’t have bugs.

• That’s QA’s job.

• Any others?

8/15/2012 29

QA/TESTERS

• Best if QA is co-located with the team

• Create Test Plans based on each Sprint

• Not on requirements that might never be developed

• When developers believe they are “Done”

• QA Reviews Unit Tests/Peer Review

• Bottom line, QA should be Proactive, and not Reactive

8/15/2012 30

HUMAN FACTORS

8/15/2012 31

DESIGNERS

• Typically create comps very early in the process

• Then go away

• They are part of the team

• Start with wireframes

• Designs/comps done at the last responsible moment

8/15/2012 32

USERS

8/15/2012 33

• Most users/customers don’t understand software

development

• Used to waiting months/years to see projects delivered

• Coaching is required

• Give them a single Point Of Contact

• True User Testing is a new concept

USER TESTING

• User Testing is used to validate the state of the

software after every sprint.

• The Team (via the Product Owner) must fully

disclose what they believe to be working and not

working

• Key Users test the software from the previous sprint

• Users can enter potential defects into the tracking

system

8/15/2012 34

SUMMARY

• Keep the baby, not the bathwater

• Engineering Practices are still first class citizens in

agile

• Quality is king!

8/15/2012 35