QA Hates You

Killswitch Engage, "In Due Time":

So I took This BBC News grammar test, and I got a perfect score, natch:

And a bug, natch.

Come on, kids. One simply must check numbers greater than one digit (or more) to make sure they fit inside your little design elements.

Some days, I feel like the Dowager Countess, sitting here marking pointed remarks as I watch the old order of people caring about this stuff falling apart.

Stone Sour with “Absolute Zero”

Good day!

Tim McGraw, “The Cowboy in Me”

The urge to run, the restlessness
The heart of stone I sometimes get
The things I’ve done for foolish pride
The me that’s never satisfied
The face that’s in the mirror when I don’t like what I see
I guess that’s just the cowboy in me

It sounds a lot like the typical workday in software testing.

Ever get asked why a user would do that? Of course you do. You’ve already been asked that today.

Here’s a little story for you about why the ball player trying to steal third base ended up on first base:

This guy stole second. Then he tried to steal third but somehow wound up on first. Then he got thrown out trying to steal second again. All in a span of five pitches.

The result, as far as we’re concerned:

The part where a runner on second base finishes the next play on first base? It’s not possible to score that without crashing every computer in America.

“There’s no way to do that,” longtime official scorer and SABR historian David Vincent said Saturday. “Not covered in the rules. A runner on second base going to first base? That’s impossible.”

Now obviously it’s not “impossible,” because it really happened. But tell that to the computer programmers of America.

“All the computer software — none of it will handle that,” Vincent said. “You don’t run the bases [from] second to first. Any software that processes play-by-play won’t accept that.”

So because it’s theoretically impossible, the official box score of this game listed Segura as having been thrown out stealing third — even though he slid into second. Huh?

“That’s because the play-by-play listed him as staying at second base [because it couldn't compute that he was actually on first],” Vincent said. “So then he had to be caught stealing third. But that never happened. So that has to get changed.”

Right. But that’s not all. The official box score and play-by-play also said that Braun got caught stealing second.

So why would a user do that? Because the user could do that. And just because someone has not done that does not mean someone will not do that in a strange set of circumstances you cannot anticipate now.

(Link via tweet linking to this article.)

In This Moment, “Comanche”:

In This Moment is one of those bands where you might mistake the band’s name for the song title. But I assure you In This Moment is the band’s name in this case.

A little story to talk about some of the ways our inattention can lead us to miss some mistakes.

For years, I’d heard about an awesome British television program that, although it aired on PBS and had not reached popularity among mainstream Americans certainly got its discussion amongst the tech crowd which tends to favor BBC programs that air on PBS. The show?

Downtown Abbey

Or so I thought. I had seen discussion of the program on the Internet, as I mentioned, and and I watched the introduction to it seven times, and I saw it on a Roku menu many times. I even started a Twitter hashtag called #DowntownAbbeySpoilers to demonstrate my particular brand of wit and to flaunt my ignorance before the Internet. It was only in the seventh episode, which includes a scene at the Downton train station clearly labeled as such, did I discover my error.

I was chuffed, to say the least.

I’d read the word as Downtown at some point, maybe a misspelling or a bad pattern matching on my part, and every time I saw the title, my brain filled that Downtown instead of Downton. Every blooming time.

I started planning this post in my head, I encountered a misspelling in the application I’m testing. Although I’ve hit the screen a number of times, I’d missed the misspelling every time I saw the page previously until just yesterday, when I happened to look at the extraneous letter in the middle of the word. Other times, my eyes had skipped right over the defect like a smooth stone over still water.

The way to avoid these types of oversights, as I always have said, is to slow down and to look at everything with fresh eyes as often as possible. Take some time to read every word and to test every control in different combinations. Focusing on the higher-level functions of an application is very important, but focusing on individual parts of it at a very atomic level will find a number of problems that your users will eventually find if you don’t (and fix) first.

Now, onto the second error: trusting the context.

My UK readers and many of the Downton Abbey fans here in the US and elsewhere might be chortling about what I said above: I was chuffed, to say the least.

It sounds like a combination of chagrined and maybe huffed, doesn’t it? You’re forgiven if you assumed it meant something like that from context. But chuffed means pleased. I was not pleased at all.

This kind of oversight comes when you trust the context of something, generally in terms of application behavior. When you click that button, of course it does that. It’s not crazy enough out of whack to be an obvious bug, so you let it go. This happens a lot in two cases: if you’re testing something in an industry or vertical in which you’re not already steeped, like counting DIDs for a telecommunications company’s order scheduling software. If the number of DIDs doesn’t match the number of telephones and never has, will you notice it as long as you can save the order and make sure it displays properly on the technicians’ tablets? Maybe not.

The other place where you can get into that sort of trouble is after you’ve tested an application for a long enough period of time that its evolution gets a little mixed in your mind. Did that used to work? Did it used to do something different? Should it do something other than what it does?

To try to minimize these style oversights, don’t trust the context. Try to learn why the context is the way it is. If something seems strange, ask. And if the person you asks says, “Just because,” “Trust me,” or “It’s always been that way,” open your defect tracker. Because QA has always been that way, just because. Trust me.

So the lessons are, again, slow down and learn as much as you can while you’re testing something to test it most effectively, and not to trust yourself or your context because you’ve been wrong before. Or at least I have. AND I AM NOT CHUFFED ABOUT IT.

QA shares a lot of qualities with the popular conception of the diva. We’re always demanding attention, and when we have attention, we make demands.

Researchers who have studied divas in the wild recognize two kinds: healthy divas, who aren’t unhealthy divas, and unhealthy divas, who are the divas who’ve built the popular conception of diva.

Regardless, the Wall Street Journal recently featured an article on the difference:

Divas, by definition, are high-performing, high-maintenance narcissists. Some are needy, demanding, negative—and talk almost incessantly about themselves. Researchers say these are “unhealthy divas” and the source of their narcissism usually is low self-esteem: They are constantly trying to pump themselves up.

Yet, believe it or not, researchers say some divas are healthy. They adore the limelight and work hard to be always front and center—but they are willing to make room for others. They are spirited, fun and positive. Because they assume everyone around them is interested in them, they share a lot of themselves—and in this way bring people together. They have the ability to help others enjoy things that aren’t normally enjoyable, whether it’s a long line at the store, an office meeting or dinner with the boss.

Within the article, you’ll find a number of differences delineated between unhealthy tantrums and expecting and settling for nothing less than the best because, baby, you deserve it (and so do your users).

Also, to prove its worth the the QA community, please note the Van Halen Brown M&Ms story appears, so you know it’s got to be True (much as things on this blog are, as I mentioned the story last year).

I’m a little behind in my newspaper reading, as you will see. But this Non Sequitur cartoon from last week might describe how one comes to become a software tester, or how one becomes a software testing consultant:

Yesterday, the day before the annual tax filing deadline in the United States, the online version of Intuit’s TurboTax software suffered a brief outage:

TurboTax, the popular tax-filing software, went offline briefly on Sunday — the day before the filing deadline.

Users had problems entering data on the Web site, according to angry Twitter messages directed at the company.

“We’re having problems with TurboTax online. We’re in process bringing back the experience u expect. Updates 2 follow,” the company said on its official Twitter account Sunday evening.

Less than 10 minutes later, it issued another update saying the site was functional again. For those still experiencing problems, the company suggested closing browsers and opening the software in a fresh window.

Well, they might have lost a couple of customers and might have put some consumers properly off the idea of ‘the cloud,’ but at least they’ll have some better data for the next set of test managers and/or operations people to analyze for planning purposes.

Metallica.  Make them think it’s a bad day.

Screenshots of Despair.

Via tweet:

Screenshots of despairscreenshotsofdespair.tumblr.com

— Jonathan Korman (@miniver) April 9, 2013

To begin with, the thing was so antipodally at variance with the whole chain of horrors preceding it–the change of mood from stark terror to cool complacency and even exultation was so unheralded, lightning-like, and complete!

–H.P. Lovecraft, “The Whisperer in the Darkness”

New career goal: I’m going to start a defect with To begin with, the thing was so antipodally at variance with the whole chain of horrors preceding it at least once.

Somehow, one could build a metaphor about the IT world being like a stuffed animal death match, so here’s a little something to get your imagination running in those lines: Imagine Dragons with “Radioactive“:

Come for the cool anthem, stay for the nightmare fodder.

He wants us all to know about this Tumblr of animated gifs called DBA Reactions.

Thank you, that is all.

Everybody has focused on the fact that the new CEO of Yahoo! has ended telecommuting in the company, another soul-crusher occurred at Harley-Davidson: they banned rock and roll music:

Hundreds of Harley-Davidson employees learned through a memo last week that their radios and music being piped onto the factory floor would be kaput by Wednesday — part of a continuous effort to improve safety.

No headphones. No headbanging. No rock ‘;n’ roll.

Just the sound of motorcycles being made. It’s the sweet sound of productivity for a Fortune 500 firm whose earnings have made a comeback since an organization-wide restructuring began in 2009.

But it wasn’t one incident in particular that made them “stop the music,” as singer Rihanna says.

“It’s a distraction,” said Maripat Blankenheim, director of external communications for Harley. “It’s really important for people – no matter what they do – to be focused on what they do.”

The memo, authored by John Dansby II, vice president for manufacturing, reflects that mantra.

“As you are aware, it is imperative that we improve our safety and first-time quality performance,” he writes. “Too many distractions and potential hazards still exist in the workplace that impact our performance every day.”

Jeez, Louise, what will people at Yahoo! do if they cannot blare AC/DC while they test?

You know, when I worked in a plant, we didn’t get radios, and I had to compensate by tacking up a poem to memorize while the Didde-Glaser ran. That experience pacing and talking to myself provided me with valuable experience I apply to QA every day.

(Part I, Part II, Part III, Part IV)

Brad, the Middle Manager
I eventually moved on from the blue collar world (and, if we’re counting, the pink collar world, since that’s the color sometimes assigned to retail work) into the white collar world, although by the time I got there, business casual was the norm and the collars were not often white. Now, in many places, the collars at all are optional. I made a couple of moves from technical writing into software quality assurance, back into technical writing, and then onto Brad’s team as a Quality Assurance Analyst I.

Brad managed a team of Quality Assurance Analysts working on a chemical modeling and lab benchtop software suite for a large pharmaceutical firm. By the time I got into my cubicle, the project was late and on the verge of losing money, but that was beyond my purview. That was in Brad’s world, as it were.

I don’t know Brad’s background, but I do know that it was not anywhere in the technical realm of software. He did have an MBA, though, and when the company was hoping to move from a product-based business model (you build it, you sell it, people buy it) to a project-based business model (you promise to build it if someone promises to pay for it), it staffed up its ranks, including its management team. The org chart featured a vice president in charge of projects, a director in charge of projects, a bunch of managers in charge of teams on the projects (at this time, the plural form of project was still only anticipated, and the only actual project, as I mentioned, was in trouble), a set of leads on each team, and then team members. That’s three tiers of management where technical skill was optional, and in Brad’s case was sorely lacking (although his hiring of me proved his keen insight into the matters of personnel).

As far as I could tell, Brad’s main job duties included sitting in meetings with other managers and sometimes team leads (but not the actual meetings with technical staff—the team lead took care of that and assigning roles and day-to-day duties). I am pretty sure he made some PowerPoint presentations and reports of some sort, along with annual goals for the team and individual reviews of his team. But he pushed paper and handled the Parkinson duties of the team.

An anecdote into interacting with Brad: I wanted to buy a $35 text editor that I’d used before to help edit the various and sundry text files a Quality Assurance Analyst I would edit during the course of the day, such as configuration files, batch files, and the special files used by chemical modeling software import features. I told Brad I’d like it. He put it into his process and workflow, and he wanted a business case for it. So I wrote a document that included a comparison between the installed text editors, Microsoft Word and Microsoft Notepad, the advantages of the text editor I wanted (IDM Software’s UltraEdit—since I’ve named its competitors already loaded onto my workstation at the firm, I might was well offer an unsolicited testimonial to it). The document identified all the text files I’d edit with it as well as future uses for it (including the buzzword XML, which would prove important although not relevant at the time).

After reviewing the document, Brad called a meeting of the Quality Assurance Analysis team to discuss it. Before that meeting, though, the team lead called a pre-meeting to discuss it. The four QA team members gathered in a meeting room to discuss what a text editor was and why QA might need it. The importance of editing the data files we’d need to test or reviewing log files was a bit lost, but I mentioned XML, the buzzabbreviation took off. Although the product did not use eXtensible Markup Language now, someday it might. The buzzword traveled up the food chain, and Brad turned the either approved or got approved the purchase.

The process to approve the purchase cost more than the purchase itself, but it was the sort of thing that filled Brad’s day. Until the company, trimming its headcount to stave off the disastrous consequences of its altered business model, cut Brad during a set of layoffs. After that time, the QA Team Lead reported directly to the Director or the Vice President with no productivity loss.

Unlike Ron, Brad was not lost in the trappings of being a successful businessman; Brad was lost in the trappings of being a manager. Brad illustrated to me that managing people doing a task works best if you understand the task at hand and don’t get yourself into a situation where your only skill is holding meetings, preparing papers, doing group projects, and doing the sorts of things that earn you an MBA or used to suffice when you reached a certain level within a very large corporation.

In today’s fluid, lean business world, you have to make sure that you grok the thing you manage and that you can improve the efficiencies and add value to those under you. I kept this in mind when I reached the executive level and spent my time helping my people solve the problems they found in their jobs and increasing the company’s efficiency by boosting the employees’ efficiencies. If I didn’t call enough meetings, so be it. The point of the job was to do the job, not to talk about it.

Conclusion
You can read a hundred books about good business practices, but the lessons within them will only be the abstract knowledge distilled from a cavalcade of someone else’s success. The stories and ideas within them might slide from your consciousness like raindrops from a freshly washed (with the deluxe package including the clear-coat sealant) car. Even when you look back to the good bosses you’ve known personally and have worked under will seem translucent in the pleasurable glow you had from working with them and succeeding in your position therein.

But the lessons you learned from your bad bosses are distinct because they were painful. If you, with enough therapy, can look to them to understand why your bad bosses were bad bosses, you can be a better boss yourself. I’m not talking about studying the psychological motivations or getting in touch with them emotionally to understand what compelled them to behave as they did; I’m talking about understanding why what they did was ineffective as a manager or leader.

Besides, they took a little bit of your soul in those brief hours/days/weeks/months/years you worked for them. Shouldn’t you take a little something back?

(Part I, Part II, Part III)

Lee, the Purchaser
The art supply store hired me as a shipping/receiving clerk, which was mostly checking in the supplies as they came off the truck to make sure that Koh-i-noor had sent us the number of pens they said they did and the number of pens we had actually ordered. The store catered to the business community who needed foam board for presentations and to students who needed specific pads of paper for their art classes. In addition to clerks, commercial inside sales people, and a shipping/receiving clerk who was also responsible for custodial duties, small computer administration, and miscellaneous electrical repairs, the store had a dedicated purchaser, an employee whose full-time endeavor was to map the sales of individual products and to order enough to meet anticipated demand. Her name was Lee.

In the early 1990s, personal computer usage was in its infancy, and the store’s inventory was maintained on a minicomputer with thin client terminals. Lee printed out reams of product lists to use as she checked the back stock and the items on the shelf to make her predictions, which were more astrological than based on past sales.

In the late summer, as the store was preparing for the back-to-school rush that produced much of the annual sales, a truck arrived with pallets of paper products, from notepads to 4’ by 6’ boxes of heavy cardstock. The receiving room of the store could handle about 3 pallets of product comfortably. This particular load comprised 14 pallets, including two double-sized pallets containing bins of foam board. The truck driver mercifully left his trailer at the exterior loading dock for a half hour lunch to give the receiving clerk the chance to restack and rearrange pallets to fit six pallets uncomfortably into the warehouse.

“Why so many?” Lee asked, incredulous. She carried a printout of the expected order. The receiving clerk took the papers from her and pointed out how the four on this line translated into so many cubic feet, how the ten on this line translated to so many more cubic feet, and so on. The order matched the delivery.

Fairly often, we worry that someone has forgotten to take the customer into account when making plans or acting. However, Lee, working with numbers in the abstract and little ticks on lines on sheets of paper, became divorced from the realities of the product. The concrete products that filled the warehouse and many backaching hours for the receiving clerk as he somehow fit these products into slots and shelves to make the warehouse navigable.

Lee taught me to remember the customer and the product. In too many instances, particularly in the software industry, the customer-facing professionals keep the customers too much in mind and have little understanding of the technologies of the product or even the things for which the customers will use the software. Instead, their focus remains on pleasing the people who place the orders, and they might find themselves promising more than their teams can deliver. Much like Lee might.

(Part V)

(Part I, Part II)

Ron, “I Own the Business”
Ron was an older gentleman operating a computer assembly and sales business from a converted shotgun shack in the southwest corner of St. Louis. The living room was what you might call the commercial sales division with three desks and tables piled with papers and unopened mail. Ron was not very organized. The dining room was a retail sales floor of sorts with a number of custom assembled machines on display to, generally, nobody. The old kitchen held the bookkeeper and the woman whose sole job was filing return material authorization requests for the cut-rate components that Ron favored. An addition and shed that filled the former back yard held a number of young technicians assembling computers and slightly older technicians repairing computers. The one car garage facing the alley was the loading dock, with a desk for the receiving clerk to check in and label individual components to make it easier for the RMA lady to process when they came back and steel shelves that held a number of broken bits of computers Ron accepted in trade. Piles of boxes littered the floor, since the receiving clerk discarded packing material over his shoulder as he worked. Ron hired me to be a clerk Friday, which meant to do whatever he wanted. In my three months there, this included filing copies of invoices from years past, acting as accounts receivable by calling, without training in the niceties or legalities of bill collection, numbers printed on inches of fan-folded, pin-fed, green-and-white lined paper, receiving (and receiving a tongue-lashing for wasting time in cleaning up the loading dock), computer delivery or pick-up in the far-flung suburbs of St. Louis, and ultimately as a computer assembler when one left in a fit of apoplectic pique.

Ron was the worst boss you could imagine: His self-importance and scattered brain combined to provide moments where he would cross from the front office through the showroom to the accounting room to get the accountant to get “that guy” (the clerk Friday) to come to place a telephone call for him. Instead of coming to get “that guy,” the accountant instead made the call from her phone to ask the call recipient to hold for Ron. Another time, Ron came up to me as I was stocking parts, and led with a noun of direct address to address me directly: “Mark,” he said, gesturing at me. “Brian,” I corrected. “Mark,” he continued, wondering what the gag was. Ron fired me, essentially, by telling me that I would not be needed after Christmas when I told him I was taking the week of Christmas off to have dinner with my father 400 miles away. My father was in a brief remission from cancer that would prove terminal, and my brother had leave from the Marine Corps. I took Ron seriously, unlike one of the sales people who brought in doughnuts every time Ron fired her—and Ron’s wife assured her that she was not fired. But on the Monday of the week after Christmas, Ron called me at home the first work day after Christmas to find out where I was. After I could not convince him that he fired me, I quit over the phone. “Without any warning?” he asked.

I’m sorry to go on so long about Ron, but he is a treasure trove of stories that seem parablic, but actually happened.

Ron’s business stayed afloat not because of Ron’s business acumen, but because of dedicated employees led by Ron’s wife who kept the business going and managed its transition from a business forms printer into a computer dealer in the early 1990s as the business world was rapidly transitioning to desktop computers. The core of loyal employees kept the business a going concern, so some amount of bluster and possible incompetence at the top might not be fatal for a business, but it does make a difference. Ron also reminds me that too much in the trappings of success and importance—spend four minutes to get that guy to dial a telephone—impede progress and efficiency. One really has to gauge whether additional staff and whatnot actually improve efficiency or whether they merely prove Parkinson’s Law.

(Part IV to come)

(Part I.)

Mike, the Telemarketing Manager
Part-time telemarketing fundraising is a tough gig. Wearing a headset, one sits at a table with a computer monitor and keyboard. A mainframe or server somewhere dials a stream of telephone numbers, and when someone answers, the monitor displays information about the person along with the approved script for the fundraising customer. One then tries to sound as fresh and chipper to this potential mark, I mean “donor,” as one did when one started the shift ten and a half hours earlier. Success ebbs and recedes—one gets a couple of the voices on the line to agree to joining the society or supporting the law-enforcement fraternal organization, and one gets confidence that translates into further sign-ups, or one gets a string of hang-ups and angry voices whose ire deflates one’s confidence, which breeds further lack of success. After darkness falls, the calls stop, and the person with the lowest total for the day empties the trash cans. It’s low-rent Glengarry Glen Ross with less swearing and less individual opportunity.

Mike, the manager of the roomful of twenty or so twenty somethings happy to be working outside of retail, was missing his front teeth. A homemade tattoo of his prison number colored the inside of his wrist. The tattoo, he told us, was so that when he got angry in his car, if he reached for the illegal gun under his dashboard, he would see the tattoo and think twice. He boasted that the only two things he had not been to jail for were rape and murder.

Colorful nature aside, Mike was not actually a bad boss. He was a boss in a bad workplace, a workplace that suffered enough turnover that the newspaper carried a running ad for telemarketing fundraisers, and the shop had new interviews—and empty chairs—daily.

Mike, though, was good at the job. His deep, resonant telephone voice bred success as a telemarketing fundraiser. Eventually, he worked his way up from the interchangeable tables through the PCs (previous contributors list, a special phone list of people who had given to the campaign in other years and were expected to be easier marks, I mean “donors,” in successive years) to managing the stable.

Mike demonstrated that one’s past is not necessarily relevant to one’s ability to perform in a position. The right confluence of talents and drive can lead to success regardless of other less savory incidents or experiences. When looking for someone to fill a position, or whether judging someone’s abilities at one’s current job, one must focus on the present and not the past.

(Part III)