Archive for September, 2010

Sorry, I’m Not Going To Fix Your Inconsequential Error

Thursday, September 30th, 2010 by The Director

When I went to read a story on Yahoo!, I got a little inconsequential error at the bottom of the page:


Sorry, I'm not that eager for that ad.
Click for full size

Gee, I’m not that eager to see that particular ad. Better luck next time!

Of course, when I went back to snag the URL in Internet Explorer, I got a host of other errors. Not only a host, but a whole dinner party full: (more…)

The Lesson Is Lost

Wednesday, September 29th, 2010 by The Director

I follow a number of developers on Twitter, and as the new Twitter has opened its raincoat and exposed itself to them, many of them have tweeted about the various problems with the new Web interface and how it doesn’t work with them.

Hey, count me in on their sentiments. However….

I expect that many of those complaining are doing so in between working on Web sites or applications that they’re developing according to a large set of their own preconceptions and desires to do it that way because they think it’s cool, and the users will just have to be trained to do what the developers want to write.

QA Music: QA Till You Drop

Monday, September 27th, 2010 by The Director

Rick Springfield, ca 1984:

The mullet is the hairstyle for QA. If I had enough hair left for one, you’d better believe I’d have one. It’s so hard to effectively and aesthetically thrash with a buzz cut.

No One Would Use Nonalphabetic Characters In A Television Show Title

Friday, September 24th, 2010 by The Director

Courtesy of CBS, we have a Never Happen happening:

In an effort to turn a popular Twitter feed into a broadcast comedy, CBS has given “$#*! My Dad Says” a rather un-DVR-friendly title.

Try to search for “$#*!” using your DVR’s remote control. Go ahead. We’ll wait.

It seems DVR designers quite understandably never suspected that a network would launch a TV show that started with the word “$#*!.”

Of course they would never do that until they did.

(Link seen here.)

Book Report: The Bug by Ellen Ullman (2003)

Thursday, September 23rd, 2010 by The Director

[Spoiler ahead.]

Well, there it is. A novel about QA. Well, no, strike that, it’s a literary novel set in software development in the 1980s where a software defect is the MacGuffin and one of the main characters is a software tester.

Not by choice, oh, no. You can tell you’re reading a LITERARY book because the main character is clear to state that she has a doctorate in linguistics and only ends up working as a software tester when her academic career peters out. This is how you direct a book to an audience that does not work in the field the book covers, by saying ATTENTION! This character is the fish out of water and will explain to you the things you need to know because this character is just like you (in the field of academics or whoever reads Literary novels) except they work somewhere exotic (software development in the 1980s).

The book, as I mentioned, takes place at a database developer in 1984. They’re building a database from the ground up, including a GUI front end written from scratch that uses a mouse and everything. The main character, aforementioned, finds a defect that crashes the system, but is hard to replicate and appears to happen randomly, but usually in big demos. The book bounces back and forth between a first person double-effect narrator (since the story is told from present day ca. 2000ish after the dot.com bubble bursts, spurred when the narrator sees the one of the old screens still in use) and a limited omniscient narrator peering into the point of view of the developer to whom the defect is assigned.

The defect itself is a MacGuffin since the book deals mostly with the break-up of the tester’s and the developer’s personal relationship and the breakdown of the developer as he doesn’t think he’s a good developer and struggles to find this bug. That’s pretty much it. Enough technospeak and actual code and UNIX commands thrown into the mix, kind of like you’d find Hindi interspersed through a Kipling work to add authenticity. The tester finds self-actualization or empowerment by learning to code. The developer abruptly hangs himself, and even that did not cheer me. Uh, retroactive spoiler alert.

I didn’t care for it much, either for the plot nor the technical aptitude. The main characters are pathetic; I didn’t like either of them. The secondary characters are very, very stock and cardboard. The other testers are, essentially, the boss who is tough and fair minded and the other one whose dialogue mostly consists of her character tic of saying, “Meep.” The developers are mostly interchangeable except for their specialties, told to us of course. And I don’t know what the point of the frame story is, frankly. To show us the pathetic main character becomes rich but remains pathetic? Or to allow someone to feasibly set a book in 1984 when it’s written in 2002?

The best QA fiction is definitely genre fiction, mainly a thriller. Unfortunately, it hasn’t been written.

Books mentioned in this review:

Banish Lorem Ipsum

Tuesday, September 21st, 2010 by The Director

In case you’re looking for a little Hamlet test of your own or need fill copy for a design, you can use Fillerati to create long strings from various literary texts.

(Link seen in the Twitterverse. Sorry, I forgot who betweeted it.)

How Much Do You Trust Your Third Party Partners Now?

Tuesday, September 21st, 2010 by The Director

Your organization probably trusts its third party integrated software partners as much as J.P. Morgan used to:

JPMorgan Chase is trying to move past three days of problems on its online banking site with an apology and an explanation that seems to put the cause on a third party.

The bank’s online site went offline Monday night and remained offline Tuesday. Service appeared restored by Wednesday, although there were some reports by Twitter users of problems.

The bank, in a statement posted online, said it was “sorry for the difficulties” that customers encountered, and said “we apologize for not communicating better with you during this issue.”

At first, Chase simply cited a “technical issue” for the problem. It has since provided a little more information.

The bank, the nation’s second largest, said in a separate statement that a “third party database company’s software caused a corruption of systems information disabling our ability to process customer log-ins to chase.com.” It added that the problem “resulted in a long recovery process.”

Now, how can you try to keep this from happening to you?

  • Compel your vendors to tell you about their updates. Ideally, you would get a chance to test your software against their new versions before they promote them to production, but at the very least, they better tell you when they plan to put things up so you can test immediately. Remember, your “trusted” partners are organization filled with the same lying developer dogs as yours, but without the QA.

  • Don’t do business with companies that practice continuous deployment. Seriously, they can promote at will and at whim, so your mission-critical software can fail at any time, without any warning, and without any clue that it’s not your fault.
  • Run automated smoke tests against your production site as often as you can stand. Depending upon the nature of the application, this might only be daily, but the more frequently you can sanity check your production environment, the better. There’s nothing better than calling your head of development on Christmas Eve to tell him the site’s down before your users or clients even know.

Remember, you have no trusted partners. You should trust them even less than you trust your own organization, if you can imagine that.

I Suspect There’s A Job Opportunity Here

Monday, September 20th, 2010 by The Director

CME says ‘sorry’ for dummy orders:

CME Group, the world’s biggest futures exchange, has said it is “deeply sorry” for mistakenly placing 30,000 fake orders it generated as part of a quality assurance test on its active energy and metals markets on Monday.

You know how easy that is to do, don’t you? Set a web configuration file wrong, put the wrong IP address in somewhere, and bam! your company loses $100,000. But your test passes!

Man, this is why I dealing with money or people’s safety in QA gives me fits. Therefore but the grace of luck go I.

QA Music: The QAing Ride

Monday, September 20th, 2010 by The Director

Here’s a song that captures the countervailing currents of absurdity omnipresent in the SDLC process through the metaphor of living in the United States:

Or maybe he’s singing about living in the United States but it really reminds me of working in QA.

Answering My Own Interview Question

Friday, September 17th, 2010 by The Director

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.

Some Epic Failures

Thursday, September 16th, 2010 by The Director

Computer World lists 11 bugs that were a big deal.

You know which bugs are a big deal? Those criticals atop your list that development is going to play dev tracker games with since they’re not sure they’ll get to fixing them before launch. But here are some of my favorites I’ve found:

  • Trying to print something from the application rebooted my workstation. Every time. Seems my Java version and my print driver weren’t playing with the application so well. However, since it was just my machine, no need to fix it! That’s the very attitude that kept me from being a stock option millionaire by now. Thanks, guys.
  • Sketching a molecule that’s 1 mile wide or that has two bonds to a hydrogen atom blows the software up.Who would do such a thing? Someone making a mistake. I’m pretty sure they fixed that.
  • The site bombs out with a few users after a couple seconds. Seems each page on the site wanted to validate schema with W3C, and after a couple pages in a couple seconds, W3C doesn’t want to talk to your DDOS zombie any more. They fixed it after trying to say it was a problem with the test environment.

What are some of your epic bugs?

He’s Not QA

Thursday, September 16th, 2010 by The Director

Sounds like a Google Site Reliability Expert got into trouble:

Google this week confirmed that it fired an engineer who accessed the Gmail and Google Voice accounts of several minors and taunted those children with the information he uncovered.

David Barksdale worked in Google’s Kirkland, Wash. office as a site reliability engineer, where he had access to user accounts. As first reported by Gawker, Barksdale accessed the Gmail and Google Voice accounts of several teenagers he met through a local technology group, and made them aware of the data he’d uncovered.

The title sounds like it might be related to performance testing or something, but it’s not:

Google.com site reliability engineering: Google Site Reliability Engineering (SRE) consists of software and systems engineers worldwide who specialize in troubleshooting, tools development, and production systems automation. As a Site Reliability Engineer, you will consult with software engineering teams during the development cycle to help developers understand and comply with our architectural guidelines for reliability, speed, and scalability. You will help manage ongoing capacity planning to handle Google’s rapid traffic growth and global expansion. You will also partner with software engineering teams during the launch, deployment, and maintenance of new products and services. With your depth knowledge of optimization, traffic load balancing, and system enhancements, you will be there to manage and maintain services, ensuring their reliability and availability for hundreds of millions of users worldwide.

QA does not taunt children except those adult juveniles in the development department. Like Site Reliability Engineers.

Every QA Lab Or Cubicle Needs Emergency Equipment

Wednesday, September 15th, 2010 by The Director

Fire extinguishers? Who would want to extinguish fires? I mean one of these:


In case of prison riot, break glass
Click for full size

This Web Site Best Viewed In Your Imagination

Wednesday, September 15th, 2010 by The Director

I can only guess what browser the designers used when putting together this program.

IE? Probably not, since the Enter button lacks text:


It looks fine in IE except for the fact that it does not.
Click for full size

Firefox? Well, maybe, if you discount the fact that the Enter button image was designed for use elsewhere:


It looks fine in Firefox except for the fact that it does not.
Click for full size

Swell.

Hey, if you’re too rich, we don’t want you to enter:


No rich people allowed!
Click for full size

Because none of our advertisers like households with incomes of $100,001 a year or more.

How does that confirmation e-mail display?


You just have to read between the blank lines.
Click for full size

About as well as you would expect.

And what happens when you click submit without entering an e-mail address on the tell-a-friend form?

Sorry, I previewed that yesterday.

On the plus side, rest assured that this program was not as cheap to the client as it looks.

Gallery of Stack Traces: Not A Valid E-mail

Tuesday, September 14th, 2010 by The Director

What happens if your application doesn’t handle invalid e-mail addresses?

.NET handles it for you:


This is not the e-mail address I was looking for
Click for full size

You really should never see this one, but I could say that about all of these, couldn’t I?

Friday Afternoon Build Theme Music

Friday, September 10th, 2010 by The Director

Hey, to celebrate that hastily cobbled together Friday build delivered just in time for the developers to leave on time, QAHY presents the theme song for Sanford and Son:

Thanks, guys! We’ll be glad to work late on Friday night and come in on Saturday to discover just how bollixed you’ve made it.

And since we’re going to be here anyway, we’ll be glad to watch over your empty cubicles and offices to keep them safe.

This Month Only: Spelling Lessons 100% Off!

Thursday, September 9th, 2010 by The Director

From a recent The Teaching Company catalog:


Someone's not going to hear the end of this, I guar-en-tee!
Click for full size

That’s not something a quick little edit in the content management system will fix.

That’s Something You Can Hang Your App On

Wednesday, September 8th, 2010 by The Director

Friends, we’ve already covered file upload test cases, haven’t we?

Well, if you’re new here, let’s recap:

  • Large files: make sure the application can handle 1Gb or more or stops user from uploading them.
  • Empty files: make sure application can handle 0 kb files.
  • Invalid files: make sure application can handle files that are corrupted.
  • Wrong file types: make sure application can handle when you try to upload the wrong type of file
  • Long file names: make sure application can handle long file/path names.
  • Invalid file/path: make sure application can handle invalid locations if you’re allowed to type in file names and paths.

The little Space Your Face Flash ditty created by NASA hangs on the 2nd and 3rd of the bullets above:


Spacing your infinite reaches of space
Click for full size

Worse, it hangs with some cheaply produced space groove playing.

QA Slang You Can Use

Tuesday, September 7th, 2010 by The Director
Magic Carpet
A project plan that miraculously gets the team from here to a destination or deadline through generous application of magic.

Example: A go live date in two weeks? Sheila wove us a magic carpet on the CPC account. We might as well be going to Arabia.

How Can You Tell An Experienced Automated Tester?

Monday, September 6th, 2010 by The Director

How can you tell an experienced automated tester from either an automated testing software solution vendor or someone who’s heard a buzzword dog whistle and is salivating on cue at the chance to work somewhere that’s included Automated Testing on a job posting?

An experienced automated tester is going to spend more time trying to tell you what automated testing isn’t instead of what it is. Because you’ve probably got a pie-in-the-sky you’re slicing to share for dessert.

Cue Trisherino:

I think people have a tendency to greatly underestimate the difficulty of writing a good GUI-automation suite. It’s not as simple as record and playback, and it’s not like building regular software.

I’ve seen experienced developers underestimate it many times. Inevitably, they end up getting very frustrated and complaining about how rubbish the automation tools are. And yes, the poor quality of automation tools is definitely part of the problem. Developers are used to using very polished tools, lovingly crafted by developers, for developers. Testers are used to using either bloated overpriced commercial tools, condescendingly oversimplified so that “anyone” can use them, or well-meaning but under-maintained free tools, struggling to keep up with the latest technologies.

What she said.

You know why developers are so hot for automated testing? They’re used to thinking they can push software around. Unlike some QA people who refuse to be intimidated by their obvious GENIUSSSS!