Less Stress. More Quality.

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.

What a strange name for a blog.

Less stress. More quality. Isn’t that an oxymoron?

A lot of people in software development today would say that one of these words doesn’t belong with the others. If you are going to create quality software, isn’t it a given that you’ve signed up (or been volunteered) for a lot of extra hours, headaches, worry, concern, fear, uncertainty, doubt, hassles, arguments, ulcers, and anxiety?

You know, stress.

While I have been known to keep an industrial drum-sized bottle of TUMS on my desk during various projects in my career, over the years I have learned that there are ways to deliver high quality software and still keep your stress level within reasonable bounds.

It’s not always easy, but it is possible. Most of the time.

This blog will focus on what I’ve learned about creating quality software with less stress. You won’t need your antacids if you have the following available for your next project:

• good practices
• great tools
• a little fun

Good Practices
I’m not a fan of the phrase “best practices.” Don’t get me wrong, I have no problem learning from the successes and mistakes of those who have gone before me. Good software engineers, testers, and managers have sacrificed evenings with the family, their waistlines, and their next promotion to bring us hard fought knowledge of good ways to solve the software development problems that plague us.

I just don’t believe in a one-size-fits-all solution.

What works best for two programmers in a garage won’t necessarily be the best solution for the team at NASA working on a Martian explorer or a Hubble Telescope. Show me good ways others have solved similar problems and I’ll pick the best solution for my current situation.

On these blog pages, I intend to share what I’ve learned about creating quality software. In return, I hope you will share what you’ve learned on your own projects with me.

Great Tools

What can I say? There’s a reason I wanted to be the product manager for the best family of issue and defect tracking and test case management tools on the market. I love my products! I was a user and fan of TestTrack long before I joined Seapine.

Stop by these pages for tips on how to use TestTrack Pro, TestTrack TCM, and TestTrack Studio to implement your good practices.

A Little Fun
Some days we all need to be reminded to breathe deep and smile. (The light at the end of the tunnel isn’t always an oncoming train.)

Stressed-out, unhappy people make bad decisions. Bad decisions make bad software.

Good practices implemented with great tools make quality software. And nothing reduces the stress in your software development life like producing quality software.

I hope you can visit each week. I’ll be doing my best to fill these pages with good practices, great tools, and a little fun that you can use on your projects.