alt='jira screenshot episerver alloy'

How to save maintainance money & time

How to report bugs in Episerver solutions

This is an intended read primarily for clients and service desk managers. However, the vision is to expand it to include all info that could be useful for any Episerver users. So, devs, bring the discussion on!

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, great 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.

Here are things that I thought help developers greatly and save clients' time:
  • Test well
  • Don't speculate on the source of bug
  • Do send us all the info you have
  • Try not to mix bugs and features
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:


  • Client tested very well already => no need for me to test it again (at least to begin with)
  • Looks like it's deploy related => might be something that I overlooked, since it is not slow on other environments, let's check the log file first.
  • The error was stearing at me in the log file => fixed it quickly and all good again, woo hoo!

Summary: 


If you have time or resources to test well, this saves time. If you don't, 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:


  • I need to test a couple of things: first, is the time shown correct? Where, view, edit, admin (in the scheduled job history)? Add Azure environment with UTC as default time zone (that Episerver admin mode shows as-is, but edit adjusts to the client settings) and you can see that this is some testing to begin with. The time was correct everywhere, but the scheduling didn't work. However, the fact that it was reported that the time was wrong got me thinking that it might be wrong in the DB and there might be an issue with how DB was created (there are specific to storing UTC time in Episerver [new in 9.1]). Checked that, all good. 
  • Finally, I started to reproduce this locally and voila, when I run the job, I get a loud and clear error that I could fix. I had nothing to do with time zones. However, no woo hoo this time, I spent quite some time chasing a slightly misleading error. 

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."

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.

Example 3:


Blog's top image.

Summary:


Even if you aren't using any sofisticated system, make sure to do the following:
  • Add a screenshot *
  • In the screenshot, always include the URL (don't cut it out of the screenshot)
  • Add browser info in which you experienced the bug (for IE include the version) - JIRA capture would do this for you
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 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.
comments powered by Disqus