Who’s On Phirst

Official blog of Phurnace Software.

Pete Pickerill's Blog
Description:
SQA Engineer

I came to Phurnace by way of Symantec, where I worked primarily on behavioral malware detection technology . My first experience with Java web applications was testing a collection of servlets on Tomcat that fielded requests from browser add-ons that were scouring the web for "phishing" sites. Because these servlets were handling millions of hits a day, I got pretty deep into Tomcat configuration and performance tuning. When I heard the Phurnace pitch, I jumped at the chance join to ease the all too familiar pain of application server management. Currently, I'm working on a test automation framework using Ant, IBM's STAF, JUnit and VMWare Server.

Posted by: Pete Pickerill on

As you may, but probably don't know, Phurnace got some Phunding. The management team put in countless hours over the last several months and the process was apparently fraught with twists and turns that would give Gordias pause. Thankfully, our fearless leaders didn't share with us each and every bump in the road. Even more thankfully they didn't share with us those moments, of which I'm sure there were a few, when the road disappeared altogether. I'm a lot like Bill Paxton's character in 'Aliens': I talk a good game and will bust my butt until the bitter end, but am real quick to loudly proclaim "Game Over, man!" when things don't go as planned. Knowing too much would give me fits.

When it comes to spending someone else's money, I think a lot of software companies screw up by making financial choices like the Lohans' make parenting decisions. Instead of worrying about their employee's productivity and professional growth, they want their employees to think their job is cool. Instead of laying the groundwork for long term success, they try to compete with the outrageous perks offered by companies like Google. Don't get me wrong. Fully stocked break rooms, expensive chairs, and ping pong tables are nice. And even though I'm as pale as they come and have a history of skin cancer, I love a good beer bash on a party barge just as much as the next guy. But I would not trade quality hardware or capable new co-workers for any of these fleeting perks. Good employees don't join a company for the parties or bottomless soft drinks. They join a company because they believe in it's products, are optimistic about the company's success, or are intrigued by the professional growth it offers them. The ones that get caught up in the perks are usually the first ones to leave when something new comes along or complain when the company hits leaner times and has to cut back on the cool stuff so they can make payroll.

The culture here is based on honesty and openness. So while the nitty-gritty of start-up funding wasn't revealed to us there has been a lot of discussion of the funding process. The chickens were never counted before they hatched, but we sure did make a lot of plans for exactly how we were going to count those chickens and what we were going to buy with our new found...poultry. O.K. I think I've lost control of the hatching chicken metaphor. Anyway, during these discussions on what was to be done with the funding it became clear to me how much different Phurnace is than some of the other start-ups I've worked at. The coolest thing about this company is that everyone here seems to be in agreement with the long-term plan. By opening up discussion of business decisions to all of us, it's easier for us to see, appreciate, and contribute to the company's growth and success. It's also striking that everyone can now rest assured that a dime is not spent without tracing it back to a concrete benefit for the company. We are making quality hires and investing in an infrastructure that will optimize productivity and yield solid deployment solutions that we can not only sell, but also take pride in. And isn't building something new and cool what working at a startup is all about?

In phurnace
Comment (0) Read More...


Posted by: Pete Pickerill on

Even though it’s been available for a few months, I only recently had time to check out the latest and greatest free virtualization offering from VMWare. I haven’t run it through the wringer completely, but from what I’ve seen there are several new features and improvements that will definitely hasten the upgrade process in our test environment once it clears Beta. Here’s what I like so far:

  • A vastly better web console. The console obviously came under some major scrutiny. The 1.0 version wasn’t unusable, but it wasn’t as feature rich and intuitive as the 2.0 console. Everything you need to manage your virtual machines is easily accessible in a clean web app.
  • More detailed event reporting. This helps you keep track of changes made to your virtual machines. It also helps you find who started, stopped, or reverted your virtual machines. So now instead of cursing the Void when a VM is reverted out from under you and you lose weeks of unsaved test data, you can find the culprit and break their coffee cup or mess with their chair settings late at night when no one else is around.
  • If you are not a late night saboteur and would rather avoid the situation altogether, virtual machine permissions are a lot easier to manage in this release.
  • Instead of assigning a single ‘Default Virtual Machine Location’ as you do in 1.0, you organize your virtual machines in one or more datastores. You can then set access permissions on your datastore to keep others from interfering with your diabolical machinations…or software development.
  • Virtual Machine memory allocation ceiling has more than doubled. 1.0 capped per virtual machine memory allocation at less than 4 GB. 2.0 bumps this up to 8 GB as long as you have the memory to spare. This is a very big deal for anyone that plans on running multiple virtual machines hosting WebSphere Portal.
  • Updates to the VIX API. 2.0 includes support for an updated API (VIX 1.5) with some exciting new features. I am most anxious to get my hands on the Record and Playback features.

The only thing that I hoped was going to be available in 2.0 was support for multiple snapshots per virtual machine. This would make it a lot easier to switch between WebSphere and WebLogic patch levels when tracking down configuration bugs. All in all, I’m very pleased and excited about digging deeper.

In Vmware Server 2.0Virtualization
Comment (0) Read More...


Posted by: Pete Pickerill on

