Improve Mobile App Development Quality By Using A Bug Database

By John Houghton on April 9, 2015

As the owner of a Mobile App Development company, I see a lot of projects go wrong.  In the last article, I talked about the problems of not using a repository and in this article I’ll talk about the problems associate with not using a bug database.  Established developers will wonder why I’m writing about this, and it’s because I see a large number of failed app development projects that don’t use repositories, bug databases, or design documents.  These projects are commonly initiated by non-software developers, and sometimes, serious money is spent and wasted. 

If you’re new to mobile app development, this article will help save you from one of the major pitfalls of software development: not maintaining a bug database.  Newbies will probably communicate their issues in email, but this can quickly become unmanageable.  Bug databases are necessary to help developers organize priorities and prevent time wasted by searching through their inboxes while looking for bug history.  Even on a small project, it’s possible to log dozens of bugs, and if you’re doing it in email, both you and your developer can spend hours per day trying to sort out basic communication issues (more so at the tail end of a project).  A bug database will eliminate this wasted time and keep you and your developers happy (and not quit).  Come to think of it, I should probably write an article on how to keep your developers happy.

When To Log A Bug

Anytime there is a problem (bug) or discrete enhancement with software it should be logged as a bug.  Developers like well written bugs.  A well written bug reduces or eliminates ambiguity and shows the app developer how to reproduce the bug so that they can fix it.  An inexperienced manager/investor/stakeholder will want to get on the phone or on skype to talk about issues, but this is a waste of everybody’s time and developers hate it.  While talking is nice and building relationships is important, you can save a lot of time, money and increase the quality of your software by logging a well written bug in your bug database.

Here are some problems you might encounter if you’re not using a bug database:

– You have 10 issues and you’re using email.  How do you know which has been solved and which has not?  Unless you have a good memory and really know how to keep things straight, issues will cross in your mind and a lot of time will be spent “un-confusing” yourselves.  In a bug database you can easily see which issues are still open with a simple query. 

– You put 10 issues in email, two of them are very important, but the developer won’t know this unless they open all of your emails and read them first.  Not too many people do this and as a result, trivial bugs are fixed first and critical bugs go on the back-burner.  In a bug database it is easy to sort by priority and developers know to start with the P1 (priority one) bugs first.

– You send a list of bugs via email, and the developer tells you that they are all duplicate and have been fixed in the latest build.  Without a bug database, it’s easy to get switched up and work on different versions of the project.  With a proper repository and bug database, each time code is checked in, it is given a “build number” and this build number is referenced in the bug.  In this case the time you spent testing and documenting bugs is lost because you were testing the wrong build.  The opposite problem can happen if the developer is working on the wrong build, or you involve another developer and send them the wrong build.  This can cause endless hours of frustration and because of human error, happens in well organized environments.  An environment without a “repo” and “bug db” can be a nightmare.

Most developers already know these processes, but if the team is large or there are inexperienced members, important to have a “playbook” or set of processes by which the bug database operates.  Here is an example.

When I was at Oracle, we had an awesome bug database and it kept tens of thousands of us organized and marching in the right direction.  Even on a very small project with one developer, it is worthwhile to set up and use a bug database.

How To Quickly Onboard New Team Members

A bug database and repository helps with onboarding.  Let’s say you have a new developer.  One of the biggest challenges is coming up-to-speed and they can get a big leg up by looking at the repository and the bug database.  (Design docs are also great and I’ll cover them later.)  When the repository is updated with new code, the developer writes notes about what was updated and this history is invaluable to new team members.  Same with the bug database.  New team members can quickly go through and see what the team has been working on.  If bugs have been communicated via email the alternative is to share your email account, but you’ll be exposing all of your communication to this person, and giving up your privacy, so that’s not practical.

There are a number of bug database platforms, and one I like is Atlassian.  (I’m a customer of theirs and I’m not being paid to recommend them, nor do I get any other incentives.)

What Does A Bug Look Like?

Here are some basics of what your bug should include:

Date: 4/9/15
Status: Open/Closed/Pending/Verified (depends on your process)
Build Number: 238080
Device Name: iPhone 6 Plus
Type: Bug/Task/Enhancement
Mobile OS Version: 8.2
Priority: P1 (P1 is showstopper, P2 is important, P3 is not so important, P4 is minor)
Description: (Here you list the steps to reproduce)

1. Open App
2. Tap XYZ button (don’t say “click” – clicking is for PCs)
3. Tap ABC button
4. Result: App crashes
5. Expected result: app is supposed to do EFG.

       Here you can write additional notes and/or include a crash log and/or screenshot.

See how simple a bug can be? The other half of this is the procedure manual of what the important fields mean, for example, priority.  I don’t know any company that releases an app with known P1 bugs.  Most companies will fix all P1 and P2 bugs before releasing.  Another important set of procedures is the life of the bug, in other words the statuses it can go through before it is closed and verified as fixed by the person who logged it.  The bug can also be classified as a duplicate, or ‘not a bug’, in other works, this is the way it’s is supposed to work.  A lot of times the tester doesn’t know how the app is supposed to work and this is why you should have an up-to-date design document or PRD.

There is a lot of info you can track in a bug database, but these are the basic fields.  Logging lots of bugs isn’t necessarily an indicator of poor quality work, but sometimes it is.  What’s bad is when a developer tells you that all 10 bugs are fixed, and when you go to check, you find out that 5 out of 10 are not.

Sometimes when a app hasn’t been properly developed, it’s good to show them how you want it done. One technique I like, especially when communicating with a remote team, is to take screenshots or make a flow diagram and send it to them.  PowerPoint is good for this and you can save as PDF before sending it along (they might not have powerpoint).

Use Video

Another technique that can enhance a bug report is a video.  Sometimes if a bug can’t be reproduced consistently, it’s good to “roll a camera” to record the interaction.  This is especially good if communication is a challenge.  For this I use a HoverCam T3 Document Camera.  (I don’t receive compensation for recommending this camera.)  In this situation it’s also important to tether the device and include the crash log.  With some creative camerawork, you can get it all in the same shot.  The video can be especially helpful if somehow the developer doesn’t believe your bug exists.  In other situations it can be good to capture random crashes, where the sequence of interactions is too elaborate to capture without recording.  In Atlassian, it’s possible to attach screen shots or short videos to bug reports.

Summary

So those are two best practices for keeping documentation on your project: maintaining a repository and a bug database.  This can prevent something that happens to me a lot: Someone approaches me with a failed app project and wants me to take it over, but there is no documentation.  It’s hard to figure out what the app even does, what the issues were – both of these dictate in part why the app was coded the way it was.  It’s hard to take over a project that has no history or documentation and it will cost you more to salvage such a project.

I actually see this a lot.  Someone calls me and asks me to help fix their mobile app development project.  I have no idea what the app is supposed to do because there is no design document (a.k.a. PRD, or Product Requirements Document).  They’ve forgotten most of it and the information all sits in a long series of emails, including all the times they changed their mind on the design and now it’s a confusing mess.  It would take days to go through all of this.  There is no repository, so it’s hard even to find out which is the latest version.  There is no bug database, so there is no history to help me understand why things are the way they are.  In these situations, I frequently also find that the project was poorly developed and it would be more cost-effective to start over.

Next Article (maybe tomorrow): Why Your App Project Needs A Design Document

Posted in Android Apps, App Development, Apple TV

Comments

Comments