The Seapine View

We recently released version 2010.1 of TestTrack, which contains many new exciting new features. One new feature that I would like to give some love to is Item Mapping Rules. This feature will benefit users who have more than one TestTrack applications, as it allows you to configure how field values are mapped from one application to another.

Continue reading…

A common question I hear from TestTrack users is how to display a value that was entered as part of a workflow event on the main issue/test case/requirement window.  As some of you may know, this is not “out of the box” functionality. However, this can be configured rather easily using automation rules and custom fields.

The only requirement is that the field on the main window has to be of type “String”.
Continue reading…

If you use Surround SCM or any other robust software configuration management tool (gasp!), chances are you are using branches to manage your software development process. Depending on your branch strategy, you may find yourself with a defect that exists across multiple branches. There are many ways to manage this situation, the best one for you will depend on your environment and needs.

Continue reading…

When approaching a programming task using the TestTrack SDK, it is sometimes helpful to first think about how you perform the same task using the TestTrack client. The process is often very similar and can help you understand why things need to be done a certain way when using the SDK.

In this post, I will discuss logging in, so think about that process when you log in using the TestTrack client. The process is as follows:

- Open the TestTrack client.
- Select the server to connect to.
- Provide your username.
 Continue reading...

From time to time the question comes up about how to move the defects from one TestTrack project to another. The answer depends on how different the projects are.

TestTrack has XML export/import and that is the preferred method. There are some key advantages to this method, namely the ability to move attachments and multiple instances of report by records and workflow events. The disadvantage is that, if fields or workflow events do not match, they are not imported. This is likely to be the case if the projects are different in field layout and workflow configuration.

Text export/import may be preferred if you have different projects because you can map fields. For example, you can import the value from the “Project” field in the source project into the “Component” field in the destination project. You have greater control over which fields are exported/imported.
Continue reading…

When companies look to invest in defect tracking and version control tools one of the first questions they frequently ask is “Do you integrate into Microsoft Visual Studio?”

This might seem like a very easy question to answer because, in short, the answer is almost always “Yes we do”.

But once people start to use the integration they normally have a ton of questions on how it works and how they would like it to work. I use Visual Studio 2008, Surround SCM, and TestTrack Pro on a daily basis so I decided to show some of the integration images with real files and bugs, as I believe that pictures speak a thousand words.
Continue reading…

So you are using an industrial grade defect tracker and you’ve been following the good practice advice of writing up all issues reported about your software. To paraphrase Dr. Seuss, “a bug’s a bug, no matter how small.”

Congratulations!

You know that all of the issues that could potentially hurt your project are safely stored in one place. Pat yourself on the back and take a moment to enjoy the peace of mind that following this good practice can bring.

You have removed a non-trivial source of anxiety related to your efforts to deliver high quality software. The fear that bugs are lurking, waiting to appear right after you ship can be a big source of stress. And while worrying about bugs that haven’t been discovered yet is bad enough, it’s particularly galling to have a project schedule slip at the last minute or have an embarrassing (and costly) glitch at a customer site due to a bug that someone had already identified — but failed to mention.

You know the scenario. Your team is gathered at one end of the table in the big conference room with the sales guy and executive managers at the other end.

Exec (wearing a suit and a frown): “How could we ship and not know about this bug?”

Someone from your end of the table: “But we did know about it. I saw the problem on my machine two months ago. I was sure someone would fix it.”

Grrrrr…

I believe there is a special place reserved for people who discover bugs and don’t write them up. And that place is really, really hot, has no central air, internet access, or pizza delivery service.

Talk to your team at the next project meeting. Send out a reminder in a Project_All email. Make it a game (award bonus points and chocolate for reporting defects — double points for the most critical bug found this week). However you do it, make sure your project culture values identifying and documenting issues.

You know your team has embraced this good practice when you overhear one of the developers say to the tester who wrote up the bug report, “Hey, thanks for finding this one before a customer did.”