Tag: Education

5 Ways to Improve Your Bug Titles

I originally posted on the uTest forum here.

Bug titles are one of the most important pieces of you bug report. They are the face of your bug, they show the its value and can help or hurt the overall efficiency of the test cycle. Far too often testers don’t give their bug titles the attention they deserve. This post will try to change that. Here are 5 tips to help you improve the titles of your bug reports.

Consider Your Audience

Like the bug report itself, the title is intended to convey information. The main difference is the title is more concise. A well written title will quickly and clearly summarize the bug and its value.

To communicate this information effectively, you need to consider your audience. Bug titles are read by different audiences who may use the title for different reasons. Testers have the difficult job of writing a title that satisfies the needs of two different audiences at the same time: The customer and your fellow testers.

Customer
When the customer or Test Team Lead (TTL) reviews the bug list, one of the first things they do is look at the title. As we talked about in Reporting High-Value Bugs – Part 2, part of reporting high-value bugs is “selling” it to the customer. The title of your bug is part of your sales pitch. Always keep the title short and to the point. You want to focus on the end result, not the actions. For example:

Use “User profile – Unable to link to Facebook” instead of “Clicking the ‘Link to Facebook’ button doesn’t do anything”

Also use words that action words that convey importance such as ‘prevented’, ‘does not’, ‘inconsistent’, ‘unexpected’ etc.

Fellow Testers
Your fellow testers use the title of your bug in a very different way. They use it to determine if the bug they found has already been reported. To help them, you need to include the key words they will be searching for.

Hopefully, before you report your bug, you search the bug list see if it has already been reported. Make a note of what you searched for because those are the words you should consider including in your title.

In Reporting High-Value Bugs – Part 2 we also talked about reporting the root cause of the bug. The same is true for the title. Your title should describe the underlying problem, not one of its many possible symptoms.

Follow the uTest Standard

uTest has a crash course dedicated to Bug Title standardization so I’m going to point you there first: http://help.utest.com/testers/crash-courses/general/bug-title-standardization

To summarize that post, every bug should be broken apart into two distinct parts. The “Area” and the “Description” The area is the place in the application where the bug occurs. The description is a brief summary of the bug. These two areas should be separated by a hyphen.

For example, in this bug title:
Homepage – The ‘Contact Us’ button is linking to the incorrect page
“Homepage” is the area and “The ‘Contact Us’ button is linking to the incorrect page” is the description

This can get a little tricky when the area is deep in the application. If there was a bug in the uTest platform on the payments screen in the Account & Settings section how should we identify that area?

In the link above, one of the authors suggests you write it like this:
Account & Settings – Payments – Total payout amount is incorrect

Personally I don’t like this suggestion. Testers who do this tend to put the navigation steps in the bug titles. That is not the place for that information. Plus having more than two sections makes the title difficult to read.

I prefer to list only the broad area of the application and include the more specific area in the description. Here is how I would write this title:
Account & Settings – The total payout amount on the Payments page is incorrect

Do Not Specify the Test Environment

Many testers include the device or environment they use to test in the title of their bugs:
[iPhone 5] User profile – Unable to link to Facebook

The landscape that we test against these days is so large that it’s no wonder that this has become more common recently. Testers feel that the device they found the bug on is an important piece of information. While that is true, the title of the bug is not the right place for it.

The main reason that this is a bad practice is because it gives false impression about the scope of the bug. Generally when testers start their bug title with the environment, they are simply stating the device that they found the bug in. But the customer may interpret that to mean that this bug is only present on that device listed in the title.

Unless you have tested against every other possible device/environment, don’t include this information in the title. It adds little value and can actually cause problems.

As with most rules, there are exceptions. Here are two:

Explicitly required
If the cycle specifically tells you to include environment information in your bug titles, you should follow the instructions.

For example, this is directly from a test cycle I recently was on

NOTE – If you find an iPad bug: Please add [iPad – iOS xx] at the beginning of you bug title.

