Archive for October, 2011

Everyone’s First Application Is Bug-Ridden

Friday, October 28th, 2011 by The Director

You know the common first program given in any class displays the phrase Hello World on the computer screen?

Yeah, that’s starting them off right. With a defect.

The “world” is a noun of direct address. Ergo, the phrase lacks a comma and should be Hello, world.

Speaking of classes, I’ve taken a couple or four language programming classes in the community college, and although they’ve focused on writing applications (or ceaselessly computing meaningless formulas using Java arrays) that do what they’re supposed to, but instructors never mentioned implications of quality assurance and testing. Maybe they thought the program would include it later, but at the time (the late 1990s), kids were coming into the field with nothing but those couple of classes at the community college. Those same kids are now the VPs. Makes sense, don’t you think?

What’s An Invalid Character Between Trusting Partners?

Thursday, October 27th, 2011 by The Director

In this case, it’s a JavaScript error:

Set partner UID to JavaScript Error

In this case, the partner passing an invalid character did not cause a catastrophic failure; instead, it spit up a JavaScript error and probably screwed up some user tracking metrics somewhere.

But what happens when your trusted partners pass your applications crap? And what’s with this “trusted” business? Your organization’s partners have less QA than you do. You need to test every little thing they pass to your application or Web site and make sure they won’t blow you up. Additionally, you need to test what happens when you pass things over there to make sure your mistakes won’t blow you up. And test to see what happens if your trusted partner isn’t there when you need it.

Any shared application programming interfaces, any interfaces period, require proper and suitable testing because software can fat-finger data, too. Just more efficiently and faster than humans.

It’s Just A Flesh Wound

Wednesday, October 26th, 2011 by The Director, the Internet site of the St. Louis Post-Dispatch, lives up to its name this morning, as it serves up fatal errors for St. Louis Cardinals fans seeking heart:

Missed it by 24 bytes

Trying to allocate 42 bytes led to this fatal error.

Although configuration of the server and the processes in the ops department are not the purview normally of QA, as the normal harbinger of doom, you can always ask, “What happens if we run out of server memory?” and “What happens if the database logs fill up?” Load testing might find these, but if you’re testing in a staged environment that gets cleaned out after every test run, you’re going not going to find out what happens when the crud accumulates in the pipes through daily usage. But it will be your fault for not finding it in performance testing.

So ask the unthinkable questions just to get someone thinking about them.

Some QA Animals Are More Equal Than Others

Friday, October 21st, 2011 by The Director

Larry Tieman in Information Week talks about how to avoid career-killing software projects and mentions the importance of elevating QA to an equal position as development:

Testing the software is yet another opportunity to bring in an independent perspective and reduce risk. Several years ago, I converted an application VP position to a testing VP position and formed an independent test organization. My intention was to put testing on the same footing as development, improve the quality of critical software, and give me another voice in a project. That VP also reported directly to me.

As you might know, I’m a big proponent of this sort of organization, partly because I was in a similar position in my last full-time posting as a Director who reported directly to the CEO and got to unabashedly air grievances where they would be heard.

Your quality assurance should not just be a cog in your development wheel where the process keeps rolling regardless. QA should be a log in the wheel’s path. All right, go ahead, submit the defect report for failed metaphor. That’s not working.

But you get the idea, or at least you get my repetition of the theme. Hey, repetition…. QA is the rumble strip of software development…. Someone stop me before I metaph again.

That’s Not A Bug; It’s A Feature. Really.

Thursday, October 20th, 2011 by The Director

When can you say that phrase unironically? ABC News’s blog reports on the heir to Stuxnet, Duqu:

Duqu is designed to record key strokes and gather other system information at companies in the industrial control system field and then send that information back to whomever planted the bug, Symantec said.

Look at the Symantec posting to which ABC News refers. Find the word ‘bug’ in it? Me, either. Because Symantec knows computer terminology.

QAHY grants you permission to say say “It’s not a bug; it’s a feature” only when refering to someone reporting on technology thinks bug is a synonym for Trojan horse.

The Most Basic QA: Someone Else

Wednesday, October 19th, 2011 by The Director

