Search

SEERS - Standardised Bug Reporting

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Antony Kennedy
    Run a business called Silver Squid
    Agile Evangelist. Big fan of process. Investigated and experimented with agile processes at several companies and no-one reports bugs properly.
    Worked for BBC, Channel 4, Sky

    Obligatory Lolcat
    People working in our industry all get bugs raised every day
    A bit of history?

    On older computer punch cards were used to store data. No hard drives or magnetic medium. Data was represented as little holes in cards.
    In 1947, Grace Murray Hopper was working on the Harvard University Mark II Aiken Relay Calculator (a primitive computer).
    On the 9th of September, 1947, when the machine was experiencing problems, an investigation showed that there was a moth trapped between the points of Relay #70, in Panel F.
    The word went out that they had "debugged" the machine and the term "debugging a computer program" was born
    In today’s web 2.0 world, we have more complicated software, and more bugs. We have dedicated teams of testers just to find them.

    Different testers raise different bugs in different ways.
    Some detailed and complex.
    And some not so much.

    SEERS is a standardised method for recording bugs.

    So, let’s go through them.

    So, let’s go through them.

    So, let’s go through them.

    So, let’s go through them.

    So, let’s go through them.

    So, let’s go through them.

    Lots of others.
    I’m a mac boy so I have no idea what windows software there is.
    Ideally annotate - skitch is great for this.
    Some scenarios, a screencast could be good.

    Perhaps the date and time. This is also useful for looking at logs.
    The speed of the computer.
    Plug-ins.

    If we know what was expected, we know when we have fixed it.

    The biggest bugbear (pun intended).

    The next biggest problem. It is useful to agree criteria.

    We will talk more about severity. First let’s mention things we need to know to gauge it.

    Notice IE6!
    This goes against Yahoo!’s very good graded browser support - but this an entire different discussion. Suffice to say, with the development time it takes, I do not believe making everything perfect in IE6 is more valuable than developing more features. Remember, your users do not compare browsers side by side like we do. They have no idea there are inconsistencies, and more often than not simply wouldn’t care even if they did. It is unfortunately impossible for a website to look the same in every browser or environment (without just using a huge image map, and even then a text-only browser like Lynx would not be able to render it) and there is nothing to gain in trying needlessly to overcome this.

    Login box - correct details, clicks submit. Grade A browser.

    Gets details wrong. Presses return. Grade A browser.

    Types unexpected characters. Grade A or B browser.

    Clicks submit 300 times. Any grade browser.

    Malformed URLs. Changing the page with Firebug. Attempting to perform SQL injections. Any grade browser.

    Now we know the background for severities. Let’s discuss them.

    Types of severity.

    Types of severity.

    Types of severity.

    Types of severity.

    Types of severity.

    Clicking login does nothing at all.

    Entering invalid credentials takes us to an empty page.

    Entering over 100 characters causes an error.

    We should fix if cost effective to do so.

    We should fix only if cost effective to do so.

    My definitions, not necessarily yours.

    So, to conclude.

    Last recap

    Last recap

    Last recap

    Last recap

    Last recap

    Slides will be on my blog later. Questions?

    1 Event

    SEERS - Standardised Bug Reporting - Presentation Transcript

    1. SEERS Standardised Bug Reporting Antony Kennedy @booshtukka antony@silversquid.com
    2. The first computer bug. Ever.
    3. Different testers raise different bugs in different ways.
    4. Different testers raise different bugs in different ways.
    5. What is a poor tester to do?
    6. Introducing:
    7. Introducing: SEERS
    8. • Screenshot
    9. • Screenshot • Environment
    10. • Screenshot • Environment • Expected/Actual Behaviour
    11. • Screenshot • Environment • Expected/Actual Behaviour • Reproduction
    12. • Screenshot • Environment • Expected/Actual Behaviour • Reproduction • Severity
    13. Benefits of SEERS
    14. Benefits of SEERS • Ensuring consistent error reports
    15. Benefits of SEERS • Ensuring consistent error reports • (even with new staff)
    16. Benefits of SEERS • Ensuring consistent error reports • (even with new staff) • The capturing of all relevant information
    17. Benefits of SEERS • Ensuring consistent error reports • (even with new staff) • The capturing of all relevant information • Less confusion
    18. Benefits of SEERS • Ensuring consistent error reports • (even with new staff) • The capturing of all relevant information • Less confusion • Greater efficiency
    19. Benefits of SEERS • Ensuring consistent error reports • (even with new staff) • The capturing of all relevant information • Less confusion • Greater efficiency • Profit!
    20. Screenshot There should always be a screenshot of the problem. Mac software: • skitch.com • Grab Windows software: • www.screenshot-utility.com • alt-print screen
    21. Environment There should always be details on the environment the problem occurred in. Don’t forget: • Browser (including version) • Operating System • Screen Resolution
    22. Expected/Actual Behaviour There should always be details on what happened, and exactly what was expected to happen.
    23. Reproduction There should always be accurate details on how to reproduce the bug.
    24. Severity There should always be details on how severe the problem is. i.e. How important it is that we fix it.
    25. Graded Browser Support Which browsers should we support, and to what degree?
    26. Grades • Grade A These browsers should work perfectly (with progressive enhancement), look close to perfect and perform well. • Grade B These browsers should work acceptably, look good and perform well. • Grade C These browsers should work and have no obscured or illegible content.
    27. Grade A Browsers • Windows XP/Vista/7 - IE7 IE8 - - Firefox 3.5 - Opera (latest version) - Safari (latest version) - Chrome (latest version) • Mac OSX 10.5/10.6 - Safari (latest version) - Firefox 3.5 Opera (latest version)
    28. Grade B Browsers • Windows XP/Vista - Firefox 3 IE6 - • Mac OSX 10.5/10.6 - Safari (previous version) - Firefox 3
    29. Grade C Browsers • Everything else!
    30. Yahoo!’s Graded Browser Support http://developer.yahoo.com/yui/articles/gbs/
    31. The Five Paths Paths describe the route a user takes through our site.
    32. • The Happy Path
    33. • The Happy Path • The Typical Path
    34. • The Happy Path • The Typical Path • The Unhappy Path
    35. • The Happy Path • The Typical Path • The Unhappy Path • The Insane Path
    36. • The Happy Path • The Typical Path • The Unhappy Path • The Insane Path • The Evil Path
    37. The Happy Path The user does exactly what we expect them to. Grade A browser.
    38. The Typical Path The user does reasonable things that we expect them to. Grade A browser.
    39. The Unhappy Path The user does things we do not expect them to. Grade A or B browser.
    40. The Insane Path The user is completely insane and clicks things at random (probably whilst humming themes to 80s TV shows and shouting “CRUSH IT”). Any grade browser.
    41. The Evil Path The user is trying to break our site. This person is probably a tester or a hacker. Any grade browser.
    42. Severities Is it worth fixing?
    43. • Blocker
    44. • Blocker • Critical
    45. • Blocker • Critical • Major
    46. • Blocker • Critical • Major • Minor
    47. • Blocker • Critical • Major • Minor • Trivial
    48. Blocker The piece of functionality we have built does not work correctly when the user is on the Happy Path. A user on the Evil Path is able to cause damage or view private data. No further testing can occur. We can not release.
    49. Critical The piece of functionality we have built does not work correctly when the user follows the typical path. We can not release.
    50. Major The piece of functionality we have built does not work correctly when the user follows the unhappy path, content is obscured or, functionality is inaccessible. We should not release.
    51. Minor The piece of functionality we have built does not work correctly when the user follows the insane path, or there are cosmetic issues with Grade B browsers. We can release.
    52. Trivial There are minor cosmetic issues with Grade B or C browsers. We should release.
    53. Terminology What is a bug and what is a defect?
    54. A Bug A bug is a problem found with functionality we have recently developed that is being tested.
    55. A Defect A defect is a problem we have found that is not related to current work.
    56. SEERS
    57. SEERS • Screenshot
    58. SEERS • Screenshot • Environment
    59. SEERS • Screenshot • Environment • Expected/Actual Behaviour
    60. SEERS • Screenshot • Environment • Expected/Actual Behaviour • Reproduction
    61. SEERS • Screenshot • Environment • Expected/Actual Behaviour • Reproduction • Severity
    62. Use SEERS. Save time. Fix bugs properly.
    63. Thank you! Antony Kennedy @booshtukka antony@silversquid.com
    64. Thank you! www.zeroedandnoughted.com Antony Kennedy @booshtukka antony@silversquid.com
    SlideShare Zeitgeist 2009

    + booshtukkabooshtukka Nominate

    custom

    244 views, 0 favs, 0 embeds more stats

    SEERS is a standardised method of reporting bugs an more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 244
      • 244 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 0
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    Groups / Events

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved