Syndicate content
You suspected it. Now you know it.
Updated: 28 min 2 sec ago

QA Music: Onward, to the Edge of the World and Over

Mon, 11/12/2012 - 05:42

Good morning.

“Sail” by AWOLnation.

Categories: Software Testing

QA Music: A Little Pick Me Up For Monday

Mon, 11/05/2012 - 04:16

Five Finger Death Punch: Coming Down

Consider this your preparation for the lessons learned meeting.

Categories: Software Testing

QA Music: Our Sweet Dreams Are, In Fact, Nightmares

Mon, 10/29/2012 - 02:47

Marilyn Manson is old enough these days that I can dig it. Here it is with a remake of the Eurythmics’ “Sweet Dreams (Are Made Of This)”:

My goodness, that should make the week look better by comparison.

Categories: Software Testing

I’ve Heard of Bugs Closing Windows Before, But This Is Ridiculous

Thu, 10/25/2012 - 09:17

2005-’07 BMW 7 Series Recalled Because Doors May Inadvertently Open:

BMW is recalling 7,485 2005-’07 BMW 7 Series cars because a software problem may cause the doors to inadvertently open, according to the National Highway Traffic Safety Administration.

“Due to a software problem, the doors may appear to be closed and latched, but, in fact, may inadvertently open,” said NHTSA in its summary of the problem. “The door may unexpectedly open due to road or driving conditions or occupant contact with the door. The sudden opening may result in occupant ejection or increase the risk of injury in the event of a crash.”

You know, I still have a vehicle whose key makes moving parts move and whose (albeit plastic) door handle makes other physical things move.

Know why?

Because I work in QA.

Also, I’m to cheap to buy a new vehicle every decade.

(Link courtesy of Gimlet again, who I should consider giving the keys to the blog except he works in ops and therefore only disdains you.)

Categories: Software Testing

Failure Is Inevitable; We Just Try To Make It Really, Really Hard

Wed, 10/24/2012 - 11:47

Wired has an interesting story from the world of manufacturing: Why Products Fail.

It deals with the fact that entropy will lead to the eventual demise of even the most finely crafted and engineered items. The laws of mother nature, the variability in the repeated processing of materials, and other things work against absolute perfection.

Of course, in the IT world, failure emerges a lot more quickly given the nature of the “engineering” (that is, the cobbling together of Internet examples to barely solve poorly understood problems) coupled with “natural laws” — the physical and technological environment from Web browser versions to commonplace architectures–that change every six months or so leads to far less success, and little fection, much less perfection.

To maintain our sanity, though, we really do have to recognize that things will break down. We just have to keep agitating and pushing to make sure that that eventual failure is more isolated and harder to get to than a couple keystrokes combined with a mouse click.

Categories: Software Testing

More Obscure References Than A Second-Tier Gaming Convention

Tue, 10/23/2012 - 13:54

Ladies and gentlemen, the IBM Jargon and General Computing Dictionary circa 1990.

You can bet your bottom dollar that I’m going to bring some of that slang back. By myself if I have to, but I bet some of you will join me.

I wish I was reading stuff like that on the computer networks in 1990. Instead, I was busy reading the MJ-12 cover-up in raw text files. Just think, if I had wasted my time on the former instead of the latter, I coulda made something of my life.

Thanks be to Gimlet for the pointer.

Categories: Software Testing

It Ain’t Me, Babe

Thu, 10/18/2012 - 03:40

But it’s who I want to be: The H.P. Lovecraft Institute of Software Design.

Categories: Software Testing

Copyright Dates: The Brown M&Ms of Applications

Wed, 10/17/2012 - 07:19

The rules of copyright citation are simple, and they have not changed significantly in decades. But companies continue to get them wrong, especially in software applications.

Whenever I see them wrong in an application, I can’t help but wonder What else have they done wrong?

Of course, I think that when I see any application at the outset. But I digress.

This makes copyright dates sort of like brown M&Ms:

In case you weren’t around during the 80s, the rock supergroup Van Halen had a clause in their concert contracts that stipulated that the band would “be provided with one large bowl of M&M candies, with all brown candies removed”. Once the “M&Ms” story leaked to the press, social commentators jumped all over it as an egregious example of the pampered and spoiled behavior that rock artists demanded.

. . . .

Van Halen was one of the first rock bands to bring truly massive concerts to mid-size cities like Macon, Georgia. The staff that worked at concert arenas in these smallish cities were used to bands coming to town with, at most, three tractor-trailers full of equipment. Van Halen’s equipment took up 9 tractor-trailers. It was a lot of stuff, and the staff at these venues were frequently overwhelmed. And when people are overwhelmed, they make mistakes. At a rock concert, “making a mistake” during setup has a large number of possible outcomes. Some mistakes don’t have any effect at all. Other mistakes can make the band sound awful, which hurts nothing but the band’s image. Other mistakes can cause stage lights to fall from the ceiling and kill people… which is exactly what the band was afraid of.

At the heart of any major concert is the contract. Much of the text of these contracts is standard legal boilerplate, but each band may attach specific demands via something called a “rider”. Most of the contracts involving concerts at large venues are jam-packed with riders, most of which involve technical details specific to the band’s stage design. For instance, a rider might say “Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, spaced evenly, providing nineteen amperes total, on beams suspended from the ceiling of the venue, which shall be able to support a total gross weight of 5,600 pounds each, and be suspended no less than 30 feet, but no more than 37.5 feet, above the stage surface”. Van Halen’s concert contracts would have several hundred such demands, and their contracts ended up (in lead singer David Lee Roth’s words) looking “like a Chinese Yellow Pages”.

The staff at venues in large cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors (sometimes significant errors) in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract.

Categories: Software Testing

!Improving Your QA Curriculum

Tue, 10/16/2012 - 03:51

If only this article were more instructive: What Psychopaths Teach Us about How to Succeed

Traits that are common among psychopathic serial killers—a grandiose sense of self-worth, persuasiveness, superficial charm, ruthlessness, lack of remorse and the manipulation of others—are also shared by politicians and world leaders. Individuals, in other words, running not from the police. But for office. Such a profile allows those who present with these traits to do what they like when they like, completely unfazed by the social, moral or legal consequences of their actions.

Unfortunately, the article is more about the study of psychopaths and university students and parts of their brains that light up; maybe the book from which it is goes more into the teaching part and less into the learn from part.

Regardless of what we might want others to think, QA people are generally not psychopaths. Or maybe I’m projecting. Maybe I’m the normal one here, and you’re all crazy.

Regardless of your sanity, the one thing QA should learn from psycopaths, or should emulate from psychopaths, is a little detachment.

Because we walk a line between passionate advocacy for quality and madness. Because that advocacy is going to meet its limit. In some circumstances, it might be a high limit (a good job to find). In others, it’s a low threshold, such as We’ll release it with critical defects causing the application to crash and lose data, but we’ll fix it if anyone in the real world tries to use the SHIFT key, which nobody ever does.

At some point, one has to have the ability to turn off that paladin nature, that passionate advocacy for as near perfection as is at all possible, and throw up one’s hands and say, “Flooz it.” And not care any more. Because that sort of thing can eat you up. You can’t go into the position completely with that attitude (It is what it is.), otherwise you won’t push the team to be better. Not enough, anyway.

So it would have been helpful to have some insight into how to emulate psychopaths in that detachment, but of course, psychopaths don’t have the need to become detached at some point. They’re psychopaths, after all, which means they’re always detached. Their tips would be more akin to how to appear engaged to convince others to behave according to their needs and desires. That is, it would be more of a sales course. Certainly not project management, since project managers can’t make anyone behave.

So I guess I’ll just have to read some more Norman Vincent Peale, and do just the opposite of what he says. Again.

Categories: Software Testing

QA Music: Waiting on the Build

Mon, 10/15/2012 - 03:38

Oh, the waiting and the wanting.

It has been far too long since I’ve listened to Queensrÿche’s Empire. Let’s have another track.

Categories: Software Testing

QA Music: You Can’t Take The Sky From Me

Mon, 10/08/2012 - 03:31

You’ve got to find something at your core that’s inviolable if you’re going to make a career of QA.

Because they’ll take everything else from you. One way or another.

Categories: Software Testing

The Unleveling Wind

Tue, 10/02/2012 - 03:09

In a stunning turn of events, flat corporate structures might not be the optimal solution:

Disenchanted with the corporate world, many entrepreneurs strive to keep their organizations as flat as possible. But a recent study suggests that, in some cases, office hierarchies help employees get more done. And that too many dominant personalities could jam up the works.

The Findings

The study, conducted by researchers from the business schools at Columbia University and Northwestern and the University of Queensland, Australia, found that when there are tasks that require teamwork, people get more done when there are defined leaders and followers.

I once worked at a place that moved from a hierarchy to a flatter structure. Although this sort of structure is often promoted as egalitarian and allowing everyone to take a stake in the outcome, the result is often less Utopian. Sometimes, when everyone takes a stake, nobody takes responsibility, and when things go wrong the blame–if blame is due–is diffused. It can always be somebody else’s fault.

In other situations, flat hierarchy projects end up with the people who think it’s most important making the most effort and carrying along other extraneous people who hope to share in the success of the project or at least appear busy enough to continue drawing a paycheck.

Frankly, I favor an open communication hierarchy where members of the hierarchy have good relationships not only with their peers in the org chart but also with members of other levels of the hierarchy, mostly but not limited to people above and below you directly.

In that case, you know how to escalate things when things need to be escalated. In a team of equals, you get a chasing-the-rabbit-around-the-racetrack sort of effect, where someone can pass you off to someone else until you eventually find someone who wants to fix it or someone who cannot think of someone else to pass you to.

Categories: Software Testing

QA Music: Getting into the Mood

Mon, 10/01/2012 - 03:13

Let’s get in the mood for another week. “Ready to Rumble” by Mystikal

Categories: Software Testing

When That SaaS You Use Goes Night-Night

Fri, 09/28/2012 - 03:52

So I’m having a devil of a time finding just one crushable c-crown black fedora with a 4″ crown and 2 or 2 1/4″ brim in large or size 7 1/4. The ones from Zappos are all contemporary, short brim hats that make the wearer look like Jimmy Olsen.

So, I went through my options and tried to implement Desperation Plan B, Acquire Wool Felt To Make Own Hat.

So I thought about Joann Fabrics, which might have felt, or wool that I can felt:

Down at the bottom, it has a link to a store locator, wherein I could find out how early I can go into the store since I’m not sleeping so well without my hat (note: you actually can clutch a crushable felt fedora to your chest while you sleep, and it will snap back into shape when it’s time to slip into the rain).

So I click the store locator link, and:

The company apparently uses a third party bit of software that has gone night-night, and not in the cool queen with a sword way.

Which brings to mind a pretty good question: What do you do if your third party applications stop working? Do you have a back-up plan for an important Web site feature like the store locator? Do you just hope to wait it out and hope your vendor has not just been shut down by an overzealous government prosecutor in New Zealand? How fast do you act? Do you hide the link immediately while you frantically call your vendor’s customer support line, whose technician has left that particular cell phone in the club last night?

These are important questions to ask when choosing a third party piece of software, especially one sold as a service. It’s a bad thing to have to decide very suddenly.

And thank you for your concern about my ongoing hat situation. I’m back to Desperation Plan A: Hanging Out In Blues Bars and Hoping To Win A Cool Hat in a Poker Game or Steal One.

Categories: Software Testing

Tips on Working With QA

Thu, 09/27/2012 - 04:02

Working with Someone You Don’t Like?

Summary: It’s all in your head as you resent your own shortcomings and project them onto QA. Which is not perfect, but is better than you.

Categories: Software Testing

Strike That. No, That.

Wed, 09/26/2012 - 02:53

So I wore a hole in my favorite fedora, and I now live in a city without a hat shop in it. Not so much because it’s a small city, but because not many cities have hat shops any more. Well, the malls have baseball cap shops, but do you think I’m the sort of man who wears a baseball cap?

So I go to Zappos because I know they have a very liberal return policy, and I fully expect that I’ll have to try on and return a dozen or more hats before I settle on one (to illustrate: On my last visit to the venerable Donges in the venerable Milwaukee, Wisconsin, I tried on so many hats that the discouraged salesman muttered to a coworker that I wasn’t going to buy anything. I bought my third fedora that day).

And I browsed and I searched Zappos, and as I was looking the site over, I noticed something.

When you filter by brand, size, variety, color, and so on, it adds the filters to a pseudo-breadcrumb trail looking list above the individual selections. You can click the filter to remove it. Me, I was looking for the filter to eliminate hipsters wearing their fedora brims turned up. Come on, guys, what’s the deal? The brim is for keeping the sun off, not for catching the rain, you twee tweethings.

And I noticed something:

When you mouse over one of the terms, the tooltip explains you can click it to remove it. But the filters immediately to the right displays in the <strike> form with a line through the text.

Looks like someone got his or her index values mixed up in an array.

You know how you find these things? You mouse over the damn things. Or you don’t, and you don’t find them.

Me? I mouse over them.

(I know, you’re wondering: how does one wear a hole in a fedora? Well, my fourth fedora here, which I bought at a hat shop in Memphis just off the train tracks in 1997 or 1998, I wore almost daily for many years, gave it a breather, and have worn it again daily for some time. The hole is at the fold in the crown at the front where you grab it to take the hat off or to put it on. It’s also the spot that touches the pavement when you’ve got the fedora upside down on the sidewalk while you’re Street QAin’ for tips. So it’s natural that it would wear unevenly here. Strangely enough, my fourth fedora lasted longer than the first three.)

Categories: Software Testing

QA, Educator

Tue, 09/25/2012 - 09:05

Over at Dice TV, Cat Miller identifies some of the things software engineers don’t learn in school:

I agree with many of the things she presents, but I’d also like to point out what other thing computer science students don’t learn in school that’s important, but often overlooked: Domain knowledge.

It’s not the same as listening to your customer, because your customer and/or user has one perspective on domain knowledge, and it might not be deep nor broad. The customer might have just started the job last week and is trying to tell you how to write software to assist him with a job that he doesn’t know how to do himself.

Can you write computer software without domain knowledge? Yes. Heck, my whole schtick is that I don’t need a lot of domain knowledge when testing an application because software fails in predictable places because it’s software, irrespective of industry.

But I do pick up some domain knowledge from a little research to help supplement my understanding of how the user will use the software and to try to predict some patterns of behavior that real users will attempt when confronted with this strange piece of programming during the workday.

I’m not keeping it very secret, am I? Because I want the developers to pay attention to it, too. And project managers. And client engagement vice presidents. Try to glean a little about the problems the software is trying to solve instead of just solutions presented to you to code. Because where your assumptions and their assumptions differ, danger lies.

Categories: Software Testing

QA Music: Metrics

Mon, 09/24/2012 - 03:49

Well, the song is called “Still Counting” by Volbeat.

If I ever present at a conference, you can bet this will be the song that plays as I ascend the stage.

Uh, language warning.

Categories: Software Testing

Working Your Obliques

Thu, 08/30/2012 - 03:40

Luxury Cars Struggle In New Crash Tests:

Last year the National Highway Traffic Safety Administration (NHTSA) instituted more rigorous crash-testing procedures that made perfect five-star ratings tougher to come by. This year the Insurance Institute for Highway Safety (IIHS) is doing the same, and the first round of results finds many popular luxury cars to be lacking. Only three out of the 11 model-year 2012 cars tested under the Institute’s new so-called “small overlap frontal crash test” earned what would be considered passing ratings.

. . . .

In the IIHS’s new frontal test, cars are smashed at 40 mph with only 25 percent of a car’s front end on the driver side striking a five-foot tall rigid barrier. The Institute says the test is designed to replicate what happens when the front corner of a car strikes another vehicle or an object like a tree or utility pole in more of glancing blow, rather than a full-on or offset frontal collision.

This is another industry’s example of happy path testing. The full frontal crash test has thus far yielded results that made car makers design their cars to meet that test, head-on if you will, and to account for what happens in that test. That sounds an awful lot like what happens in happy path testing or the bare minimum “testing” that occurs in demos, internal and external, where someone shows someone else exactly how your developers have expected the user will use the software. Maybe there’s even some validation testing to make sure that, if a collision occurs, it’s handled.

But the real damage, and the real value of QA, is in the oblique testing, where QA doesn’t do what the user is supposed to do, but also does something that the developer doesn’t expect a user to do even when the user isn’t doing what he’s supposed to do.

The trick, of course, is to think that way and to see the possibilities of just tangentally using the software incorrectly or working just a little bit out of order to elicit a response that you can film into a compelling PDA for the benefits of not commuting or you can enter into the defect tracker.

It’s also a keen insight into why QA is never happy nor confidant in a product; sure, it might have passed all the tests (Ha! Just kidding! It just passed enough tests to satisfy the low standards of the project managers), but QA knows it did not think of all the tests, and out there, some user is going to find the right combination of events and the right angle and speed to hit the application to build his own catastrophe. If only I could think of that use case.

Categories: Software Testing

Remote Workers Not As Distant

Wed, 08/29/2012 - 08:31

Report: Remote Workers More Engaged, Committed:

If your employees come into the office each day, it’s natural to think that they’re engaged and well-connected with one another. But that’s a misperception, according to a recent blog post from the Harvard Business Review.

Scott Edinger, founder of Tampa-based Edinger Consulting Group, wrote that the physical proximity of an office gives the illusion that co-workers are communicative and working together efficiently. The opposite is true, however. Remote workers are actually more engaged and committed to their team, Edinger wrote.

One reason for this, Edinger pointed out, could be that members of virtual teams feel the physical distance between them makes interactions more valuable.

When people do not sit at adjacent desks, they try hard to connect with one another and maximize what little time they do spend speaking with one another.

He wrote: “What’s more, because they have to make an effort to make contact, these leaders can be much more concentrated in their attention to each person and tend to be more conscious of the way they express their authority.”

Working remotely does focus one’s attention and effort to the task at hand and to make sure that when you’re “on the clock,” you’re actually putting forth effort toward the company goals. You’re not as focused on making it until the end of the day as you are getting the tasks done.

I worked at a posting where we went from a remote office setup to an office space, and a lot of the communication remained through IM or email for tracking purposes or because we were too lazy to get up from our desks. As far as communication goes, the only real benefit of being in the office is being able to trap the developer who’s been avoiding you in a cubicle and make sure that he is, in fact, going to hear you out (as will the whole office by that time).

There are distinct benefits to allowing remote workers, especially in IT. I think it will continue, and this article helps bolster the arguments for it.

Categories: Software Testing