Monthly Archives: June 2013

They say the US and the UK are very much alike, and only separated by a common language. Although this is intended to be humorous (which I think it is), there’s a little more to it. Anyone who has taken a taxi in New York City, and then somehow managed to experience a taxi ride in London can attest — there’s just no comparison.

Did you know London taxi drivers usually spend anywhere from 2-4 years learning and being tested (written and oral) to achieve the position of a London taxi driver? I didn’t until I started to write this blog. My point is that London taxi drivers take their role and position very seriously. Their taxi’s are uber clean, the driver knows exactly where he needs to go without calling back to his garage for directions, and they don’t use navigation systems. That’s right — they must memorize over 2500 London streets to pass their exams. They see themselves as professionals, and mini-business owners. They care about the fare they carry, their luggage and even though most of them are not ‘touristy chatty’, all of them want to ensure visitors and non-visitors alike move around London under their watchful and careful driving.

If you take a taxi in New York City… not so much. You will usually get a driver that speaks English… though likely with a strong foreign accent, but that’s okay. They will get you where you want to go and often by using technology (navigation systems), or calling back to their garage for additional help. The taxi will likely be well worn; many without shocks because potholes really do a lot of damage to them… so they just don’t replace them. Most taxi’s are quite dirty as well. It’s sad, but that’s my experience for the most part, and I am in NYC quite a lot.

But the real difference, and the point I’m making here, is work ethic. London taxi drivers will do more than simply take you from point A to point B. Returning to the US recently, one actually dropped me at Heathrow and told me to wait in the car while he made sure Virgin Atlantic was open at that early time of morning. Then, he helped me with my luggage; and not just out of the trunk and onto the curb, but in through the terminal door, and pointed me in the right direction to the counter. I don’t see any NYC taxi driver doing that! The message? You’ll enjoy your London experience even more with the help, support and guidance of taxi drivers who really care about your experience traveling in their taxi!

It’s all about customer service! Pure and Simple! And, you know what? I gave the London taxi drivers better tips, too.

Throughout the different stages of the software lifecycle, bugs – or defects if you prefer – are written by many different people who have many different perspectives. Some of these bugs will bounce around between different individuals on a project team quite a few times while others will be processed quickly with little fuss. The defects that are most likely to cause the most activity usually exist because of unclear requirements or because of poorly written defect write-ups. The goal of a good bug report is to allow a developer to reproduce the problem. In this post, we’ll discuss poorly written bug write-ups and how we can make bugs into more effective tools.

Without clear requirements, people often make incorrect assumptions about what should happen in the project. In the same way, poorly written bug reports lead to assumptions about what and where the issue lies, and the project team wastes unnecessary time and money determining the real source of the problem. We’ve all seen these poorly written bug write-ups, some as vague as “feature x crashed” and others that are a convoluted mess of multiple issues. It’s not just developers who suffer when bug reports are written poorly; testers who have to test a “fixed” bug when there isn’t enough information will be left to guess whether the issue is truly fixed, often resulting in a back-and-forth between QA and Development. These multiple-issue bug reports can also throw off statistics for future estimates of testing or regression times. So, everyone on the project team benefits when the bug writer takes a little extra time to make sure the bug details are as clear and succinct as possible.

Clearly stating where the problem occursIf there are multiple areas where something can be done, be clear about which places the problem happens and which places the problem does NOT happen.

Easily repeatable steps

Clear actual results

Clear expected results

Keeping each write-up about a single specific issue

Including all details pertinent to reproducing the bugSpecific browser being used if the issue is browser dependent, data points needed, user roles, etc.

Excluding details that confuse the issueWhile you may have gone to 15 other dialogs before the issue was encountered, keep the information to just the steps needed to reproduce the issue.

For all of us who write up bugs, it’s in our own best interest (as well as the interest of the development team that needs to get them fixed), to make sure we write them up well the first time so we don’t waste our own time resubmitting clarifications or steps that could easily have been there in the beginning. The product will be better, and that makes for delighted clients. Take a few extra moments to review your own write-up at the beginning to save everyone time later in the project.

I recently had a discussion with a friend who owns a small business and needs a web application to run day-to-day operations. She’s a pretty savvy person but has a limited technology background. She came to us looking mostly for help in laying out the requirements, and how to hire a contract developer. But software can be a complicated business with thousands of little questions and details lurking around every corner, so we wanted to give her some advice to help her avoid the pitfalls. Here were the key takeaways.

Define the Scope

First, be clear about the scope and what you are trying to accomplish. For many projects, a phased approach is best, especially for smaller companies with more limited resources. Trying to do everything in a single release costs too much and takes too long, which drives up the risk. If you have finite time and resources (and most of us do), every addition to scope is a potential subtraction to quality control and keeping to your delivery schedule. You are better off determining what you absolutely need to get out the door in phase 1, letting it generate revenue while you plan for your next release. Be ruthless about cutting features. Often what you leave out is just as important as what you put in.

Screen Mockups

Once you have an idea of what you are building, you should make screen mockups to clarify which screens you need in your application and what is on them. You can include brief notes with the mockups to point out key details or functionality that is not obvious. You should have at least one mockup per screen in your application. Screens that have different modes or layouts may need multiple mockups to fully illustrate what is going on.

I like to start out sketching on paper; then once I have a rough idea of the layouts and content, I use a mockup tool to do more comprehensive mockups. My favorite tool for this is Balsamiq (http://www.balsamiq.com/). It’s cheap, easy to use, and gives great results. The key here is to focus on layout, content, and function, not colors, graphics, and making things look pretty.

User Stories or Workflows

Now that you know what screens you need, it’s time to write up workflows (sometimes called user stories) to explain how key features will work in the application. You know that hand-waving you’ve been doing about how customers will find a product, add it to their cart, and check out? Now is the time to get down to specifics: which page are users on at each step? Which button is the user clicking on each page? Simple workflows can be done in a bulleted list, while more complex workflows may require a flowchart or other diagram. This helps you understand how your screens work together, and the application as a whole.

Requirements

Mockups and workflows fall into the general category of requirements, but here I’m talking about other details that are not easily captured in these earlier efforts. If you want your application to do something specific, you need to write it down. The more detail you can provide, the better you understand your application and the more likely you will get what you expect from your development team. Here you can list out details for each screen like how to handle errors, how many characters each text field should hold, and anything else that you can think of that is important.

Summary

Software applications contain thousands of details. What color should something be? What happens when a user clicks this button? How long should a product name be? (30 characters long? 100 characters long?) Developers have to make dozens of decisions about these kinds of things every day. If you don’t make these decisions up front, your developer will make them for you, and they may not always do what you want. Good developers know what details matter and require additional input from you without bothering you with trivial issues, but they are not psychic. The more you clearly understand your application and can convey it to the development team, the more likely you will get what you expect and have a successful development project. Good luck!