I dream of buying a dilapidated shack in Middle-Of-Nowhere, Texas. All this shack needs is a small kitchen, a BBQ Pit, a sturdy lawn chair, and a butcher’s block. I would spend the wee hours of the morning prepping brisket after brisket, chicken after chicken, coercing a steady fire into life. When the time was right, the meat would hit the pit, I would plant myself in the lawn chair, and wait. The remainder of my workday would be spent checking the heat, tending to my meaty charges, and whipping up the occasional batch of sauce. I’d close up shop at 2:00 PM or when the meat sells out, whichever comes first.

Unfortunately, this is just a dream and it doesn’t show any signs of turning into a reality any time soon. Until that happens, I have to take solace in the occasional opportunity to cook for friends and family. Phurnace had such an occasion yesterday and I jumped at the chance to spend a day fighting the smoky beast instead of testing software.

 

HOW I COOK A BRISKET:

The Rub:

  • 1 cup Paprika
  • ¼ cup Kosher or Fine Sea Salt
  • ¼ cup Fresh Ground Pepper
  • 1 tbsp Granulated Garlic
  • 1 tsp Cayenne Pepper

Prepping the meat:
An untrimmed brisket is pretty fatty. I usually trim the fat down to a thickness of about ¼ inch wherever I can. Once it’s trimmed, I’ll flip it over and score the top of the brisket perpendicular to the grain. This kind of gives me a guide for cutting the brisket after it’s done. After it’s trimmed comes the seasoning. I usually coat the entire brisket with a thin layer of mustard. This gives the crust that develops during cooking a little tang and crunch and helps the rub adhere to the brisket. Sprinkle the rub liberally over all surfaces but don’t feel like you need to cram it in every little nook and cranny.

Cooking the meat:
I won’t get into how you build and maintain an indirect fire here because it differs from cooker to cooker. The most important thing to remember is you want to maintain as steady a temperature as possible. I usually shoot for a temperature of 240. Put the brisket on your cooker and add some wood chunks to the fire. I usually use oak and/or apple wood chunks. Check the fire once an hour. Add more charcoal and wood chunks as needed.

Typically the brisket will take about 1.5 hours per pound to cook at this temperature. About halfway through cooking time, I start rotating my brisket every 2 or 3 hours and basting it every hour on the hour. The baste I use is pretty simple and will make your heart explode if you drink it straight. It’s 2 cups of beef broth, a stick of butter, ¼ cup of Worcestershire, ¼ cup of lemon juice, and a couple tablespoons of leftover rub.

When’s it done? Whenever the internal temperature reaches about 160 or you can pierce it with a fork easily and it pulls out with little to no resistance. Let it sit for about a half hour and then slice it, using the score marks you made during prep time as a guide. Slicing against the grain yields the most tender results.

In BrisketBBQ
Comment (0) Read More...


Posted by: Pete Pickerill on

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

# STAF Server1 FS COPY FILE myFile.exe TODIRECTORY /your/dir/here TOMACHINE System2

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 TipsSTAFSoftware Test Automation FrameworkOpen Sourceagile testing
Comment (0) Read More...


Posted by: Pete Pickerill on

Why buy the cow? Open Source QA Tools can provide a sturdy test and automation framework.

I’ve spent the bulk of my career in QA at startups so I’m not accustomed to operating with an abundance of resources. As such, I’ve researched a ton of free and open source testing tools in the hopes of automating or streamlining the test process to compensate for a lack of manpower. I’ve decided to use my blog posts to detail some of the tools that I have found useful over the years.

At my last job, we built our test lab by cruising Goodwill stores in search of donated systems capable of running Windows 98, NT or 2K with a minimum of upgrades. While our experiences in creating this “Franken-lab” made for a few good stories, we often spent more time dealing with hardware outages and the quirky behavior common in donated technology than we did testing. At the time disk space, memory, and powerful processors were expensive. Even if we were to buy mid-range systems we’d have quickly exhausted our budget. Without enough hardware to cover all of our supported platforms, we’d have had to rely on disk imaging, a process that includes a lot of downtime while one system configuration is being blown away and another written to disk.

VMWare has changed all of this. At Phurnace, my test lab consists of one system with 8GB of RAM, 2 quad-core processors, and a terabyte of disk space. I can run up to about 10 Virtual Machines concurrently so I can use one as my client test platform, use several more to create clustered WebSphere or WebLogic environments to test against, and have a few virtual machines to spare for developers to troubleshoot defects or test code before checking it in.

Benefits of the Virtualized Test Lab:

  • Installation of VMWare Server and Virtual Machine creation couldn’t be easier.
  • Quickly shift gears. If I get blocked while testing one platform, I can power down those servers and bring up another set of server images in a few minutes without leaving my chair.
  • Snapshots! VMWare also allows me to start from a known good base state every time I power on a virtual machine so I know that ‘pollution’ on my test bed will be minimal.
  • A basic CLI that allows you to start and stop VMWare images remotely. This has been very handy for test automation
  • A library of virtual appliances, some offered for free, that provide pre-installed and configured enterprise applications. I have just started investigating some of these to manage the virtual network my virtual machines are connected too.
  • Lots of available help is just a good Googlin’ away. VMWare is very widely used.
  • Free! Gratis! On the house! VMWare Server is a free offering that is intended to familiarize users with virtualization. While they have several support subscriptions and product upgrades available at a price, this free offering has more than met our needs.

So check it out here . I recommend it highly.

In Virtualization
Comment (0) Read More...