It's never an easy task to work on support. You have to take into account environment issues, bug is rarely easily reproduced locally; without constant development on any project, it's always some time one needs to dive into it again. Suma sumarum, good issue definition helps us catch the nasty little bug quicker and more effective. Cost and relation-wise, client is happier, we are happier. Everybody involved prefers to spend time on new features anyways.
Let me ellaborate a bit through some positive and negative examples.
Test well
Example 1:
I was recently lucky to have a great example from a very thorough client: "Website is extremely slow in view and edit mode for any page type. Admin mode seems decent. Tested from one country, confirmed from the others. Appears to have started after yesterday's deploy. Test protocol below:
...
8:28:00 am - click on pinned top news - 1:23 until page loaded
9:33:30 am - click on episerver widget - 3:37 min until fully loaded including pinned navigation and asset pane
..."
Result:
Summary:
If you have time or resources to test well, this saves time. If you don't, that's fine, too, but it will take more from the developers - we need to test, measure, reproduce before we can head to it.
Don't speculate on the source of bug
Example 2:
Bug: It looks like the time in the system is wrong
Description: I have had several issues where a scheduled post has not been published and now I discovered that the website is not showing correct UTC time.
Result:
Summary:
Make sure to write the undesired behavior only, not something that might be causing it, in this case, the best description would be: "Delayed publishing doesn't work. On any of the pages and page types that I have tried doing this, when I schedule the publishing, it doesn't get published."
Do send us all the info you have
In majority of issue tracking systems, there are tools that can help capture additional info that might seem irrelevant for you, but for us, developers, it's beneficial. We, at Mogul, use Atlassian JIRA and its product called JIRA Capture. It is a Chrome add-on and it opens a window that looks similar to the screenshot on top of this blogpost. When we don't have all the info, this expands the Q&A loop, we need to ask for more details, wait for them or try to chase the wrong bird. Getting educated in using a system of this kind is beneficial for the effectiveness of any development work.
Summary:
Even if you aren't using any sofisticated system, make sure to do the following:
To create a screenshot, you might want to use a free tool called Lightshot. You can easily install it and by clicking prt sc (printscreen with optional fn for some keyboards), you get similar options to the one in JIRA Capture (without saving it directly to JIRA ofc) with possibility to either save to disk or immediately upload to prntscr cloud (not to be done when screenshotting priviledge info).
If you can't explain the case when a bug occurs or feel that there is some kind of misunderstanding, you might want to use LICECap and record your screen. It's a free gif recorder that a fellow EMVP Alf Nilsson recommended me a while ago. It is great tool for recording short interactive screen captures.
Try not to mix bugs and features
Example 4:
This doesn't work, but could you also make this bigger and is it possible to change this behavior to that...
Result:
This gives us headaches with estimates, especially with nice-to-have features. We need to divide this into subtasks, then estimate each, report back and if there are any interconnections between subtasks, we need to take into account combinations of features. Then, quite often, the nice-to-haves are prioritized in next sprints, since they aren't urgent/important.
Summary:
Please add one issue per bug/feature, then it can be estimated well, bugs fixed quicker and new features prioritized easier.
LEAVE A COMMENT