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).
Open Source Summit NA 2024: Open Source Cloud Costs - OpenCost's Impact on En...
T3CON15: The Best Do's And Don'ts of a Bug Tracking Workflow
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
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?
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.
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