A do-it-yourself email communication shows a few flaws:

Text not inserted error.

You know what the most basic bit of quality assurance is? Having someone else look at it.

I know some smaller companies don’t have great budgets for proofreaders, testers, or professionals of any stripe to handle their client communication needs. Or maybe they have a marketing intern on staff. Whatever. Your organization should never send something out, particularly a formal communication, without someone other than the writer/designer reviewing it.

It wouldn’t be a bad idea to send yourself the email before you blast it to the subscription list, since the missing text and extraneous nonbreaking-space-missing its-semicolon might not display in the WYSAWTS (What You See Ain’t What They See) editor that assembles your text, your logo, your custom text, and your address into the final product.

Come on, have someone else look at it. It’s what the professionals do.

Spoiler Alert: Instructions

Friday, October 7th, 2011 by The Director

Twitter added the common social media widget that allows you to Tell a Friend by sending invitation emails to people you know. They put a lot of thought into the design, as you can see by the fact that the instructions are nearly invisible against the default background color:

The secret instructions

It’s nice of Twitter to hide the spoiler and compel you to highlight the test to read it.

SPOILER ALERT! You can send to multiple email addresses by separating them with commas.

A Null Interview Question

Thursday, October 6th, 2011 by The Director

You know what job interview question I hate to get and don’t like to ask? The commonplace general “Why do you want this position / do you want to work here?” question. I admit, I’ve fumbled on it a bit when asked. Sure, you’ve done some research on the company, you have a sense about what they do, and maybe you have talked to someone working there and get some inside information. Maybe not. Regardless, they’re asking me what I would think about the company from the inside while I’m on the outside.

I mean, regardless of the company, I want the following things when I take a job:

  • I want money. I’m not in this to change the world. I am a mercenary with a good skill set. I want a good paycheck. Also, they tell me benefits are important. But if you’re not going to offer me good compensation, I’m not going to work there.
  • I want a multiplier. Frankly, I’d like some benefit to my working there for some length of time related to the fact that I’m working there for some length of time. I want options, I want an employee stock purchase program where I get the stock of a growing company at a discount, and/or I want room for some advancement.
  • I want to do different things. I don’t want to sit in a cubicle, running the same set of test cases against a set of features or application for months, much less years.
  • I want to make a difference. I don’t want to just be a tip o’ the hat to the importance of QA and testing whose suggestions and defects are ignored. I need to see that I’m improving the product or project.
  • I need to be proud of where I work and what we do. This follows from many of the above, but I take pride in what I do, and if I can’t take pride in what we do, I won’t do it for long.
  • I wouldn’t mind a foosball table. I’ve worked on this pull shot for years; I’d hate for it to go to waste.

That’s what I want from any job, and here’s a dirty little secret: Outside of the assembly line, every employer will tell you that’s what it offers. I guess the answer gives the interviewer a sense of your priorities or something. Or maybe it’s one of the basic things the HR schools say you must ask, or the interviewers just remember getting asked that question at every job interview they’ve ever been to. When interviewing, I don’t ask it. Meaningless, I tell you.

On the other hand, a bit of a riposte is to ask your interviewer or interviewers, “How long have you been here? Why are you here?” Someone working at the company knows what it’s like to work there and what the company offers its employees, or at least the employees sitting in on your interview.

Management Lessons from Vince Lombardi

Wednesday, October 5th, 2011 by The Director

I don’t care who you are or where you’re from, but if you’re from Wisconsin, you idolize Vince Lombardi, or you’re a heretic. He coached the Green Bay Packers, the small-market blue collar National Football League (fĂștbol norteamericano, not soccer, you international readers) and led them to something like 14 annual championships in 8 years. He was that good.

Now, you might ask yourself what a football coach from fifty years ago can teach you about quality assurance management. If you don’t read anything but quality assurance books, you’re only going to read what other people think. Crikey, you do understand you have to get outside those narrow channels of thought designed by someone else to synthesize your own knowledge, and reading outside the industry can do that. What are you, a Bears fan? (Patriots fan: If you weren’t in that lesser American conference, you wouldn’t be much better.)

