QA Hates You

Yesterday, I betweeted:

Proper interview question for software testers: Are you more like the Cat in the Hat or more like the fish?

Those of you who are familiar with the story know what I’m talking about. Those of you unfamiliar with the story need to catch up. Go ahead, meet that special someone, get married, procreate, and read your spawn that book 100 times. I’ll wait.

Okay, done? Here we go.

I’ll sum up for those of you who, instead of properly schooling up for the question as mentioned above, just continued reading. Two children sit in their home on a wet, wet day and wonder what to do. In comes the Cat in the Hat, spawning mayhem, while the fish points out that the cat should not be there and should not do what he is doing. Now.

Am I more like the Cat in the Hat or the fish?

I have elements of both.

The Cat in the Hat is chaos and all sorts of unexpected behavior. I have a great ability to look into an application or a process to find the unexpected places you can go with them and to exercise that disruptive influence to make sure that the problems get identified and fixed.

On the other hand, the fish is an enforcer, as much as a fish can be, of the rules and strictures offered by requirements or formal processes. I like to hammer on these, too, whenever possible.

However, I’ve worked mostly for smaller firms with fewer formal processes (and requirements? What are those?), so I’ve acted more Cat in the Hattish throughout my career. Plus, I’ve had people under me, so I’ve experience opening a couple boxes of Thing 1 and Thing 2 as needed.

“It’s better to be wanted for murder than not to be wanted at all.” –Marty Winch

Surely you can meditate on that for a while and see how it applies to QA.

Trisherino enumerates five things developers and designers could do to reduce the number of obvious issues testers will find: 5 Tips to Thwart Testers.

They’re obvious, and they’re pretty good ideas, but your organization will not follow them for long, even if your team catches on.  Why?  Because institutional memory is fluid.  By the time you drum that into your developers’ and designers’ heads, they move onto a different teams or onto different companies.  They will be replaced by people who are less expensive and less knowledgeable or they will be replaced with experienced sticks in the mud who know the right way to do things: their way.

And their way does not include to stooping to IE.

And so it goes.

The best you can hope for is to become such an archetypal nemesis to your developers and designers that they carry the fear of you beyond your team and company so that they do things the right way even when they’re somewhere else.  Somewhere, some lucky QA professional will get a n00b on their team that does things right.

From Meditations Book Twelve:

All those things at which thou wishest to arrive by a circuitous road, thou canst have now, if thou dost not refuse them to thyself. And this means, if thou wilt take no notice of all the past, and trust the future to providence, and direct the present only conformably to piety and justice. Conformably to piety, that thou mayest be content with the lot which is assigned to thee, for nature designed it for thee and thee for it. Conformably to justice, that thou mayest always speak the truth freely and without disguise, and do the things which are agreeable to law and according to the worth of each. And let neither another man’s wickedness hinder thee, nor opinion nor voice, nor yet the sensations of the poor flesh which has grown about thee; for the passive part will look to this. If then, whatever the time may be when thou shalt be near to thy departure, neglecting everything else thou shalt respect only thy ruling faculty and the divinity within thee, and if thou shalt be afraid not because thou must some time cease to live, but if thou shalt fear never to have begun to live according to nature- then thou wilt be a man worthy of the universe which has produced thee, and thou wilt cease to be a stranger in thy native land, and to wonder at things which happen daily as if they were something unexpected, and to be dependent on this or that.

At least, that’s how I felt when I quit the daily work world and went to test consulting.  It’s liberating in that it allows me to focus on the testing and avoiding the office politics and the other trappings that fall into the “administrative” bucket on the time sheet.  On the other hand, you do have to have a certain faith that those contracts will keep coming.  QA doesn’t make a fellow optimistic, but you do need it a bit when there’s no sure knowledge that you’ll be logging the same defects against the same features against the same application a year from now.

From Meditations Book Seven:

 In everything which happens keep before thy eyes those to whom the same things happened, and how they were vexed, and treated them as strange things, and found fault with them: and now where are they? Nowhere. Why then dost thou too choose to act in the same way? And why dost thou not leave these agitations which are foreign to nature, to those who cause them and those who are moved by them? And why art thou not altogether intent upon the right way of making use of the things which happen to thee? For then thou wilt use them well, and they will be a material for thee to work on. Only attend to thyself, and resolve to be a good man in every act which thou doest: and remember…

Hrm, you know, that’s not very inspirational mentorship, true though it may be.  Maybe we’d better cling to Henry V at Harfleur:

