The Seapine View

I have updated our labs page in regards to integration with Microsoft’s Team Foundation Server (TFS).  Even though this is not an ‘out of the box’ supported integration, you do have several options.

We had two sample scripts on how TFS could be integrated with TestTrack Pro and TestTrack TCM. I have updated them so they can be used out of the box. Previously they had connection information hard coded, which meant you had to change the source code and recompile in order to use them. I have also added a new article.
Continue reading…

As a consultant, I have been exposed to many different development methodologies and processes. In most cases, assignments are performed by a person that is aware of staff resources and distributes tasks according to the availability of these resources.
Continue reading…

If you are a loyal reader of this blog, chances are that you read Gerhard Kruger’s post about our Visual Studio Integration.  In this article, Gerhard talks about accessing TestTrack Pro items and Surround SCM actions from within Visual Studio. I’d like to present a different angle to this integration, specifically, the TestTrack Pro integration.
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…

Last week, Seapine Software presented a webinar called “Transparent Traceability in Life Sciences: A practical approach to compliance in your development lifecycle”.  The program was presented by Paula Rome, Sr. Product Manager, and myself and was moderated by Jay Luis, VP of Marketing.  Preparing for these webinars is harder than I thought but we’re all very happy with the result.
Continue reading…

My colleagues and I have presented several different ways to interface TestTrack with other systems, mostly using the TestTrack SDK. If you want to create a simple data interface, there is another option: Email.
Continue reading…

Before I worked for Seapine Software, I was employed by a now defunct software company in the Cincinnati area. It was a small company, with about 25 employees or so. I did many jobs at this company. My main duty was customer support, but I also did things like testing, managing our bug tracking system, putting together our releases, and other things.

Reading Matt’s post on his co-op where he tracked tests on a spreadsheet made me reminisce about my old employer. You see, our defects were written down on paper. Screenshots were physically attached (I mean we used a stapler) and notes, comments, and anything else were usually handwritten all over the place.
Continue reading…

I was recently interviewed by Mike Lippis for the Outlook Series. Listen to the interview.

Mike was interested in my perspective on test case management and issue tracking. As you might expect, I was pretty shy about talking about the advantages these types of tools bring to software development teams. (Don’t worry, you don’t have to listen to the entire interview in one sitting.)

Just out of curiosity, how would you answer these questions?

• Can you answer the question “Are we ready to ship today?” the same day you ask the question?

• Are you confident that your testers and developers are focusing their efforts on the highest priority tasks?

• Do you know if the product you shipped has all of the features your stakeholders asked for? Can you prove it to auditors?

If you didn’t answer yes to all of these, then you are a good candidate for adding an integrated test case management and issue tracking solution to your development tool arsenal. And I just happen to know of a great solution!

Check out TestTrack Studio today. You won’t be sorry.

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.”

One of the strategies I’ve used to reduce stress when wearing my project manager hat has been to try to control all changes to the project. I bet more than a few project managers out there are nodding their heads in agreement.

Change control = good = normal levels of stomach acid

But I’ve recently come to wonder (after some great customer conversations) if sometimes in my zeal for control of that holy project manager triangle of time, money, and features, that I took things a little too far.

I’m not talking here about ignoring valid scope changes that are driven by real business needs (and signed off customer requests).

I’m talking about spurning opportunities to increase productivity on long running projects by not taking advantage of the latest version of your software development tools.

Me: “Talk to the hand, girlfriend, ‘cause until we ship, nobody is touching that bug tracker server.”

In real life, I’m not that cool. When faced with this situation, I’m sure I rattled off phrases like “risk management” and “not an ideal time in the schedule.” Like there is ever an ideal time in a project schedule for anything.

Don’t get me wrong. I’m not advocating throwing out good practice and common sense. There are definitely better times than others for making changes to your project processes and tools. But not all changes need to throw you into a DEFCON 1, maximum biohazard containment frenzy.

I’m arguing that upgrades to your project tools don’t all carry the same risk. Assuming you have current backups, upgrading your issue management system does not have the same potential for wrecking your project schedule as, say, upgrading your compiler version. And, since your team is using that issue management system every day, an upgrade with even small usability enhancements has the potential reward of higher productivity and improved morale.

Why am I whining about this? Because in those recent customer conversations I mentioned, I found myself saying the following multiple times.

Me (again): “Great feature request! I can see how that would save you a lot of time. We, um, added that in a recent release.”

Frustrating to me and very frustrating to the customer stuck on a version several releases back.

I know upgrading software development tools in the middle of a project can be a stressful and divisive issue for teams. I’d love to hear what factors you consider when pondering a tool upgrade.

Bottom line for TestTrack users: if you are up-to-date on your maintenance, the upgrade is free. Check out the release notes to see if your favorite TestTrack feature request has shipped without you. Still unsure if the rewards are worth the risk? Maintenance also entitles you to contact support so you can find out just what’s involved in upgrading your project.