When word of the day is "Found!"

1. Insane pleasure when it comes down
to systems

2. Root Cause, eh?
• Business requirement- A road on which
vehicles can be driven.
• Expected result- Vehicles can be driven
smoothly in a straight line on the road at any
condition.
• Actual result- Vehicles lose control when road
is under different test conditions.
• In short – Slippery When Wet.
• Who caused this to happen!!!!

3. Deep Impact
• Business requirements are
the most important –
any deviation may cause a deep impact –
on people, project, prestige
• Best practice - Evaluate each requirement,
produce possible linkage with others, and
simultaneously establish user stories.

4. Start Bugging
• Each User Story should have a possible trail
of what can go wrong.
• Tester has to develop the bug, even before
developer can start coding.
• Expected results must comply with business
requirements.
• Additional observations must be
documented –meaning, even when a
situation is assessed as “Out of Scope”, it
should be verified from the business
stakeholders instead of sitting ducks on it.

5. Long Time No See
• Typically, expected bugs are way less potent than
hidden, dormant bugs.
• Hidden bugs express themselves rarely and can
disrupt the process to the extent of crash.
• Test steps executed to produce hidden bugs, may
or may not reproduce the same when re-
executed.
• Document exact test steps and bug , as soon as it
occurs.

6. Long Time No See
• Re-testing using test cases that
produce similar or related defects can be linked.
• Test Analyst might rethink about documenting
each and every random defect that occur.
• The deciding factor lies in the potency of defect
how it affects the application. Cosmetic changes
can be reported simply, while, any defect that
exposes architectural incompatibility, or
showstoppers, need to be documented with
screenshots and exact steps that led to it.

7. May Day, May Day
• Declaring a war-like situation
is best avoidable.
• Always remember Murphy’s Law: Anything
that CAN go wrong, WILL go wrong.
• And THAT WILL go wrong at the 11th hour.
• So, leave nothing to chance, or to your mate,
to complete that defect report which you
should be owning.

8. You cannot Go for Bug Reporting with loose
language-Bug reporting has to be precise
Summary
• Completely explaining
the Bug in less than 30
words
Steps to Reproduce
• Clear steps that lead to
the Bug in less than
150~200 words
Bug Description
• Have strong analytical
perspective and the
ability to express the
past, present and
future of the Bug
before hitting a 100.

9. Set the Stage
• Collect templates and assess the best that will
accommodate all essential details of Bugs – a
handful highlighted below
Summary, Description, Requirement ID,
Priority, Severity, Reported by, Assigned To,
Steps to Reproduce, Impact/ Regression
Analysis, Screenshot, Target Resolution Date,
Changes Made for Bug Fix, Modules Affected

10. Mind the Gap
• Demography, People
and Language - varies
in great lengths.
• Plan, Do, Check, Act
will be further
modified when
working with clients
across the globe

11. Stop Bugging
• Managers – Encourage and appreciate when
someone does what needed to done.
• Developers - Learn to accept that testing is not
your cup of tea. Leave it to the professionals.
• Testers – You strive to add value to the project
team, not extract out of it by meaningless
defects. So give them what they fear the most
– A Valid Bug

12. Bugs Inc.
• Bugs are incorporated through
out different phases of Software Development
Life Cycle.
• A proper Defect Management Tool eases the
hassle of tracking and reporting bugs.
• If the Defect Life Cycle has been initiated as
per the previous slides, it would be a lot more
easier to start with Defect Management…to
be continued.

13. The Art of…
By Prajnaparamita