Once more unto the breach, dear friends, once more;
Or close the wall up with our English dead.
In peace there’s nothing so becomes a man
As modest stillness and humility:
But when the blast of war blows in our ears,
Then imitate the action of the tiger;
Stiffen the sinews, summon up the blood,
Disguise fair nature with hard-favour’d rage;
Then lend the eye a terrible aspect;
Let pry through the portage of the head
Like the brass cannon; let the brow o’erwhelm it
As fearfully as doth a galled rock
O’erhang and jutty his confounded base,
Swill’d with the wild and wasteful ocean.
Now set the teeth and stretch the nostril wide,
Hold hard the breath and bend up every spirit
To his full height. On, on, you noblest English.
Whose blood is fet from fathers of war-proof!
Fathers that, like so many Alexanders,
Have in these parts from morn till even fought
And sheathed their swords for lack of argument:
Dishonour not your mothers; now attest
That those whom you call’d fathers did beget you.
Be copy now to men of grosser blood,
And teach them how to war. And you, good yeoman,
Whose limbs were made in England, show us here
The mettle of your pasture; let us swear
That you are worth your breeding; which I doubt not;
For there is none of you so mean and base,
That hath not noble lustre in your eyes.
I see you stand like greyhounds in the slips,
Straining upon the start. The game’s afoot:
Follow your spirit, and upon this charge
Cry ‘God for Harry, England, and Saint George!’

From an essay on What Every Super Achiever Knows About Time Management That You Don’t:

Super achievers don’t manage their time, they create, manage and maximize their opportunities. At any given time they know the one critical, must complete, task and they work on that task. It is the most important and therefore deserves their full attention.

Curly said there was only one thing in life, but you had to figure it out.  If you’re working in quality assurance, you’ve already figured out what that one thing is: to keep your hanger-on-to-technology job by being pleasant in innumerable pointless meetings, not rocking the boat, and spending a lot of time generating metrics systems to justify your continued employment.

Well, maybe that’s just a lot of the quality assurance people with whom I’ve worked briefly.

No, the one thing you need to focus your time on is delivering a quality product.  Knowing the product, knowing the business problem it’s designed to solve, and making sure the damn thing works is that one thing.  Sitting in kickoff meetings, no matter what kind of doughnuts they have, isn’t it.  Neither is pulling together another test strategy document from the template that no one will read or understand.  It’s not about creating a perfect process that Plato would be proud of.  It’s delivering a quality product.

Focus your time and energy on that, not the trappings of the Quality Assurance industry.

Optimism is a failure of the imagination.

More fun with Twitter, secondhand:

Click for full size

It has crashed so badly that not only is the update portion not working, but it’s returning a 408 error, which means that the Web server is timing out while looking for the custom error page.

Which leads me into a short bit of rant about a piece entitled In A Web 2.0 World, Quality Is Irrelevant (link seen here):

Still, I’m not in full rosy concurrence with the idea that we should kick quality completely to the curb. For one, it’s not that quality doesn’t matter — it’s that the definition of what constitutes quality is changing. The old idea that quality is defined by editing an article six ways from Sunday so that it’s denatured of all passion and advocacy, and so that that it has every freakin’ semicolon and middle initial in the correct place — that’s what’s dead.

So what’s the new definition of quality? It’s a bit early to say definitively, but I believe what’s gelling is consistent with the post-literate society I believe we’re now amidst. (At this point I should probably send a friendly text message to my teenage daughter. To which she’ll respond: KK LOL ROFFL TTYL.) Namely, quality is now measured out more in engagement — videos, pictures, short and pithy commentary — than in llooooooonng, boring blocks of dense text. Which nobody reads anyway!

The author is speaking mostly about writing style and typos, but of course developers are happy to generalize it to code and everything else.  However, shifting the definition of quality away from, you know, quality and to strengths the definer has (speed, relevance, authenticity, a blog on a magazine’s domain, an espresso machine in the kitchen) ultimately only serves the complacency of someone who defines quality down.

For in a Web 2.0 world, particularly one with eager Noah Websters out there who’ll tell you their application is the alpha and the omega, flaws and all, quality will remain a differentiator, and a bigger differentiator at that.  Although one expected a certain floor of minimum quality standards with most products up until about 1996, with software and applications, particularly those written poorly like Twitter, one gets first-to-market as the goal or tipping-point users or something other than stability and quality.  Once better quality products come out, though, users will migrate to them.  Blogs with fewer typographical errors will garner respect more than those rife with things like Steev Jobs had a herat attack!!!!

Of course, if your goal is to build it and cash out rapidly or to grab the youth market where newness and authenticity trump quality and stability instead of building a solid, long term user base, I guess quality isn’t for you, but then again, you probably don’t have a test team anyway, so worrying about redefining quality isn’t even a problem you’re addressing.

You cannot spell adequate without QA.

Well, no, ComputerWorld calls them 5 easy ways to commit career suicide, but I have found them to be effective techniques in establishing proper business relationships when you’re in QA. Particularly #3, Contradicting the boss in public.

