Category Archives: Bug Fixes

Recent bug fixes, large and small.

Repro, Cause & Fix: Using Kerika to Fix Bugs

Agile & Scrum, Bug Fixes, Kanban & Lean, Kerika, Team Collaboration, Technology, , ,

Interested in using Kerika for software development? Here’s a practical example, taken from one of our own boards, that highlights best practices for tracking, investigating and fixing bugs.

First, a look at our Workflow

Every software development team will want to set up its own workflow, of course, reflecting its internal dynamics and available resources.  Here’s the Scrum Board workflow we use in our team:

Scrum Workflow
Scrum Workflow

Our Scrum Boards are organized with these columns:

The Backlog contains all the ideas, large and small, that we have on our product road map: in Scrum terminology, it’s our Product Backlog.

The Sprint Backlog is the set of cards that we pulled from the Backlog at the start of this Sprint: right now, only 4 items are left as we are close to the end of our 2-week Sprint Cycle.

Within each Sprint, cards are picked up developers and first moved into the Planning column, where detailed analysis of the work to be done is completed.

Depending upon the complexity of a particular work item, a developer may request a design review before moving the card further into the Development column.

Developers do their own unit testing as part of the Development phase, but then the work item moves further down to the the QA column which frequently includes formal code review.  (More on that below…)

After a bug has been fixed, had its code reviewed and passed unit testing, it gets Deployed to the Test environment.

We usually wait until the 2-week Sprint is over before asking the entire team to present the entire Sprint’s output to the Product Owner for the Show & Tell; this avoids distracting the team midway through the Sprint.

Once the output of a Sprint has passed the Show & Tell, it can then be Deployed to Production.

The Done column shows all the work that got done in this Sprint.  That’s where all cards are supposed to go, but sometimes a work item is abandoned and moved to the Trash.

(Side note: we sometimes use WIP Limits to make sure that people are not over-committed to work, but this is not a consistent practice within our team.)

Logging the bug

Now, let’s take a look at an example of an actual bug card that was worked on by our team:

Example of a bug tracked as a Kerika card
Example of a bug tracked as a Kerika card

(This particular bug doesn’t have a lot in the details, because it is related to another task that is currently underway, and Kerika makes it easy to link cards, canvases or boards.)

Some bugs go into the Product Backlog, if they are not considered especially urgent, but others go straight into the Sprint Backlog if they represent serious production problems that might affect user’s access or the reliability of their data.

Adding bugs to the Product Backlog lets us process bugs along with other development, e.g. of new features, in the same way: everything can be prioritized by the Product Owner and handled through a consistent workflow.

Documenting the bug

Our bug reports typically come with two attachments; at least one of these should always be included so that the developer has a clear starting point for her work:

  • A screenshot showing the user experience (if the bug can be observed directly by the user.)
  • An excerpt from the error log, if the server reported any errors around the time the bug was observed.
Original bug report documents
Original bug report documents

Kerika makes it easy to attach any kind of content to any card, canvas or board: for bug fixing, particularly in the analysis phase, this is very useful if the user needs to include URLs, material from Sourceforge or similar sites, links to Github, etc.

Repro, Cause & Fix

Before any bug is fixed, our developers always add a standard document we call Repro, Cause and Fix as an attachment to the card:

Repro, Cause and Fix
Repro, Cause and Fix

This document is added no matter how trivial the bug.

Why? Because, on average our team goes through about 30-40 cards a week, and has been doing so for years now.  If we don’t document our analysis now, we will never recall our logic in the future.

Repro, Cause and Fix

Repro, Cause and Fix

Our team adopts a consistent layout of the Repro, Cause & Fix document, which we adhere to even for trivial bugs:

The Repro Steps are the steps needed to trigger the bug: usually they consist of a specific sequence of actions taken by a user that cause the bug to appear, but they can also consist of a sequence of events in the background, like specific server activity or memory/CPU utilization conditions, or overall network traffic, that trigger the bug.

The Expected Behavior helps clarify the developer’s understanding of the how the software should behave in this situation.  It’s not uncommon for a developer who is new to the team to misunderstand how a particular feature is expected to behave, which could lead to more bugs being introduced.  Clarifying Expected Behavior in this document provides an easy way for the Product Owner and the Team Lead to confirm that the developer is not going to go down the wrong track.

