Tag Archives: Bug

Thanks to a longtime user from Poland, we discovered — and fixed — a bug that crept into one of our recent feature enhancements, where items couldn’t be permanently deleted from the Trash column on Task Boards and Scrum Boards.

With the proliferation of top-level domains we have had to update some of our old code that tried to make sure people were signing up with properly-specified emails.

In the old days, of “.com” and “.org” and other short domain extentsions, this was easy to check at the time someone entered an email address: if it wasn’t properly formatted we could alert the user right away so they didn’t go down a dead-end path.

We can’t do that anymore: new top-level domains are being launched on a regular basis by registry companies and the list of potential domain extensions is no longer finite or easily matched by regular expressions.

If you create a list of tasks on a card on a Task Board or Scrum Board, Kerika does a bunch of stuff in the background to make sure your view of what’s due, at the card level, board level and account level, are always correct.

We found a couple of edge cases where the due dates on tasks wasn’t rolling up correctly to the card level, potentially giving users a misleading view of what was currently due for them:

When the last task with a scheduled due date was removed (deleted) from a card, this wasn’t correctly adjusting the due date for the card itself.

Similarly, when the last task with a scheduled due date was no longer scheduled, this wasn’t correctly adjusting the due date for the card.

Both bugs have been fixed. They were real edge-cases, so it’s likely that most users never noticed them in the first place, but still…

We found and fixed a bug that was kind of annoying, even if it affected only a small handful of users: if you transferred ownership of a board to someone else, that board wasn’t appearing correctly in the Shared With Me tab of your Home page.

Thanks to our users at Oxbow Farm, we have found and fixed a bug that affected users who signed up directly with Kerika: clicking on an attachment in the card details was downloading the original version of a file, not the latest.

Here’s what was happening: when you add a file to a card or canvas, Kerika checks to see if that file was already being used on that particular card or canvas. If so, Kerika automatically handles your latest upload as providing a new version of the old file, so you see just one entry in your card attachments view:

The bug that we recently discovered, and fixed, resulted in Kerika downloading the original version of the file when you used the download option that appears after you select an attachment from the list of attachments on a card.

If you clicked on the attachment’s thumbnail to open a preview of the file, Kerika was correctly opening the latest version of the file. The bug was only in the download action, and that’s been taken care of now.

We found and fixed a bug recently that was stopping Account Owners from inviting people to join a board team, unless the Account Owner herself had a specific role in the team (i.e. was a Board Admin or Team Member).

This isn’t how it is supposed to work: Account Owners have all rights to all boards that are owned by their accounts, which means they can change the board team on any board they own.

Unexpected bug we encountered recently: an attempt to sign up as a Kerika user, using our direct sign up process, failed.

When we looked into the error logged on our server, we discovered that this user was trying to enter a first+last name combination that came to 42 characters; our code assumed that no name would exceed 40 characters in length.

Digging a little further into the user scenario, we discovered that these were accounts that were being opened in the name of organizations, or departments within an organization, rather than actual people.

So while 40 characters may have been enough for most “real people” names, it wasn’t enough for department names, e.g. something like “Kerika Marketing Communications Team”.

Thanks to one of our users from Washington State’s Administrative Office of the Courts for pointing this out: it turned out that the count of “remaining” cards in the Board Summary was including items that were in the Trash, which was misleading.

This has now been fixed: the count shown in the Board Summary gives you a better idea of what work remains.

To access the Board Summary on any Task Board or Scrum Board, click on the Board Summary button shown on the top-right of the Kerika app:

Board Settings is highlighted

Clicking on this button will show a summary of the board, like in this example:

Remaining work

In the example above, the count of “28 items remain” now properly excludes any items that are in the board’s Trash.

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

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

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

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

(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

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

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

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.

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.

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

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 🙂