In this situation it is perfectly fine (and even required) that you include the environment in your title.

However, you may see something like this in the instructions:

BUG TEMPLATE: Please include the following info in all your bugs: Mobile device model and OS version Description of bug Wi-Fi or 3G / 4G?

This does not mean that all this information should be in the title. It simply means that it should be specified in the body of the bug. Generally you should put this information in the ‘Specified Environments’ or ‘Additional Environment info’ fields. It is the “Bug” template, not the “Bug Title” template.

Environment specific bugs are allowed
Occasionally a cycle will allow the same bug to be reported for different environments. In this case, each one of these bugs is considered different by the customer. Since the only difference between the bugs is the environment, it is necessary to include the environment in the title. Otherwise you would have multiple bugs with the exact same title and your fellow testers would have to look at the contents of the bug to see which environments had already been reported.

Keep Consistent with Earlier Bugs

Sometimes a cycle will ask you to include some extra piece of information in the title. One example of this would be the build of the application that you tested. What I usually see happen in these situations is every tester comes up with their own way of including this information. The result is a messy bug list that looks something like this:

[b 123] Area – Description
build 123 => Area – Description
Area – Description {build 123 v.2.045.34}
123 Area – Description

This is difficult for the customer and TTL to read and makes it impossible for them to quickly scan through the list.

Assuming that the earlier bugs followed the uTest standard and everything we addressed above, you should follow the pattern established in the first few bugs. Don’t worry about being original or sticking to your own personal preference, the goal is consistency. This will make the customer’s and TTL’s jobs much easier. See how much easier this is to read?

[b 123] Area – Description
[b 123] Area – Description
[b 123] Area – Description
[b 123] Area – Description

Learn From Other Testers

You can learn quite a lot from reviewing the bug reports of your fellow testers. You can see different styles of reporting the reproduction steps, come up with new ideas of how to test, and see which types of devices are the most common.

The same can be said for the bug’s title. When you are reviewing bugs, don’t just skip over the title. Instead, take advantage of the opportunity to learn from the mistakes and successes of others.

First evaluate the title of the bug first on its own:
Does the title follow the standard? Does it include appropriate key words?
Then look at it in the context of the entire report:
Does the title accurately and efficiently summarize the bug? Does it “sell” the importance of the bug?

As you pay more attention to your own bug titles as well as the titles of other bugs, you will start to see the types of patterns we have just talked about. It will become apparent that the testers who do these types of things are the ones that are separated from the crowd. Bug titles are extremely important and should be treated that way. Keep these tips in mind and you will be one step closer to writing the perfect bug report.

I’d love to hear your thoughts on this topic. What other tips can you give your fellow testers?

Strategies for a Testing Career – Part 1

I am reading through a book of articles titled “On Strategy”. It is published by the Harvard Business Review and the context deals with business strategy. What I have found is that even though the intended audience is business managers, the lessons can easily be applied to individual testers. As I read and study each article, I will write a post summarizing the content of the article and how testers can apply the lessons to develop their own strategy.

What is Strategy?

by Michael E. Porter

Operational Effectiveness Is Not Strategy

Operational Effectiveness (OE) means performing activities better, faster and with fewer inputs and defects then your rivals. The quest for productivity, quality, and speed has spawned a remarkable number of management tools and techniques. Enormous advantages can be gained from OE, but from a competitive standpoint, the problem with OE is that the best practices that drive it are easily emulated. When competitors both strive to achieve the best possible OE, the competition between them produces absolute improvement in OE (everyone is more effective), but relative improvement for no one and the more indistinguishable the competitors become. The pursuit of OE is not a bad thing, in fact it is a necessary part of strategy, but OE itself is not a strategy