Introduced Since: our developers try to pinpoint the specific point in the software’s life where the bug was introduced.  This helps the developers reflect upon how errors are created in the first place: the blind spots lie in their analytical patterns that need to be strengthened.

(In this particular example, the developer has been able to point back to some of her own work on an earlier feature implementation that caused this bug to appear.)

Root Cause is not the same as the Repro Steps.  While a specific sequence of actions or events may reliably display the effects of a particular bug,  they only provide the starting point for the analysis; the Root Cause itself is discovered only when the developer examines the code in detail and determines exactly what is breaking.

Affected Feature: all of our code goes through code review, which we view as one of the most effective QA processes we could adopt, but it can be very challenging when you are processing 30 cards each week, each affecting a different part of the software.

Identifying the Affected Feature helps with the code review process, since the reviewer can consider the bug fix in the larger context of the feature that’s being modified.  Without this, it is doubtful that we could review so many changes each week.

Affected User: in most cases, this is “everyone” we offer the same Kerika  to all our users, whether they are on free trials or have paid for professional subscriptions.

Identifying Affected Users is useful, nonetheless, when dealing with bugs that are browser-specific, or service-specific: for example, determining that a particular bug affects only Kerika+Google users, or only Internet Explorer users.

The Fix: OK, this might seem obvious, but this section really refers to identifying the specific modules in the software that will be changed as a result of the bug fix being applied.

Like many others, we use Git for managing our source code — along with Maven for builds — since our server environment is all Java-based.

Fix
The Fix

The Fix section usually includes references to Git checkins: this helps with future bug fixes, by making it easy to traceback sources of new bugs — part of the Introduced Since section described above.

We use separate Git branches for each feature that we develop so that we can decide precisely what gets released to production, and what is held back for future work.

This helps with the Show & Tell phase of our workflow, when the developers demonstrate the output of the Sprint to the Product Owner, who has the option to accept or reject specific features (i.e. cards on the Scrum Board).

Code Review

All of our code goes through code review, no matter how trivial the change:

Code review
Code review

We really believe that code reviews are one of the most effective QA practices we could adopt: having a second pair of eyes look over code can very considerably reduce the chances of new bugs being introduced.

So…

Kerika is great for distributed software teams: our own team is spread out between Seattle and India (roughly 10,000 miles apart!), and all of our work is done using Kerika for task management, content management and team collaboration.

Of course, an added benefit of “eating our own dogfood” is that we are highly motivated to make sure Kerika is the best tool there is for distributed teams 🙂

 

 

Bug, fixed: when you have a lot of boards open, you could run into problems

Bug Fixes, Technology

We found and fixed a problem that a small number of users were experiencing: if you had a lot of boards open at the same time — say around 40 — and you then used the URL of any of these boards in some context, e.g. by including it in a chat message, you could run up into a “502 Bad Gateway” server error.

This really was an unexpected edge case — we had never considered that people might be working on 40 boards at the same time, nor that they would routinely have so many boards open, but it turns out that for professional services firms that use Kerika to manage their different client engagements, this was actually not that unusual…

The underlying problem was obscure: Kerika uses a cookie to keep track of which boards you currently have open.

This helps us restore your session perfectly if you exit Kerika and then return, e.g. by simply closing your browser or actually logging out and logging back in.

In the scenario where a user might have had 40 boards open, the cookie was becoming really, really large (as far as cookies go), and our Web server wasn’t set up to handle such large cookies.

Fixed.

Bug, fixed: handling references to websites that redirect to HTTPS

Bug Fixes, Technology, Usability,

Some sites like Kerika.com use HTTPS all the time: every URL reference, whether to our website, within our application, or even to any article on this blog is automatically converted to a secure HTTPS session.

