Fortunately when some of our customers feel that way, they share the results. Here’s a roundup of recent test related Third Party Tools to help you make the most of your bugs in Tracker.

Bugherd is a website annotation tool, that lets you capture bugs, feature requests, etc.,  by clicking the offending element on your pages using BugHerd’s simple overlay. With this integration, this feedback can be sent straight to Tracker.

Bugsnag allows you to automatically create bug stories in Tracker when a crash is detected in your web and mobile applications.

HoneyBadger error management app users can link their apps to their Tracker projects. When a bug comes in, they can press a button to create a story. The bug stays linked to the story so that users can easily jump to Tracker from Honeybadger.

PivotalFeedback can be hooked up to a “Feedback” link, for example, to allow users to easily submit bugs, features, and chores to Tracker, with all the information you need.

Testrail is a test management tool for QA and software development teams. It integrates with Tracker so you can link test results to stories, push bug reports and look up the details of stories directly from TestRail.

Redline allows  anyone to point out bugs directly onto a web page without having to sign in to Tracker. Instead, their notes auto-generate a story in Tracker, along with a URL that shows the markups on the original web page.

Don’t forget to look in on the integrations we’ve created as well, including Bugzilla, Lighthouse, Jira and the ability to create connections to other tools in Tracker.

The post 6 Third Party Tools for Automatic Bug Creation and More appeared first on Pivotal Labs.

In such situations, the Viewer role in Tracker is just what you need.

Only a project owner can manage roles and that’s done on the project Members page. There are a few ways to get there, for instance:

Mouse over the project name on the left side of your Dashboard and click Members

or
View the stories in your project and select Add/Remove Members in the PROJECT drop-down

Once you’re there…

To change a Member’s role to Viewer:

At the project Members page:

1. Select Viewer from the Role drop-down to the right of the email address for each person you wish to change the role for.

The change is immediate and will apply to this project only. So if you have more than one project in your account and want to reduce the number of collaborators in that account, please repeat the above for the same person in all projects in the account.

To add someone to a project as a Viewer:

At the project Members page:

1. Enter their name or email in the Add Member field, then select Viewer in the drop-down directly to the right of the field (the default is Member)

1. Click Add and fill in any further information you are prompted for, etc.

or

1. Click the “Add members from list” button.
2. Select the Invite checkbox for each person you wish to add.
3. Select Viewer from the Role drop-down to the right of the email address for each person you are inviting.
4. Scroll down, if necessary, and click the “INVITE CHECKED” button.

Feedback

We hope this helps you get more out of Tracker. As always, we value feedback, so we’d love to hear from you in the comments here or on Facebook, Twitter, or by email to tracker@pivotallabs.com.

The post The Viewer Role: Giving read-only access to your projects appeared first on Pivotal Labs.

Roles and activities

The web site allows people to do all the typical things you would expect while shopping online. Customers can browse for products, search for specific items, put them in a cart, sign up for an account to track their orders and make future shopping more convenient, check out, etc.

To help us design the site, we want to identify all of the key “activities” for all user roles. To start with we can think about admins who will stock and manage the site, and shoppers who actually use it. Each has a specific set of wants and needs that we might consider as stories that will be entered in Tracker. As well as feature stories, there are activities to do with setting up hardware and infrastructure for the site which can be added as chores.

As we think about these activities, they fall into natural areas of functionality such as ‘deployment’, ‘admin’, ‘shopping’, ‘’search’, shopper accounts’, ‘checkout’, ‘orders’, etc.

At least some of these will have enough stories associated with them, that to get a higher level view of each and more easily manage their priority, you can create an epic.

Creating epics

You can either click EPICS toward the left of the Tracker project page to open the Epics panel, then click the plus icon at the top, or type ‘e’ (when the cursor is not in an editable field).

Alternatively, if you have already entered and labeled stories in Tracker, you can convert a label to an epic. The label will remain, but change color from green to purple to identify it as an epic linked label.

Describe and discuss large features

In your epic, you can describe the high level goals of the feature and attach mockups that demonstrate desired designs. Comments can be used to have a conversation with the team about the feature and record overall decisions.

Planning your stories

The feature or activity described in the epic can then be broken down into small, concrete, actionable stories. For example, with the Shopping epic in mind, you might have a story called “Shopper should see list of products, with primary photo as thumbnail”. After entering your stories, you can drag and drop them onto a collapsed epic, so that they get the epic’s linked label and become part of it. Click the arrow icon to the right of the collapsed epic to see all the stories in the epic or simply type shift+e. You can also drop stories into the epic stories panel and start ordering them by priority, the most important being at the top.

Then you’ll want to determine the level of effort for each story, and can go through and estimate them.

Representing milestones

Having broken down each epic into stories, it helps to put a release marker into the backlog to represent the “minimum viable product” milestone (or “first demo to investors”).

Then drag all the stories for that milestone into the backlog, above the release marker. Release markers should always go at the end of the set of stories that the milestone or release will include, not the beginning, then they follow those stories through the workflow.

Keeping track of progress

As you start working on stories, their state is represented in the epic’s progress bar. It gives an immediate overview of how far along the epic is. The colors in the bar match the color of stories, and it’s width represents the size of the epic, relative to other epics. As your stories are completed and accepted, the bars update to reflect what’s happening.