As testers, we too pursue common tools, techniques, and procedures to do our job more effectively. Quality Center, Test Manager, test plans, test cases, bug tracking, and defect metric are just a few examples of the many ways the testing industry has enable testers to chase OE. As all testers attempt to become that sought-after tester they too fall into the trap of trying to become that one ideal tester. We all are want to become QC experts, and automation specialists, but as we all pursue that goal, we all become more and more similar which is contrary to our goal of standing out from the crowd.

So what is strategy? How do I as a tester establish my strategic position?

Strategy Rests on Unique Activities

Strategy is all about being different from your competition. Our competition as testers would be anyone who has the same goal as we do. For example all other testers that are applying for that job we want or the opinionated blogger who has the ear of the testing community that we envy.

Strategic positioning means performing different activities from rivals, or performing similar activities in different ways.

A perfect example of doing different activities is Jame Bach. Almost everything he does and teaches is exactly the opposite of what most “factory” testers do. While your average tester is pursuing certifications and following test cases, James supports open learning and exploratory testing. As a result, he is one of the most well know testers in the world. No doubt he is an amazing tester, but the reason he stands out is because he is so different from everyone else. He’s loud, sarcastic, opinionated (none of this is meant as a slight by the way) and people listen.

Almost every tester out there is experienced in Quality Center. Knowing how to write test cases or track bugs is expected and it doesn’t set you apart, but there are ways to do those similar activities in different ways. Consider learning about lesser know bug tracking software such as Kiln, or possibly create something totally new yourself. Try to find a new way to perform exploratory testing within an Agile testing environment.

A Sustainable Strategic Position Requires Trade-offs

A strategic position is not sustainable unless there are trade-offs. Trade-offs occur when activities are incompatible. For example, if my strategy is to be a white-box manual tester, then I should ignore learning about Selenium automation and focus on manual testing and coding skills. Pursuing both would split my available time and effort effectively making me a lesser white-box tester. Trade-offs mean more of one thing necessitates less of another.

Sustainable means that over time, your strategic position will erode if you try to do everything. You may be able to get by in the short term, but as you spend more and more time on non-strategic activities, your core skills will suffer and it will become apparent as others (who made the trade-offs) surpass you.

Fit Drives Both Competitive Advantage and Sustainability

Strategy is all about combining activities to give you that unique strategic position. Fit describes how those activities tie into each other. One activity’s cost can be lowered by the way other activities are performed. Similarly, an activity’s value to your strategy can be increases by effectively “fitting” it with other activities.

I want to become known as an expert tester. My strategy to accomplish that, in part, includes becoming knowledgeable in my field and sharing that knowledge with others. Learning and blogging “fit” because they both contribute directly to my goal, and each complements and improves the other. Learning give me something to blog about, and blogging helps me to better remember and reflect upon what I’ve learned.

Conversely, we need to be aware activities that don’t “fit” our strategy. If I decide that I want to be a context-based exploratory tester, will getting a certification from ISTQB contribute to that goal? does it “fit” with the other activities of my strategy?

Rediscovering Strategy

There are two distinct views on strategy. One is the idea of competing head-to-head with your rivals on the same things, the other is establishing a unique strategic position that provides a competitive advantage. Here are some characteristics of both views.

Head-to-Head

  • One ideal competitive position in the industry
  • Benchmarking activities to achieve best practices
  • Outsourcing and partnering to improve efficiencies
  • Focus on a few success factors, critical resources, and core competencies
  • Flexibility and rapid responses to competitive and market changes

Unique Strategic Position

  • Activities tailored to the strategy
  • Trade-offs focus activities
  • Fit across activities
  • Focus on the entire system, not individual parts
  • Operational effectiveness is a given

There are two points I took away from this article that I think are extremely valuable. First, we as testers need a strategy. Strategy isn’t something that should be left to managers of  big companies, it can and should be applied to individuals. And second, imitating what others are doing is not a strategy, it’s an anti-strategy. The only way to give ourselves an advantage over our competition is to have a unique strategic position based on trade-offs and carefully aligned activities.