Saturday, 21 January 2012

The Art of Bug Reporting


Submitting effective bug reports is more difficult than people realise, anybody who has experience in Software Development, Game Development or Quality Assurance (QA) have received at least one bad bug report and maybe even written one themselves (I know I have). Reports that read "Crashed, I have no idea why", reports that contain little or useless information, reports that are abusive and give wrong information.

If you're starting your first QA position, thinking of a career in QA or you are a regular
 bug reporter, this post will hopefully provide useful tips for everyone.

This post isn't related to any particular software, it's just my experience working in QA/Technical Support over the past few years. This post contains guidelines, I am not saying this is how bugs should be reported and that these are rules or laws which everyone should follow. Some software packages and programmers have specific guidelines on how they want bugs reported so it can vary depending on the type of product your using or company guidelines.

First Thoughts:

Experiencing an unexpected bug can be frustrating and also make some users quite angry, a sudden crash or freeze is the most common cause as you may be deprived of any unsaved work, first thing to do is take a timeout to calm down before beginning to write the report.  

Remember, a clear and concise report will lead to bug fixes and improved software quality. A badly submitted bug report can lead to many things which can prolong the fix; automated closure, exchanging emails for weeks, report may not be looked at for while, these all delay the bug getting fixed.


The goal or mission for a bug report is to enable the programmer to see the software failing. Working in a QA position within a company can give you a couple of options to achieve this mission; You can write clear and detailed description with reproduction steps or invite the programmer to your desk so you can show them in person.

Programmers know the code they have written, they will have feelings about what areas are most trusted and what area's are likely to include faults, so by showing them the bug in person can give programmers clues towards finding the cause of the issue.


So what do I include in my bug report? Well, that is a good question, I tend to follow five key areas:

1. Title: A short one line description where a programmer should be able to understand what type of bug is being reported.

2. Description: Description is a more detailed paragraph which should be clear and informative, a programmer should be able to picture in his/her mind what is being described and imagine the bug reproducing.

3. Reproduction Steps: Also known as repro steps, this is a list of clear and easy to follow instructions, documenting every input and action you took to reproduce the bug.

4. Actual Results: Usually a one line reading what happened when following the above repro steps. "The application crashed and closed".

5. Expected Results: This is usually one or two lines where the user writes what he/she expected when following the repro steps.

After writing the above into your report, additionally you can record a video and also take screenshots and attach these to the report. Screen capture software is available and some are free. Screenshots are easy to take, for Mac you can use the Grab application & for Windows the standard printscreen key or for Windows 7 users the snipping tool. Screenshots and Videos are great for capturing that sometimes illusive error message, makes it easier then typing a series of digits and numbers where a typo could be introduced.

Proof Read:

Before clicking that all important submit button proof reading what you wrote is important for ensuring the report is clear and easy to understand. If you wrote repro steps, try to follow them and see if you missed any steps.

I really take a lot of pride in writing a good bug report, I get a good sense of satisfaction and I will continue to explore new methods to do better. I hope this post has been somewhat helpful and informative.

Friday, 23 December 2011

It's Christmas Holidays!

Wow what another awesome year it has been working at Unity Technologies! It truly has been a great year full of exceptional development, ground breaking releases, our biggest Unite conference ever, 750,000 registered developers and to top that we just shipped our beta development preview of Unity 3.5 just in time for Christmas, arguably our biggest release yet, with many new features including support for Flash deployment and Google's Native Client, we all hope you enjoy this gift while enjoying your Christmas holidays! If you missed the download page you can grab it here:

On a side note I have got back into the swing of 3d modelling, this is something of a passion for me and I really am enjoying it.
I am using a 3d package called Modo and it's currently a learning experience for me, it's different to 3d Studio Max which was what I was introduced to.

I am currently working on a project, modelling the interior of a small flat which I have exported out of Modo and into Unity where I will eventually texture and set up lightmapping. My thoughts are to use Substance materials to texture the interior, my reasons for that is simple...they look amazing.

Here's a sneak preview of the modelled interior in Unity:

Feel free to keep up to date with me on Twitter! Catch you later and have a very Merry Christmas and Happy New Year!

Friday, 12 August 2011

3D Asset Creation.

There are so many ways to create assets such as characters to environments and various props using such products as Autodesk's range, Modo, ZBrush and the open source Blender for our games, but what I am writing about this evening is how the creation of assets could all be changing in the near future.

This short blog this evening starts of with the mention of tablet technology, the all to familiar iPad from Apple, this has really changed the way the games industry and it's consumers are playing games these days, but what's also interesting is it could also change the way game developers create assets for our games, let me explain.

You may or may not have heard off a certain app called TreeSketch, with this app the user can create tree's by touch, drag and release, doing this action paints a tree with branches and leaves onto a canvas. I wrote about this app previously with my Unity Technology blog here: (at the time it was called TreePad) please read, it will give you more of an insight into the app itself if you don't have it installed already.

Getting back to the idea, this app has a great feature where the user can export the tree as an .fbx file, unfortunately this doesn't include the materials and textures inside the app due to licensing issues I believe but nevertheless you can assign materials and textures to the tree in an engine such as Unity. Here is a video from Steve Longay demonstrating how easy this is to create a 3d interactive tree: I am quite confident this is easier then creating tree's in various other modelling packages but I am sure I'll be proved wrong.

There is also another app which I only discovered today and one I have been hoping someone would develop, Autodesk have released a 3d sculpting app which users can customise one of seventeen base models with a range of sculpting and detailing tools, and the added feature which is cool, stencil photo's on top! Photos can be imported or captured directly with the iPad 2 camera!! The base models range from human head, full scale human body, animals, shoes, t-shirt and a car. View video here: 

123D Sculpt
The downside of this app at this moment is no feature to export the models as .fbx or .obj files but hopefully Autodesk will implement this with a future update. If that feature does make it into an update that's already a nice range of assets you can create/sculpt and export on the move for your video games and with great ease. I am not sure of how many artists do 3d modelling on their laptops while on the move but I think with the tablet technology combined with these great apps now it's possible to do this with ease and while having fun at the same time.

To sum up,  whether or not this will change the way game developers create art assets for games remains to be seen, it appears the technology is there, now all we need is more apps! This can also be used as a great education experience for young game developers at college or universities, either way this new asset development pipeline will make some impact in the industry.