I never inappropriately discharged a firearm in the presence of coworkers. I’m stuck on deciding which punchline to go with here, so you choose whichever you like best:

• In all cases, the discharge was appropriate.
• I wish I’d thought of it.

If you’re a grade A QA professional, you’ve managed to worm quality assurance into the entirety of your organization’s software development lifecycle (if you’re grade A+, you’ve actually broken out of the SDLC and have someone from the quality team proofreading corporate communications, werd). That means you get a seat at the table in the requirements gathering process along with some free-talking technical guy who’s really a sales guy with a cert or two, a business analyst if you’re lucky, and a customer relationship management yippy dog who jumps up and down agreeing with whatever the customer says and sometimes with something your company’s representatives say. However you got yourself into this predicament, best practice or not, you have to take care of QA in this meeting, and here’s what I do in that situation, particularly if I find myself in that situation disarmed.

(more…)

Joel Spolsky talks at length about Internet Explorer 8′s upcoming standards adherence and the coming Internet cataclysm because of it.

The piece is long and offers many lessons, but the best one is the recognition that even though you’ve launched a site or Web application that works with current browsers, you’d better test them again when new browsers come out, even if it’s only a quick run through sanity check.

I like to pretend I’m an old-school computer user, steeped in the command line world of old operating systems and the dark screen and keyboard unfettered by the need to use a mouse. I know all the operating system hot keys. I like the Tab key. I don’t like wasting the time to move my hand a couple inches to the left to inelegantly maneuver a collection of pixels on my screen so I can work. I know, with that much attempt at cred, you’d think I’d learn to touch type, but this article isn’t about my shortcomings. It’s about the shortcomings of interfaces that don’t allow you to interact with the application without the mouse.

(more…)

Project Manager Frank Kelly guesses 4 reasons it sucks to be in QA.

I’ll rebut with one good reason about being in QA: Schadenfreude, all day, every day.

A recent article shows how the workarounds put in place in software impedes people. This article, entitled “Apostrophes in names stir lot o’ trouble“, alludes to a number of characters that software designers/developers mishandle:

It can stop you from voting, destroy your dental appointments, make it difficult to rent a car or book a flight, even interfere with your college exams. More than 50 years into the Information Age, computers are still getting confused by the apostrophe. It’s a problem familiar to O’Connors, D’Angelos, N’Dours and D’Artagnans across America.

To avoid SQL injection attacks, which can use the apostrophe, a lot of times developers just prevent users from entering apostrophes into the edit boxes on Web forms.

That’s not the best solution, as the people in the article attest. You shouldn’t let your developers get away with it.

Ah. A Web application has stood up to your rigorous testing in the original test environment. Hey, in a strange quirk of fate, you’re living in that fantasyland where the application is then deployed to a staging server that resembles the structure of a production server so you can run through it again on a final build. The application passes with flying colors, which means it hasn’t bled to death in stage from your repeated thrusts. No, some project manager or customer lover comes in and says, “Ship it.” One of your technical co-workers deploys the application to production sometime in the middle of a night on a weekend or, more likely, 20 minutes before the client expects it.

You, tester, have just one run through it and MillerCoors time, right? Hold on, little pardner, not so fast. Particularly if your application’s production environment uses a load balancer.

(more…)

In the January 2008 issue of Software Test and Performance (available as a PDF), the head of Parasoft, a QA software company, explains when automation efforts can go to pieces.

(more…)

As you expect, gentle reader, even when it comes to checking the links on Web sites, I prefer manual testing, particularly at the onset of a Web site development project. That is, I do want to personally, with my own index finger, click every single link on every single page, including that repeated navigational menu bar that would never, ever change across the pages (the developers and designers say) and don’t tend to change except when they catastrophically fail, for no discernable reason, on a single page.

That’s not to say that automated link checking doesn’t have its place, because it does. The remainder of this piece talks about its place.

However.

(more…)

“Those who would give up Essential Quality to earn a little Temporary Profit, will see neither Quality nor Profit.”

Feel free to use that in your next status meeting, when someone is explaining why the team shouldn’t fix a large number of defects.

In the message from the editor in the November 2006 (pdf) issue of Software Test & Performance, Edward J. Correia expresses a basic belief in the magical potency of automated testing:

Repetitive tasks are bad enough—having to perform them repetitively is insane. If something can be automated, it should be. Even if it takes 10 times longer and costs a hundred times more than the original task itself, it pays in the long run to automate your tests.

I cannot tell you how many times I’ve gone into interviews and sales calls for projects where the other person across the table blurts out the benefits of automation and how the company wants to use automation to build a complex suite of automated tests to ensure 100% code coverage to run with nightly builds to ensure project success.

But the automated test evangelists, speaking in their tongues, are wrong. Sometimes automated testing is a bane.
(more…)