Who’s On Phirst

In my last post I talked about how virtualization changed test lab creation and management. I’m sure the first thing you did after reading the post was download your very own copy of VMWare Server and replace all your hardware with super flexible virtual machines. You’re now basking in the glow of your long term cost savings, marveling at how easy your lab is to maintain, and using some of that extra time and money to bid on my exclusive line of “VMWare Saved My Marriage” T-Shirts available only at my eBay store.

Eventually your boss will notice you’re no longer cursing under your breath and slamming the door to the lab. It’s inescapable. And when the boss man gets wind of spare cycles, he starts thinking crazy thoughts. He starts thinking you now have time for that automation project that’s been on the back burner since 1996. With a heavy sigh and a final farewell to what will inevitably be known as “The period in my life that was great, thanks to Pete Pickerill,” you turn your attention to how you’re going to build a flexible automation framework that runs just as well on your Unix & Linux systems as it does on your Windows systems.

Have I got an open-source project for you! Software Test Automation Framework (STAF) takes care of all the nagging little odds and ends that have very little to do with testing your software. STAF employs a series of pluggable modules (called ‘Services’). Standard services cover most of what you’ll need: file system operations, environment variable management, process execution, logging, and miscellaneous commands like ‘ping’ and ‘zip.’

The command above may seem a little cryptic, but when you break it down into steps it starts to make sense. In the example above:

• STAF is executed on Server1: STAF Server1
• The Filesystem Service (FS) is invoked to copy the file myFile.exe: FS COPY FILE myFile.exe
• The target directory is given: TODIRECTORY /your/dir/here
• The target machine is given: TOMACHINE System2

That’s STAF in a nutshell. You execute the STAF command locally or remotely, you specify the service you want to use, what you want to execute within that service, and provide the necessary variables to complete the task.

Now you may be thinking, “But, Pete! What if the copy fails due to disk space limitations or network interruptions? What if System2 didn’t boot to a usable state? What if it just up and fails for no discernible reason at all?” There, there buddy! It’s alright! STAF gives you very descriptive return codes. What’s more, these can either be returned to STDOUT if you’re using the cli or a scripting interface or as Java Objects if you’re using STAF in a Java class.

Other cool things about STAF:

• Accessible: Java, Perl, Python, Tcl APIS and an Ant task make it very easy to fold STAF into your automation. There’s also an Eclipse plug-in I haven’t had a chance to check out.
• Extensible: Write your own services in Java, C, or C++ to handle testing peculiarities specific to your software.
• Documentation: STAF is managed by IBM and the documentation is the best I’ve ever come across in the Open Source realm. STAF DOCS
• Active Community: STAF is frequently updated and new features and integrations are added all the time. There’s also loads of info in the mailing list. STAF MAILING LISTS & DISCUSSION FORUM

For more examples and info, check out the STAF website, Agile Testing Blog & Performance Wiki.

In Tips, STAF, Software Test Automation Framework, Open Source, agile testing
Comment (0) Read More...

BBC has a news report on how boring tasks can lead to errors and omissions. Evidently, your brain will go into 'autopilot' mode when performing redundant, boring tasks. Apparently, there is a specific bit of brain activity that can occur right before you are about to make a mistake.

Until they can make a portable MRI for data centers that will catch that brain activity, may we suggest Phurnace Deliver to simply get rid of your dull and boring tasks along with your errors?

In Tips, phurnace, java, deliver
Comment (0) Read More...

If you have never been in the datacenter in the wee hours of the morning, trying to figure out what's wrong with a server, stop reading this.  If you have never been in an all-hands-on-deck meeting where everyone is trying to figure out what went wrong with a deployment, then stop right now and go do something more useful with your time.  Because if you haven't lived through that, then the rest of this post won't mean much to you.

I've been through plenty of those times.  And the truth is no matter what company I worked at - big, small, or something in between - we always had those times.  They are just a fact of life for people whose job it is to keep the server up and running.

Which brings me to the point of this entry (which is naughty blogging of me - you are supposed to make your point in the first paragraph, but oh well.  It's my blog, so I get to do what I want).  Anyhoo - the point is that so much is wrong with how we think about the "Software Development Lifecycle."  In all the flow charts and diagrams I've seen they all seem to be ignoring the very basic point that things go wrong.  And they don't have a lot of built-in mechanisms to help you through that phase of the life-cycle.  It's a black box in the flow chart that says "insert troubleshooting here."

Let me back up a bit.  If nothing changes about a server environment, chances are you aren't going to have a lot of problems.  Maybe a power supply goes out.  Maybe the network drops.  But for the most part you are only going to have problems when things change.  And that's the catch 22.  Things are supposed to change.  New code is supposed to go out to the servers.  New features are supposed to make it into the hands of eager customers.  And those changes are supposed to happen more often rather than less frequently.  That's how our companies compete with each other - it's called time to market.

And that's the fundamental disconnect between the two goals of keeping things up and running, and getting new code out faster.  As diplomat Henry Kissinger used to say, "real tragedy doesn't happen when right faces wrong, but rather when two rights face each other".  Keeping the servers up is a good thing.  Getting code out faster is a good thing.  How do you balance the two?

To me, any real Software Development Life-cycle has to fully embrace the fundamental belief that things are going to go wrong during any process.  Phurnace Software sells a product that helps do things better, but I can't claim, and I wouldn't claim, that if you use Phurnace to do your deployments that you will never have a problem again.  That's ludicrous, and simply not credible to people who have done this as long as I have.

But one thing that is very different about Phurnace, and the way we do things, is that what we have built is functionality that is designed to specifically help you out when things do go wrong.  We know it's going to happen at some point, and we work hard to try to make it as infrequent as humanly possible.  But it will happen.  And when it does, we have the built-in the features you will need to figure that part out.  Heck, we even have a product named Troubleshoot. 

So, when you are looking at how to balance that "time to market" with "keep the servers up", keep in mind that you have to have robust tools and process in place to fix the problem.   A black box just doesn't cut it.

In troubleshoot, Tips, java
Comment (0) Read More...