(We are not the only ones doing this: type in “facebook.com” in your browser’s address bar, for example, and you will be automatically redirected to “https://www.facebook.com/” even though you didn’t type in “https”.)

Always using HTTPS is good security practice, but it can sometimes lead to problems for users: unless you are very familiar with a particular site, and also the type of person who plays close attention to these things, you might not understand this process.

And even if you did, you would still find it convenient to make short references to “kerika.com” (or “facebook.com”) instead of typing out “https://kerika.com”.

When you include a URL in any part of a Kerika board’s contents, e.g. in a card’s details, it’s chat or its attachments (and the same goes for canvases), Kerika tries to get the title of that Web page so the URL reference is easier to read.

We found and fixed a bug related to this: in situations where the URL, as typed by the user, actually resulted in a redirect from the referenced website (typically a “301 permanent redirect” rather than a “302 temporary redirect”), Kerika wasn’t properly showing the Web site’s page title.

All fixed now.

AdBlock was messing up our website (even though we don’t serve ads!)

Bug Fixes, Ephemera, Technology,

We discovered recently, to our considerable annoyance, that it is possible for AdBlock to mess up our website in a really serious way, even though we don’t serve up any advertisements of any sort (and never have.)

Here’s what was happening: when you use AdBlock, you have the option to add various lists of advertising sources. (You can find them here.)

One of these lists is from someone called fanboy.

If you subscribed to fanboy’s EasyList, for example, Kerika’s sign up page would not display the buttons for Kerika+Google and Kerika+Box:

AdBlock problems
AdBlock problems

(The same problem showed upon the Login page as well.)

It turns out that the EasyList filter uses JavaScript classes called social-media-header’ and social-media-button,  social-button and soc-button which were also the names of classes that Kerika was using.

The conflict caused Kerika’s signup and login buttons for Kerika+Google and Kerika+Box to not appear for Chrome and Firefox users who had AdBlock installed.

It took a while to figure out this was the cause.  We are not fans of fanboy.

Bug, fixed: Export notification wasn’t going away

Agile & Scrum, Bug Fixes, Technology, , ,

A small bug fix we did recently: when you do an Export of data from a Task Board or Scrum Board, you get a notification from Kerika when the export completes: that’s because the export could potentially take a long time, if you had a very large board, i.e. with hundreds of cards on it.

(In practice, most exports take just a few seconds, so the notification comes very quickly after you start the Export.)

The notification comes in two forms:

  • By email, with a link to open the file containing your exported data.
  • In your Kerika Inbox, on the top-right of the Kerika application, looking like this:
Export Notification in Kerika Inbox
Export Notification in Kerika Inbox

There was a bug that clicking on the “Dismiss” button on Kerika Inbox didn’t make the notification go away: it would reappear after a page refresh.

That bug has been fixed. Enjoy.

Bug, fixed: adding SharePoint URLs as attachments on cards

Bug Fixes, Technology,

Thanks to one of our users at Washington State’s Employment Security Department, we found and fixed a bug that was causing problems when users tried to add SharePoint URLs as attachments on cards, for Task Boards and Scrum Boards.

The problem turned out to be in some code we have that tries to check whether a user is entering a valid-looking URL.  SharePoint’s URLs are somewhat unusual in that they include the “{” and “}” characters, which most other web servers don’t use.

Our old code was treating these characters as invalid, thereby rejecting URLs coming from SharePoint.

This has been fixed now.

Thanks!

A mysterious grey dot

Bug Fixes, Kerika, Technology,

Here’s one of the weirder bugs we ever fixed: it turns out that there is a tiny grey dot in the middle of every canvas on a Whiteboard.

Grey dot in the middle of the canvas
Grey dot in the middle of the canvas

It’s been there for a while, ever since we introduced some animation to make it easier for people to understand that canvases can be embedded inside cards on Task Boards and Scrum Boards, as well as being used independently on Whiteboards.

But the funny thing is that none of our users, nor anyone on our team, noticed it because too many of us, it seems, eat in front of our computers all too often, so our screens are flecked with little bits of food debris most of the time 🙂

One of our team members finally noticed it after assiduously cleaning his computer screen, and that’s how we discovered there was an HTML element there, with a zero size and absolute position at the center of the canvas (to help with the “exploding” animation effect when a canvas is opened).

Although this element has a height and width of zero, it also has a 1 pixel wide solid grey border, which is used in the animation.

And that’s what appeared as the tiny grey dot in the middle of the screen: one pixel of grey border, not any debris from our lunch.

Another round of bug bashing…

Bug Fixes, Kerika, Technology

Our current release (Sprint No. 37 since we moved to a Scrum methodology!) is focused on bug bashing: mostly server-related bugs, and a few that users might have observed themselves.

This is fairly typical of our development cycles: while we fix major bugs in every release, every once in a while we spend an entire release on just general bug bashing and cleanup.  These offer opportunities to catch up on infrastructure improvements, getting our test cases in better shape and other administrative work.

Release 37 should be done, with testing, by the end of the week: it will have about 65 work items completed, with another 21 items that were trashed.

Trashed items are usually duplicates of bugs: different symptoms with the same underlying cause.