Rules to Better Bug Management and Feedback

​Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see. 

If you still need help, visit SSW Consulting Services ​and book in a consultant.​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  1. Do you know the right way to report bugs and give feedback?

    ​​​​When reporting bugs and giving product feedback, it is essential that you are as descriptive as possible, so that the developer can reproduce the error to find out what the problem is or understand what features you are requesting

    Try to have one email per bug​/suggestion, but if the bugs/suggestions are related or very small (e.g. they are all on the same page) then you should group them together in a single email.​
    Figure: Bad Example - This email isn't going to help the developer much - it is vague and has no screen capture, and gives no alternate way for the developer to contact the user regarding the issue
    Figure: Good Example - This email includes the product name and version, the category of the issue (BUG), a screen capture and contact number, and shows that the user's system is up to date

    Writing detailed emails like the above can be very time-consuming and laborious. Therefore, it is always a good idea to use a template to make sending quality bug reports quick and easy. A great example is the Functional Bug template from the ASP.NET open source project.

    Also, make sure your descriptions are detailed and useful as that can make finding the solution quicker and easier.

    Make sure you always explain and give as many details as you can of how you got an error or a bad experience.

    Where is TV.SSW on the navigation?

    Figure: Bad example - Lack of details
    1. Navigated to
    2. Scrolling down looking for a big graphic like "CHECK OUT SSW TV! CLICK HERE!"
      Me, thinking… "Hmm… let's try the menu at the top..."
    3. About Us? Nope.
    4. Services? Nope.
    5. Products and Support? Nope.
    6. Training? Nope.
    7. User Group? Nope.
    8. Rules? Nope.
      Me, thinking... "OK. Now where? Most likely, the SSW company description will list it..."
    9. Navigates to About Us.
    10. Me, scrolls down… nothing.
      Me, thinking... "OK. Weird. Let's go back."
    11. Me, goes back to homepage.
      Me, thinking… "Is there a site map?"
    12. Scrolls to bottom of page. Clicks sitemap link.
      Me, thinking... "Ctrl+F for TV? Nope."
    13. Me, gives up… types to try and get lucky. Huzzah!
    Figure: Good example - We can easily identify more the one way to improve the UX

    Better than a good description of the bug is a screen recording. This should be followed for a more detailed report. Use Snagit (preferred) or Jing to record your screen.

    Figure: Good example - Recording bug reports in a video can make the issue clearer to see
    Figure: Good example - Giving feature requests via video

    ​Related rules

  2. Do you provide details when reporting .NET Applications errors

    .NET applications can sometimes produce a stack trace of an error, these error messages are all we need to figure out what has happened.  Please do not send us this screen shot, instead, select the top section of what's within this box and paste it in an email that you can send back to us.

    The text within the 'Details' button is more useful for debugging and locating the problem.

    the bug happened
    Figure: Bug details window
    See the end of this message for details on invoking 
    just-in-time (JIT) debugging instead of this dialog box.

    We really want this part:
    ************** Exception Text **************
    System.ArgumentException: invalid sender parameter
    Parameter name: sender
    at WindowsApplication3.FormStart.button5_Click(Object sender, EventArgs e) in c:\datajohnliu\datavs7projects\windowsapplication3\formstart.cs:line 143
    at System.Windows.Forms.Control.OnClick(EventArgs e)
    at System.Windows.Forms.Button.OnClick(EventArgs e)
    at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ButtonBase.WndProc(Message& m)
    at System.Windows.Forms.Button.WndProc(Message& m)
    at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
    at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

    This part is quite useful sometimes too.
    ************** Loaded Assemblies **************
    Assembly Version: 1.0.3300.0
    Win32 Version: 1.0.3705.288
    CodeBase: file:///c:/windows/ v1.0.3705/mscorlib.dll
    Assembly Version: 1.0.1129.31301
    Win32 Version: 1.0.1129.31301
    CodeBase: file:///C:/DataJohnLiu/DataVS7Projects/ WindowsApplication3/bin/Debug/WindowsApplication3.exe
    Assembly Version: 1.0.3300.0
    Win32 Version: 1.0.3705.288
    CodeBase: file:///c:/windows/assembly/gac/ 1.0.3300.0__b77a5c561934e089/
    Assembly Version: 1.0.3300.0
    Win32 Version: 1.0.3705.288
    CodeBase: file:///c:/windows/assembly/gac/system/ 1.0.3300.0__b77a5c561934e089/system.dll
    Assembly Version: 1.0.3300.0
    Win32 Version: 1.0.3705.288
    CodeBase: file:///c:/windows/assembly/gac/system.drawing/ 1.0.3300.0__b03f5f7f11d50a3a/system.drawing.dll
    Assembly Version: 1.0.3300.0
    Win32 Version: 1.0.3705.288
    CodeBase: file:///c:/windows/assembly/gac/system.xml/ 1.0.3300.0__b77a5c561934e089/system.xml.dll

    These are not really useful
    ************** JIT Debugging **************
    To enable just in time (JIT) debugging, the config file for this
    application or machine (machine.config) must have the
    jitDebugging value set in the section.
    The application must also be compiled with debugging

    For example:

    < jitDebugging="true" />

    When JIT debugging is enabled, any unhandled exception
    will be sent to the JIT debugger registered on the machine
    rather than being handled by this dialog.​
  3. Do you know the best way to manage product feedback?

    ​​​How do you want customers to send you feedback? Phone calls? Emails? A website? 
    There are a number of web applications that do a great job on this:

      • UserVoice
      • GetSatisfication​
      • UserEcho​
    codeauditoruservoice.jpg Figure: The UserVoice website allows user to enter suggestions (used here b​y SSW Code Auditor)

    admin.jpg Figure: UserVoice has an Administrator console to track feedback
    UserVoice is the most popular platform to collect, manage, and prioritize user feedback. It has a voting and tickets system out of box.
    Many software houses use this for their products eg. SSW Code Auditor, SSW Link Auditor

    Here are the google results as at 2014​ Figure: Google result of UserVoice​​​

    getsatisfaction.jpg Figure: Google result of GetSatisfaction​

    Figure: Google result of UserEcho

  4. Do all your employees know the quickest way to fix small web errors?

    ​Imagine this scenario... Mary notices a small error on a page in her intranet. She is a good employee... She fires up an email and reports the spelling error to info@s* As she sends it she says to herself "That it took more time to report the error than it would have taken me to fix it".

    Small  errors should be fixed by the person who found it. Text changes can be easily done in SharePoint or WordPress. If you know who is the culprit, it might be a good idea do inform that person, including the things you have fixed.