QA Hates You

You know, I worked once in a corporate environment where we had to set personal and team goals for a year. So we sat around in several days’ worth of meetings to come up with the most basic bullet points that we could probably hit as a team and vague notions of our self-improvement to ensure we would get annual bonuses and not embarrass our division.

It wasn’t even that big of a company.

But for those of you who are facing that situation as we go into December, here’s a little research material:

That should be on your list somewhere.

(Thanks to El Guapo for the suggeston.)

Sorry for the lack of posting lately.

Here, let me distract you with Damn You Auto Correct.

Join me in noting the comma missing before the noun of direct address in the title.

Reverend Horton Heat, “The Devil’s Chasing Me”:

I’ll leave it to you to determine whether QA is doing the chasing or being chased in the metaphor most applicable to your situation.

I recently read the book Genghis Khan and the Making of the Modern World to glean its insights into management and quality assurance in particular. As you would expect, I found a lot of good advice from the life of a man who drove natives into moats to fill them. Here are three:

• Prepare the environment.
  When Mongol reconnaissance groups were looking around at the edge of the largest contiguous empire the world has ever known, they would find places they were going to invade next year. Then they would burn the agriculture nearby and they would raze the villages in the manner of Genghis Khan. That way, next year or the year after, when the main of the Mongol forces would come riding through, the formerly developed land would be good pastures for the horses.

  This is not a call for adequate planning at the project level. The best plans evaporate in the heart of testing. It’s about looking ahead and making sure you have the resources to feed your horses when the time comes. Make sure you have the appropriate browsers installed and your VMs in a row before the projects start. Get a good basic idea in place for how you approach generic applications trampled into your people’s minds so that when they cross the river, they know what to do and where the forage is.

• Bring to bear different technologies and knowledge bases to devastating effect.
  The Mongols ruled a vast swath of Asia, the Middle East, and eastern Europe. They had a great diverse number of peoples upon whose knowledge they drew to great effect, using war machines and techniques learned in Asia to attack cities in Russia with something they’d never seen before. The Mongols also used scholars from all across the world to administer and maintain the vast trade lanes they created. If Genghis Khan had stuck to what he knew, fighting on horseback and herding, the Mongols would have remained a localized group of tribes doing what they always did.

  I think job ads that look for industry- or tool-centric knowledge automatically limit the teams that hire people who’ve walked the same happy paths (and unhappy paths) the existing team has always walked. Personally, I like a diverse team drawn from software covering many different industries for the insights into how software often fails in those other systems that might apply to the software in your industry that your company produces.

• When load testing, look for the indirect approaches to add load.
  Before Genghis Khan would attack a walled city, he would burn nearby hamlets and villages and farms and would drive the refugees before him to seek refuge in those cities. The influx of hungry and thirsty refugees would deplete the stored food and the cisterns. Their presence would tax the patience of the city dwellers and the powers-that-were who tried to keep order.

  By an indirect assault of adding a burden, Genghis found and exploited weakness.

  When you’re planning your load tests and performance assaults, don’t just focus on the normal pathways into the application. No doubt those gates and drawbridges are well defended. Don’t forget to look for other mechanisms that indirectly impair the performance of your application. A Web service or API that only one client will use (for now). A component that only contributes infrequently, but importantly. Don’t forget to make those small parts of your application wail, too, to see if their problems can cause big problems for your application.

I’m definitely heeding my own advice in going to history books for management lessons in QA, but all the material you learn and all you take in becomes grist for the creative mill. Or the destructive mill. Whichever sinks your boat.

This morning, I removed Norton AntiVirus/SystemWorks from another machine in the lab. It went something like this:

I’ve been a Norton customer for 15 years, before the Symantec acquisition and through four separate operating systems starting with Windows 95. I even several of Norton’s books to those early operating systems as I tried to bend my head around the change to Windows 95 (you know, when the GUI doesn’t lie atop DOS but is the operating system itself).

However, it has been with a growing reluctance, especially as this century has advanced.

The whole shebang really bogs the systems down. On my laptop, it took several minutes to come out of screensaver on the mornings after Norton ran a whole system scan, and I’d have to reboot the machine–after the several minutes’ worth of screen saver recovery–to bring it back up to regular operating speed.

Some of it’s my fault, no doubt, for allowing it to run for years installing its updates and leaving its garbage behind. But, really.

So here’s how I had to go about it:

1. Uninstall the Live Update Service. Its updater runs on its own and has its own uninstall service. If you try to uninstall Norton AntiVirus or Norton SystemWorks on its own, it refuses as the Live Update Service might be working even now.
2. Uninstall the Live Update Service Notifier. Which is different from the preceding somehow. But I wanted to kill them both before I tackled the others.
3. Uninstall Norton AntiVirus. It’s a big kahuna, and it knocked me off of my wireless network since it had to uninstall its network drivers. Really.
4. Reboot.
5. Uninstall Norton SystemWorks. But, Director, doesn’t that include Norton AntiVirus? Depends upon the bundling. I initially on SystemWorks but balked and upgrading/licensing the whole thing when I came to the end of the year. So I just got the upgrade/install for the AntiVirus, I guess. How old is this laptop, anyway?
6. Reboot.

Then she was singing “Daisy.”

I’m not saying I’m done with Norton/Symantec forever; a lot of machines come with it bundled on at purchase, and I’ll probably run it then. However, I am saying it’s a good strategy to do that. When the license expires and you remove Norton, it’s like getting an upgraded machine.

Forget the buzzwords; here are some new words to deploy in your status meetings.

A couple of my favorites:

5. Ludibrious

Adj. – “Apt to be a subject of jest or mockery” – This word describes a person, thing or situation that is likely to be the butt of jokes. Use it when you want to sound justified in poking fun at someone. “How could I resist? He’s just so ludibrious.”

And:

8. Malagrugrous

Adj. – “Dismal” – This adjective is from Scots and may be derived from an old Irish word that refers to the wrinkling of one’s brow. An 1826 example of its use is “He looketh malagrugorous and world-wearied.” I’m tempted to also make the word into a noun: “Stop being such a malagrug!”

(Link seen here)

Jethro Tull describes the SDLC:

Would it be so frightening to have QA at your shoulder?

I’m sorry, I meant the Dilbert way:

However, you should not feed junior testers enough that they get pudgy.

Thank you, that is all.

Given the more mellow sounds you’ve been hearing here recently, you’re probably skeptical of this post, fearing that I’m going to uncork “It’s Raining Men” on you.

Fear not. It’s just Slayer.

And try to use those two sentences in conversation today: “Fear not. It’s just Slayer.” Especially if you blurt them out in a meeting where you’re discussing problems with database commits. Because those sentences always allay fears.

An Indiana resident reports some crazy swings in the weather this year:

Another reminder that your monitor is not the only output you need to test for your application.

(Seen here.)

I’d make some metaphor here about how keeping your teams segregated makes a QA ghetto, but it’s failing me now.

Let Bobby Womack explain it: