Post on 02-Jul-2015
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