Filing a bug report is never a fun experience, a well written bug report will make life easier for everyone involved, though. Reporting is one thing, but the real challenge in software development is to recreate a bug. So, ideally a well written bug report is just the half way to success. Setting up an efficient bug tracking workflow is the real challenge here. We have been seen many different bug tracking workflows in agencies as well as larger enterprises for managing website bugs in general. Initial situation & problem description Developers produce code that should work in every browser, every operating system and every device specified in the performance and compliance goals for a site or application. However, no matter how much effort we put into testing our work, clients will likely find something that doesn’t work: independent on how talented your development team is, bugs are inevitable, and everyone has to deal with them regularly. So, developers and project managers deal with the question of how to set up an efficient workflow for testing websites and tracking bugs for everybody involved. What’s wrong with current bug tracking workflows? The problem with current QA and bug tracking workflows is that QA engineers need to describe what they experience visually. That is, they translate something perceived into human understandable language. Obviously, a lot of contextual information is lost in translation. Even worse Most bugs happen at the worst place in the universe: the client’s browser and clients are in general not the best choice for QA. Not only are they expecting flawless software but often they simply don’t understand the concept of a good bug report. How to set up a bug tracking workflow! Every developer and project manager has his very own tool set which makes his/her life a lot easier. Over the last years, since starting Usersnap, we have seen different workflows. Some of them are more efficient than others. The main difference in most bug tracking workflows can be not only found in the variety of used tools (you won’t believe how many people are not using a “bug tracking tool” at all), but also in the complexity of the workflow itself. In this talk I’m going to show you some of the best and some of the worst examples of bug tracking workflows, including some crucial lessons learned and insights on how companies use their bug tracking tool (or don’t use any bug tracker at all).

1. The Do’s & Don’ts of a bug
tracking workflow.
@tompeham | @usersnap

2. That’s me. Thomas Peham.
● Tech Marketer at Usersnap, a visual bug tracking tool.
● managing bugtrackers.io
● previously:
○ Project Manager at a TYPO3 agency
○ Project Manager at Styria Digital One
● blogger for various web development & design blogs.
● @tompeham I @usersnap I @bugtrackers

3. Outline.
● The problem of bugs.
● 4 steps for tracking down bugs. (and fixing them.)
● From bugs to no bugs.
● Best bug tracking takeaways

4. Why I’d like to talk about bug tracking today.
Or: What is Usersnap about?
@tompeham | @usersnap

5. bug tracking, the black sheep?

6. Compared to other web development
areas, bug tracking is pretty “old school”.

7. How people react when it comes to tracking
bugs...

8. Or this way...

9. The problem of software bugs.

10. The problem of software bugs.

11. The problem of software bugs.
Bugs are expensive.

12. The problem of software bugs.
Bugs are expensive.
(approx. $ 312 billion per year globally)
source: Cambridge University

13. The problem of software bugs.
Developers don’t test
their code?!
source: ashleynolan.co.uk

14. The problem of software bugs.
What tool do you use to test your
JavaScript? (if any)
source: ashleynolan.co.uk

15. Web development has changed. Why bug
tracking hasn’t?

16. So, how do we solve that problem of bugs?
I SEE BUGS
EVERYWHERE

17. Step 1: Ensure a bug-free development
environment.

18. Step 1: Ensure a bug-free development
environment.
Yeah, but there will
always be some bugs.

19. Agree on: what is a bug.
And what isn’t.
Find the real bugs.
Okay then. Step 1) Define + find bugs.

20. “A software bug is an error, flaw,
failure, or fault in a computer
program or system that causes it to
produce an incorrect or unexpected
result or to behave in unintended
ways.”
What is a bug?

21. software bug
...error, flaw, failure, or fault….
...produce incorrect or unexpected
result…
What is a bug?

22. software bug
something which is not working as
designed.
What is a bug?

23. What is a bug?
This is a bug...

24. something not working as designed.
or.
not designed as it should work?
What is not a bug?

25. in theory: it’s easy.
in practice: it’s not.
What is not a bug?

26. So, who’s in charge?
The project manager?
QA Team Lead?
Development Team Lead?
What is not a bug?

27. Agile sounds great, right?
What is not a bug? Who’s in
charge!?