Mousing over a progress bar reveals a more detailed breakdown of progress, including an estimated completion date. This date is the last day of the iteration that the epic’s last prioritized story appears in, in the backlog.

Re-prioritizing stories

Priorities always shift during a project and you can reprioritize stories directly in the backlog, or in the epic story panel. The changes you make are always also made throughout the project and reflected in the different views of it.

Stories moved in the epic story panel are reprioritized relative to other stories there. The following show a selected story before and after it is moved:

Completing epics

As you complete your stories, epics are considered done (and appear in green) when all prioritized stories in them are accepted. Stories in the icebox are not considered to be “in play” – they’re on ice, and in most cases epics will have stories in the icebox indefinitely. It’s often the case that everything you wanted doesn’t actually get done, yet the feature is perfectly usable. However, as soon as you drag a completed epic’s story from the icebox to the backlog, it will stop being green.

Done epics remain in the Epics panel until the iteration in which stories in them were accepted is over. Then you’ll see “Show x Done Epics” at the top of the epics panel instead.

More information and feedback

We hope this helps you get the most out of epics for your project. For additional information, please see the FAQ, and watch this brief overview video. As always, we value feedback, so we’d love to hear from you in the comments here or on Facebook, Twitter, or by email to tracker@pivotallabs.com.

The post Using Epics for Your Project appeared first on Pivotal Labs.

But if you do receive an error message instead of bugs loading in your Bugzilla integration panel, here are some tips to get past them. The following also applies to other error messages, but these are the most common:

“Unable to load bugs – Please check your URL and remember to include http:// and exclude the xmlrpc.cgi.”
or
“Unable to load bugs – There was a problem processing your request.”

You can take the first error literally, but there are also some other causes for it which aren’t obvious.

1. We only support versions 3.4.x and above. That said, at the time of writing, we recommend 4.0.9 as we’re looking into an issue with the the 4.2.0 release and possibly some preceding minor versions and release candidates.
2. If you haven’t changed the integration’s “Bug ‘Status’ values to exclude” (currently RESOLVED, VERIFIED, CLOSED), these defaults could be trying to pull in too much data and hence failing. To check, log in to your Bugzilla instance and use the advanced search options to find a small number of bugs, to help you change the default values to exclude all but those, and see if they’ll be pulled in.
3. You may need to install one or more optional Perl modules, i.e. SOAP-Lite and possibly Test-Taint. To determine if you have them installed (or to get the commands necessary to install them), go to the directory where you installed Bugzilla on your server and run the checksetup.pl script. It will tell you what modules are installed, and what optional modules can be installed (and what they will enable). Check to see if these modules are there and if not, install them.Once that’s done, you can test it using the following. To run this you’ll need access to a machine that has the CURL command. Create a file called version.xml with the following text:<?xml version=”1.0″ encoding=”UTF-8″?>
   <methodCall>
   <methodName>Bugzilla.version</methodName>
   <params>
   </params>
   </methodCall>

   Then run this curl command:

   curl -X POST -H"Content-Type: text/xml" -d @version.xml <url of your Bugzilla server>/xmlrpc.cgi

   To see a successful version request, run the command against the Bugzilla “Landfill” test server. For example:

   curl -X POST -H"Content-Type: text/xml" -d @version.xml https://landfill.bugzilla.org/bugzilla-4.0-branch/xmlrpc.cgi

   If all is well, the response should look like this:

   <?xml version="1.0" encoding="UTF-8"?><methodresponse><params><param /><value><struct><member><name>version</name><value><string>4.0.2</string></value></member></struct></value></param></params></methodresponse>

   If the response printed by the curl command accessing your Bugzilla server is like this, then the Tracker integration should be able to access your Bugzilla server. If this is not the kind of response you get, then your server is still not setup correctly. In general the response’s content should help you troubleshoot. For example, if contains, “The XML-RPC Interface feature is not available in this Bugzilla.” it means you need to enable the XMLRPC interface on your Bugzilla server.

   However, if you are using version 4.0.5, a bad response (such as “Application failed during request deserialization: 32612: When using XML-RPC, you cannot send data as text/xml; charset=utf-8. Only text/xml and application/xml are allowed.”) could be the result of the following Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=731219
   It’s been fixed in the patch referenced in the bug, but by the time you read this, there may be more recent updates.

4. Another problem can be with the data that is being transferred to Tracker, if there are one or more bugs which contain multibyte characters in the description or comments. This is usually a result of pasting text into a bug from rich text email or office documents. These characters cause the length of the data stream that the web server sends to us to be incorrect, and we are unable to parse the XML on our side. In that case, determining if your bugs have any multi-byte characters and removing them, should resolve the problem. We can provide steps to help you with this if you need them.

The above should cover the most common problems. Hope it helps.

Finally, we get asked if you can integrate Tracker with Bugzilla if it’s behind your firewall. Yes, we have API servers that you can allow through your firewalls for Pivotal Tracker integration with your Bugzilla server. Please refer to our Integrations help page for more information: http://www.pivotaltracker.com/help/integrations

If you have any questions, or there’s something this doesn’t cover, please send email to: tracker@pivotallabs.com

4.0.9

The post Setting up & Troubleshooting Bugzilla with Tracker appeared first on Pivotal Labs.