At any rate, a couple lessons distilled from The Coach:

  • The game is more complicated than it looks. You might think football is a couple seconds between whistles where big men hit each other. Below that tip lies an iceberg of individual team assignments working together in harmony and a whole glacier’s worth of individual and team preparation to handle any one game at a time. Like any software project or iteration, you need to remember the complexities and to account for them. A client wants a feature or a Web site? Sure, it sounds simple, and to the people who watch–that is, the clients or stakeholders–it is going to look short and easy. But if you’re managing it, you must not see it that way.
  • Your team has different positions made of different individuals who are motivated differently. Sure, you’ve got a project manager/scrum master, and he knows his role and what he’s supposed to do. The team’s success and performing as well as possible so not to get cut are definite motivators. Be that as it may, you’ll get the best performance out of that player if you know the player as well as the role and know how much to micromanage, how much to lay off, and whether to shout or to whisper. To be a leader, you not only need to lead, but you need to follow the player–to learn each his needs and personalities.
  • You have a chance to plan for each game. All projects are similar, following a set of constraints, but they all differ in the challenges faced within each one. Sometimes, the linebackers are fast. Sometimes the inside rushers can run right over your center. But the more you know about each game and each team, the better you can tailor your approach to the game or project. In college dorms, your developers could pick teams and start a pick-up game, but in the big leagues, it takes more than that.
  • You can plan, but you must adapt to the game at hand. Your planning will have gaps. You planned all week to contain that #56, but he goes down with injury, and instead of a speedy safety, you’ve got a mountain of a man who knows his zones. The rain on gameday makes for a slippery ball. Circumstances arise that you might not have planned for, or maybe it’s just that you have to use a backup plan instead of the first plan. Requirements, timelines, personalities, and every element within your project are variables, not constants. They will change in the middle, and you have to adapt. Hopefully, your understanding of your team and the project at hand will give you a good head start on changing appropriately.
  • You can adapt, but your success will come down to individual performance. You’ve got a plan, you can adapt, but if your developers turn in buggy code, you’re still sunk. You need to motivate the individual performers (see above) to get the best from them, and if they’re not working with the team, you still need to take action with that mouthy wide receiver.
  • At the end of every project, you can find something to improve with the team. You beat the Bears 49-0? Great! But look how the left tackle missed a block on the sweep. You got the development in under budget and passed the application off to the testers only three days late? You can do better. Even when everything goes right, it could be made to go righter. In the next game or project, the improvement you put in place can be the margin of success if something else goes wrong.
  • A hamburger and coffee is what a successful leader eats for lunch. Not sushi. That’s just pretentious.

That’s some of the reminders I got from this book, wrapped in a different metaphor (football) that makes it fresh. Your insights might vary. But, jeez, read something besides the industry standard material to make sure you think differently from the industry standard.

Double-click That Link

Tuesday, October 4th, 2011 by The Director

A pretty stock naughty thing to do when testing a Web application is to double-click a link instead of single-clicking it.

But, Director, what sort of madman would do such a thing?

  • Someone used to the desktop paradigm might do it just because he or she does not know not to (someone like Roberta).
  • Someone like me who doesn’t see any action immediately and wonders if he clicked the link or if he clicked while the cursor was not on the link.

Case in point: In WordPress, you can move an item to the trash by clicking the link labeled, appropriately, Trash:

The mouseover indicates the link is selected....When you click....

If you click the link, the page comes back with the item missing from the list and your trash incremented by 1.

If you double-click the link, though:

When you double-click, hilerrorty ensues.

Hilerrority ensues! The application deletes it and then tries to delete it again! This results in an unspecific error condition, but what would happen in your application?

Come on, guys, the user might double-click a link, and your Web application needs to take that into account and to handle it elegantly. More elegantly than a non-specific error message with no further navigation, certainly.

Even Spam Generators Have Defects

Monday, October 3rd, 2011 by The Director

Come on, guys, put a little effort into trying to fool me. If you show me the whole decision tree, I’ll suspect you’re not really a reader.

The spam as Mad Libs

Doesn’t it remind you of The Lovin’ Spoonful?

Of course not. You’re all pups.

wordpress visitors