28. So, who’s in charge?
The project manager?
QA Team Lead?
Development Team Lead?
What is not a bug?
Decide + communicate
at the beginning of a
project!

29. 1) automated testing
2) manual testing
3) crowd testing
4) the “banana principle”:
or testing with the
customer
How to find bugs?

30. How to find bugs? Automated testing.
Specify test cases run tests
test
report

31. + no infrastructure (devices,
browsers, vms) needed.
+ many platforms &
browsers are supported.
+ fast & reliable test cases.
How to find bugs? Automated testing. Benefits.

32. - Investment in tools
required.
- No “real device” feeling
- tools have limitations
- “agile testing” hardly
possible
How to find bugs? Automated testing. Drawbacks.

33. How to find bugs? Manual testing.
write test cases &
user stories
manual testing
test
report

34. + short-term cost is lower
+ manual testing = agile
testing
+ more user-centric than
automated testing.
How to find bugs? Manual testing. Benefits.

35. - investment in human
resources is required.
- test execution takes longer
than automated testing.
- threat of “human errors”
How to find bugs? Manual testing. Drawbacks.

36. Let the crowd test your
website.
Combines the benefits of
manual + automated testing.
How to find bugs? crowdsourced testing.
write test cases &
user stories
let the crowd
test
test
report

37. + user-centric feedback
+ fast & reliable
+ “outside” view to system
How to find bugs? crowdsourced testing. Benefits.

38. - find the right crowd
(=target group)
- still in its early beginnings
How to find bugs? crowdsourced testing. Drawbacks.

39. Automated vs Manual?
Robots vs human power.
TDD vs agile.
Pre-scripting vs user-
centric.

40. Step 2) document bugs.

41. Step 2) document bugs.
How a bug report form
should look like.
Not.

42. Step 2) document bugs.
How a bug report form
should look like.
Not.

43. But: Information needed when reporting a bug. Or:
The Art of Bug Reporting.

44. But: Information needed when reporting a bug. Or:
The Art of Bug Reporting.
- The What? A description of what happened.
- The Where? Place where the bug happened.
- The When? Time frame when something
happened.
- The Who? Person who discovered the issue.
- The Why? Why do you think it happened?

45. How to write the perfect bug report
- summary + prioritization
- details on how to find the
bug again.
- meta information.
- ….

46. Your website = place where
the error occured.
How to fix the bug documenting process.
crime scene:
written document of
problem description
bug report:
place where the problem
should get reproduced %
fixed.
developer’s code:

47. Your website = Where the
error occurs.
How to fix the bug documenting process.
crime scene:
written document of
problem description
bug report:
place where the problem
should get reproduced %
fixed.
developer’s code:This is a loooong way
for fixing bugs.

48. = browser
Why not stay in the same medium?
crime scene:
= browser
bug report:
= browser?
developer’s code:
This is a visual experience This is a visual experience

49. Step 3) Reproduce it.
“If you can’t reproduce a bug, it’s
almost impossible to fix.”

50. Step 3) Reproduce it. But how?
bug reporting tool
the client: the project team
project mgmt tool
development
environment
But it works on
my
environment!
There’s a bug!

51. Step 3) Reproduce it. But how?
integrated PM + bug
reporting tool
the client: the project team
development
environment
screenshots screenshots
+meta info

52. Step 4) Fix bugs.

53. Step 4) Fix bugs.
If you’ve followed step 1 - 3,
step 4 is easy.
Is it? ;-)

54. Step 4) Fix bugs.
What does a closed bug mean?

55. Step 4) Fix bugs.

56. Step 4) Fix bugs.
Who is responsible for
this decision?

57. So, to the recap...

58. From bugs to no bugs.
Bugs Find them.
Document
them.
Reproduce
them.
Fix them.
No
bugs.

59. Key takeaways

60. The Waterfall...

61. The Waterfall...
...is no longer valid.

62. agile testing

63. agile testing
#FTW

64. agile testing
#FTW
Decide on
responsibilities!

65. ad-hoc bug reporting

66. visual bug reporting

67. bug tracking responsibilities

68. Open vs. closed bugs.

69. But what if...

70. Communication matters.

71. Everybody is a QA agent

72. Now it’s up to you.

73. @tompeham
@usersnap
@bug trackers
thomas@usersnap.com
Thomas Peham