Documenting an agile defect

Shirly Ronen-Harel

Oct 2010

What is an agile

level of defect

documentation?

Moving fast means also to be able to document defects to a level of “just enough” and not

to much.

The level documentation of defects in an agile

environment changes for deferent types and

process stages related defects.

Defects management is one of Highly important process to manage efficiently and

effectively.

Defects management is a

costly process : documenting

, reproducing , managing,

fixing , closing.

Managing and resolving

defects should be done in a

timely and efficient manner.

Outstanding defects can hold

up the release of

functionality to the business.

Defect should be related

to functionality – not

to a module.

Quality in : Finding ,fixing

and testing Defects Early

is a must.

deferent agile defects phases

Each phase holds a deferent agile attention to the defect

documentation

Defect detected during peering , developer & tester.

Defect detected while continuously merging code.

Defect detected during acceptance tests of a user

story/epic/process/functionality.

Defect detected during regression tests.

Defects detected during customer lab testing.

Customer defect – from customer production.

Inherent defects.

And more

• Keep it simple – we don't have to document

all defects at the same level of details for

all deferent phases of detection.

• It depends on the value the documentation

holds against the effort of documenting it.

Tips

The far we move from the developer who fix the bug

(or reproduce it), the more detailed the defect documentation should be and the procedure should

be more official.

The distance between development

operations to those who supply the

defects to fix is curtail since

communication barriers hold expensive

waste potential

For example : tester located in an off shore team should send detailed bugs with the most relevant details to the group of developers. The flow of communication may hold a time/ distance gap that may delay the bug fix, reproduction on the bug

or even understanding it.

Other needs that defines the level

of documentation of a defect

Just enough documentation level for the following.

each level require a procedure of deferent documentation details.

Defect that we can learn from in the future , will be

document to the level of learning value only.

Defect to add to automated tests, will be documented with

the relevant information.

Non reproducible defects , will be documented for future

use.

Defects to move to future versions should be highly

document to the level of ease of reproduction.

Peering defects/ check-in defects – may not even be

documented in case they are fixed on the spot.

Detailed

Less detailed

Co-located

teams

Distributed

teams

•Check-in defects

•Detected during tester –

developer Peering.

•Fixed on the spot

•Minor fixed on the spot

•High priority (?)

•Not fixed this

iteration/release

•Needs further

testing/investigation

•Regression

•Manual Bugs to add for

automated testing

•Not fixed toady

•Customer regression

production bug related to 3rd

level support

•Off shore testing. Detailed

issues and bugs

•Faster support operations

•Customer data defects

•Almost nothing – not cost

effective

Decide for each type of defect the agile level of

documentation

• For example : since we don’t always have the opportunity to talk to the defect reporter when we want to fix the defect ,defects coming from customer site , may need to hold configuration details, customer data and scenario as a must.

• For example : defects related to an acceptance tests may hold only a clear title to them since the entire tests detailed is automated or already documented into the user story acceptance.

Tractability

• Functional Defects• are Always traced to a user story – functionality

– A defect is a user story child.

– It is born from a task testing or user story acceptance, regression,

sanity testing

• Or epic

• Not to a module

• Regression defects– Detected at customer site or not related to a current open user

story

– Should be added to the sprint/ product backlog and prioritized as

part of a backlog item.

Therefore

Big defects list is out!

Functional backlog progress

and quality view – is IN!

• The focus is on the release

functionality quality . defects are only a

small part of it.

Big bug meeting are out, short

“just on time“ functional

health discussions are IN.

Defect view is not relevant

Two new views becomes more relevant :backlog view & functional user stories

view.

• Release view drill to functional status –

progress , coverage, bugs.

• Backlog view – change management for the

entire release : functional and bugs.

User story

task

task

task

task

Epic

In progress planedactual remaining

defect

User story

task

task

task

task

Epic

In progress planedactual remaining

defect

User story task

task

Epic

doneplaned

actual

defect

User story

task

task

task

task

Epic

In progress planedactual remaining

defect

User story task

task

In progressplaned

actual

defect

remaining

planedactual remaining

http://codesion.com/images/collabnet-scrumworks-pro.jpg