QA Hates You

As I mentioned on Twitter, I’m a member of the Rutger Hauer school of software testing. The Rutger Hauer school of software testing (RHSoST) focuses less on processes and procedures and more on how to wreak havoc using a varied set of tools upon a system or application regardless of its plot, I mean, its business rules.

But here are some of the primary texts of the school:

• Introduction:
  Beyond Justice. The basic primer in software testing describes how to create user scenarios to test systems, how to understand and work within and without established processes and procedures, and how to turn erstwhile enemies into allies.
   
• Exploratory Testing, Basic:
  Blind Fury. Even when you lack basic knowledge about a system or insight into the business rules or considerations, you can still cause damage find defects with your sword basic set of test cases that apply to any application.
   
• Exploratory Testing, Advanced:
  Blade Runner. As your knowledge of applications grows, you can find more complexity and higher levels of business rules to test until the final deadline.
   
• Load Testing:
  Escape from Sobibor. Learn how careful planning and execution of load tests can find the weaknesses in and actually crash the most rigid set of rules and constraints in an application.
   
• Career Planning: Working in a Large Corporation:
  Deadlock. Learn how to find a payoff even when constrained by an explosive device bolted to your neck, figuratively speaking (and literally).
   
• Career Planning: Working as a Test Consultant:
  Hobo with a Shotgun. This text deals with the itinerant tester and the challenges he/she faces with each new engagement, including how one fits in–or does not fit in–with the existing culture and how one can test effectively and efficiently on the run.
   

Rutger Hauer on the end of a project and the knowledge lost when a test consultant or team member moves on:

These are some of my favorite texts in the RHSoST. Undoubtedly, some of my fellow school members have their own. Don’t be afraid to share in the comments.

Five Management Lessons From James T. Kirk

In your QA circles, you’ve got your Picard leaders, who confront a problem by calling a meeting, and you’ve got your Kirk leaders, who confront a problem by besting it in combat that somehow leaves the Kirk leader’s uniform torn.

This book is the autobiography of Richard Marcinko, the man who organized SEAL Team Six. It recounts his history from his days as a lowly enlisted man in the United States Navy and his rise through the ranks as he becomes an officer, a leader, and commander.

So what? you might ask. I’ve read a bunch of books about testing, I’ve read a couple of books about managing, but I’ve never really read a book that captures a career path that mimics the one in software testing.

You start out bucking the system, complaining about the Man, and fighting hard to get quality. Eventually, if you get promoted to team lead and beyond, you have to subvert that fighting instinct to recognize the new environment and to work within its limitations to further your goals and missions.

Marcinko goes from a platoon leader who goes around the leadership he doesn’t like to being a ramrod straight commander of a SEAL team. He was to play the political game a bit and know how things are done in the Navy. When he gets an opportunity, he gets to form his own team, SEAL Team Six, in his own vision–which is closer to snake-eating SEAL grunt than ship-driver (that is, a commander that comes from a different milieu). Marcinko ends up training with his men even when he’s a high-level executive.

Definitely some interesting lessons in this book, but as it is his autobiography and it’s written from the point-of-view of a long time military man, the language is pretty vulgar and the outlook a bit crude. However, Marcinko has written two books that have his picture on the cover in suits and probably don’t have quite as many f-bombs: Leadership Secrets of the Rogue Warrior and The Rogue Warrior’s Strategy for Success.

Or, if you want some more sedate reading, you could pick a book off of James Bach’s recent list, but there’s probably not as much shooting in them.

Books mentioned in this review:

Over at Forbes.com, Susannah Breslin posts This Is Why Your Employees Hate You.

Basically, here three order list points boil down to 1)You’re hired into a new company and don’t get the lay of the land before you start making a mess, 2) You’re unlikeable, and 3) You are not a leader.

As you might know, I think #1 is very important, and I’ve harped on it on occasion here. When you’re hired in as a manager, you have (or have convinced someone that you have) skill and ideas applicable to leading people in doing whatever you’re managing. You might have led a team in some other industry doing something similar, or you might even have been working within the same industry for a competitor or some related organization. Be that as it may, you don’t know how things are done in your new organization, and until you do, you should probably avoid upsetting the apple cart with your new ideas and processes which are really only old ideas and processes that might have worked at your last employer. At your new posting, some things are done that way because they’ve always been done that way, but some things are done that way because they work for your new employer and new employees. Until you can tell them apart, you don’t know where your new ideas are improvements or impediments.

As to number 2, remember, lads and lasses, there’s a fine line between being a jerk and being confident and right. Regardless of which side of that line you’re on, people who don’t like you or what you’re saying will think and say you’re a jerk. So be professional, but be confident and tell people the hard truths. Clearly. Dare I say, bluntly? I DARE.

And for number 3, we’ve seen QA managers like this, haven’t we? Just glad to be sitting at the big table and unafraid to rock the boat. You’re not going to add anything dodging that responsibility, and when it comes time to trim budget, if nobody remembers you saying anything about anything, especially not saying anything that stuck up for anything, they’re going to wonder why you’re on the payroll in the first place.

So do what Ms. Breslin says. Or the opposite of what she says. You’ll be a better manager for it.

But know these are not the reasons QA hates you. QA hates you because QA hates everybody.

If you’re looking to improve your management chops, emphasis on the chops, you can take some lessons from one of the legendary leaders of history: Attila the Hun.

I recently completed Attila: King of the Huns: The Man and the Myth, and that book offers these lessons from the reign of the warrior-king:

• Build a team of diverse talents.

  As a ruler, Attila was an originator, in some respects a revolutionary. He clearly perceived that if the Huns were to become a great power, as he intended them to be, they must learn from other more advanced peoples. His own intimate circle of advisers, in consequence, consisted largely of foreigners.

  If you hire and promote only people who’ve worked in your business line or only in your particular methodology, you’re going to be bound to only insights and knowledge of those. If you hire from outside them, though, the foreigners might teach you something about what you’re doing that someone of your tribe would not innovate.
   

• Let the farmers farm.
  

  When the Huns occupied a new territory large numbers of people fled before them, but the numbers of those who remained were larger still. Many of those who stayed were agriculturalists, and the Huns not only allowed them to continue to till the land, but encouraged them to do so.

  When you take on a new assignment or position, some turnover might occur as people leave to follow their mentors or because they feel that they, not you, should be the barbarian king of the tribe. Accept that. Those who stay have a lot of experience in the field. Don’t immediately overturn everything they do to conform to your new methods which might be informed and learned, but might not apply. Let those workers show you how they do things, and you can learn from them and, if appropriate, gradually increase the taxes introduce your improvements. Otherwise, more will fly, and you’ll lost a lot of knowledge with them.
   

• Avoid the trappings of the title.
  

  ‘While sumptuous food, served on silver plates,’ he [Priscus] wrote, ‘had been prepared for the other barbarians and for us, for Attila there was nothing but meat on a wooden platter. He showed himself temperate in all other ways, too, for gold and silver goblets were offered to the men at the feast, but his mug was of wood.’

  In dress and general appearance also Attila was noticeably different from the others present. ‘His dress was plain, having care for nothing other than to be clean, nor was the sword by his side, nor the clasps of his barbarian boots, nor the bridle of his horse, like those of the Scythians, adorned with gold or gems or anything of high price.’

  If you’re too busy showing everyone you’re the leader, you’re not leading, you’re pillaging. Back when I was an actual Director of Quality and not merely a Director Emeritus, I had my cards say simply, “Quality Assurance.” Because my title wasn’t important, what I did was important. Plus, you get the respect of the blue collar grunts if you do like they do and live like they do. Or at least you get my respect.
   

• Break something early.
  

  The wholesale destruction of a major town early in a campaign was a strategy adopted by Attila in both France and Germany. Metz recovered to become a city of importance. Aquileia did not. But the news of what happened in both places spread, as it was no doubt intended to, and the rulers of other cities duly took note.

  This is not to say you break the process or the methodology early, as I have advised against that above. However, every posting comes with some sort of deliverable, and the sooner after you take your position that you can create absolute havoc with it, the more the developers and other team members will listen to you when you explain how to avoid that in the future. Or maybe they’ll just fear you’ll do it to them, so they’ll be more careful. Either way, making that splash early can really ramp up your influence.
   

• You don’t need a long contract or employment to make a lasting impression.
   
  

  Attila was sole King of the Huns for a mere eight years. In that short time the impact he made on his contemporaries was extraordinary. Much of this was due to his conquests. Eight years was a short period in which to hold both the Eastern and Western Empires to ransom with the threat of capturing and destroying both Constantinople and Rome, in addition to overrunning much of Germany and France.

  If you’re audacious and capable enough, you can make a lasting impression on an organization, its product, and its quality that will last long after you’re sacked for drinking kumis on the job on your third day. At the very least, they’ll remember the fermented mare’s milk.

A short video explains how Southwest Airlines tries to determine if candidates for its open positions have a sense of humor:

Having a good drawing-and-quartering sense of humor (gallows humor is too humane for our line of work) will help one survive the software development industry. How important is it to you, and how do you go about finding it in candidates?

(Link seen here.)

Last night, this video about what motivates people made the rounds on Twitter:

It’s an interesting summation of Dan Pink’s book Drive: The Surprising Truth About What Motivates Us.

At first blush, you might think it does not agree much with my list of priorities with a job. My top item:

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.

The emphasis of the talk is on other things to empower and motivate people (autonomy, mastery, and purpose). But lower in hierarchy of needs remains money. From Dan Pink’s talk:

Fact: Money is a motivator at work, but in a slightly strange way. If you don’t pay people enough, they won’t be motivated. What’s curious about that, there’s another paradox there which is that the best use of money as a motivator is to pay people enough to take the issue of money off the table. Pay people enough so that they’re not thinking about money, and they’re thinking about the work.

Too many organizations are going to take away from that talk that money isn’t important and the other things will motivate employees to work for the company at a discount. Kind of like HR people trying to sell you that the staff bowling parties, free sodas, and great atmosphere of an organization is worth $25,000 in annual salary. It’s not the way to go, because other companies are going to catch on and start moving in this direction–so many have already–that underpaid employees (and employees who wonder if they’re underpaid) are going to wonder whether the grass would be just as green and the salary more green at that company up the road.

Testy Redhead said on Twitter:

Never stop testing in production. You have to test the cloud, not just your code. Ken Johnston #bsadt

You know, that’s my motto, too. At my last full-time posting, I set my browser home pages to client sites so that I had to look at the sites by default every time I opened my browser. I ran through the sites every promotion with a basic set of regression tests. And I hounded the developers to make minor bug fixes, the stuff marked low or typo in the defect tracker, so that a low priority did not automatically mean it was resolved (wink, wink) as won’t fix without, you know, marking it so and leading to the firestorm of righteous QA indignation.

However.

We could do that because we had a maintenance budget for these clients/sites/applications. Granted, we blew through the maintenance retainer because those retainers were set based on the assumption that the maintenance contract was pure profit after having a network admin make sure the machines were patched once every couple of months.

The point is, when your organization writes up its maintenance contracts, you should push to include as much QA and bug fixing time as you can to make the testing in production and the bug fixing palatable to the organization.

Otherwise, if the client writes a check and you’re done at product launch, you can test all you want and find a bunch of problems, but the rest of your organization will toussle your hair, chuck you on the chin, and ignore the whole business.

This article on career rotation reminds me of a point.

In Big, the hit movie from the late 1980s, star Tom Hanks rises from a clerk in data processing—that’s what technology was called back then—to become vice president of product development for a toy company. That quantum leap in status and pay took him all of a week to pull off. Some would-be fast-trackers might call that the ideal job rotation.

Some companies have always encouraged ambitious employees to rotate out of their discipline—technology, finance, marketing, operations, etc.—and into a different department, often one in which they’d have to push themselves to succeed.

The rationale is simple: By seeing how other areas of the company operate—getting the proverbial big picture—an employee becomes more valuable, and the organization as a whole gains. Six to 18 months in a new assignment arms an employee with additional knowledge and layers of skills.

That career advice is more geared to people in big corporations who aren’t in tech jobs but managerial or other non-tech components (business analysts, project managers). Nobody is going to take a technical writer and try him out in QA, for example, or give him 18 months to taste development. However, rotation is important to keep your peeps, especially your QA bunnies, from burning out.

Let me explain. No, there is too much.

One of the shortest postings in my career came when I was put on a QA team on a long deathmarch of a multimillion (and I mean two) and multiyear (and I mean like four) project to develop a custom piece of software for a client. I joined the team some months in, when they had a mostly working Java desktop application (perish the thought! because the application surely perished). I started testing an area of it and tearing it up. The client didn’t like this, didn’t like that, wanted more of that, and altered the specs so that my employer had to change it. I spent nine months essentially testing the same features of the same application and often logging the same issues when I left.

Don’t do that to your testers. Let them see different things, different projects. If you swap them around, they get more experience with the gestalt of the application/business/et cetera as well as learn new techniques, technologies, and music fitting for QA when they work with different people.

This article in the Wall Street Journal is spot on: Where Process-Improvement Projects Go Wrong:

What do weight-loss plans and process-improvement programs such as Six Sigma and “lean manufacturing” have in common?

They typically start off well, generating excitement and great progress, but all too often fail to have a lasting impact as participants gradually lose motivation and fall back into old habits.

I’ve sat through enough process meetings to know it’s true. We’d sit in a conference room, chart out a nice flowchart eventually of an ideal situation, and then when the meeting broke up and actual projects started, everyone would do what they always did in the first place. Which is ignore the process.

When you’re trying to improve the process in an organization, you have to take into account the specific organization and the major players within the organization. An outside consultant beaming down solutions from planet Six Sigma is not going to know enough about the industry and about the people within the company. They will offer procrustean solutions that the teams will easily ignore or forget.

The best process improvement can come from within if you have a long enough relationship with other people in the organization to know their strengths and their weaknesses. To improve the process, you need to account for the people who will try to make it work and to accommodate them. You’ll want to capture the best of the things they do and you’ll want to make sure the process handles all of their weaknesses and shortcuts, too, so when the fit hits the shan, the process handles that, too.

A process under glass, framed on the wall, isn’t the goal. Doing things the right way is.

A proposal would hold vendors liable for bugs:

SANS’ newly released Top 25 list of common programming flaws came with a little legal muscle, too, with representatives from SANs, Mitre, the U.S. Department of Homeland Security, the National Security Agency, and other organizations pushing for custom software developers to be held liable for insecure code they write.

Experts from more than 30 U.S. and international organizations, including OWASP, Microsoft, Apple, EMC, Oracle, McAfee, and Symantec, contributed to the CWE/SANS Top 25 list. And procurement experts from some of the organizations are recommending standard contract language for procurements that would ensure buyers aren’t held liable for software that contains security flaws. “Wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems,” says Alan Paller, director of research for the SANS Institute.

Paller says the contract language would be based in part on a draft in the works by the State of New York (PDF) that refers to the SANS Top 25 and would make the state’s custom-software vendors contractually bound to provide apps that are free of those bugs. Paller says although there is “no formal agreement on the language” among the group at this point, it’s focused on the section of New York’s proposed contract language that reads: “the Vendor shall, at a minimum, conduct a threat assessment and analysis of vulnerability information, including the current list of SANS 25 Most Dangerous Programming Errors; provide the Purchaser with a written report as soon as possible after a vulnerability, threat, or risk has been identified.”

Well, within the context of the job, QA management is always on the hook. Any bugs that get through reflect poorly on QA (as they do on the whole organization, but I always internalize it because I’m that way).

However, when I read something like this, I get a little skittish and recollect sitting in a sexual harassment seminar given to all department heads and learning that I, personally, was on the hook as a potential plaintiff if one of my minions made a hostile-in-the-sexual-way environment (hostile-in-the-QA-way environments are standard). I am sure I paled a bit learning someone could get my house. I mean, I had a Canadian on staff, and you know what that means (the man was born in Canada).

I’m probably a little worried for something that probably won’t come to pass. A little liability and being required to fix problems is good. That fear can help make some better software. How the torts shake out, though, that remains to be seen.

A thoughtful rant about how meetings affect managers differently than programmers, et al.:

 There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

That can hold true for QA, too.

Worse, that block of time might have looked good when the meeting was scheduled, but slipping development timelines now impose that meeting in the four hour block on a Thursday afternoon between being ready for test and the time the client expects to review the Web site in a test environment.  We’re not talking beta, here, bubs, they expect it to be feature complete and ready.  Instead, I’m supposed to sit in a four hour seminar on succession planning?  How about I talk about secession planning, wherein we in QA form our own nation-state, huh?  And we’re marching on the kitchen at 19:00.

Sorry, got off topic there.  But as a hands-on manager, I’ve struggled myself with meetings and the trappings of executivedom.  Hey, let’s have a meeting here and a meeting there; meanwhile, the actual production of the things we’re paid for go off the rails because all the decisionmakers are in the fishbowl conference room, not deciding and not contributing.

Sorry, got off topic again.  You know what else can blow something up?  Because we in QA don’t have the creative genius aura that allows us to metaphorically close our doors and get deep into work.  People are always popping by with questions or comments or whatnot.  Project managers want updates on things you haven’t gotten yet.  Designers have questions about how to spell the client’s product name.  And so on.  Meanwhile, you’re trying very careful to remain focused on a methodical assault on a Web site or application, and every time you’re called to avert your eyes from the screen, you need a couple of seconds to step out of the testing mode and into “social” interaction and then a couple seconds back to where you were and what you were doing.

I do my best testing alone, in a darkened room, with limited interruption.  That way, I can give the site or application my undivided attention and can see the small things that are wrong.  I hate being called out of that for meetings, communication, or other less productive activities when I’m under deadline.

Ah, this rambled.  Perhaps I’d better mount another assault on the coffeepot.

(Link seen on Outside the Beltway.)

Sorry to go back to this well twice in one day, but:

 The secret of managing is to keep the guys who hate you away from the guys who are undecided.

An old expression in IT goes something along the lines of eating your own dog food, which means you use the very software you write every day.  Also, it goes to show that people who use that expression tend to think of their own work as grinding horsemeat and mixing in the right amount of ash to meet the minimum standards.  However, Joel Spolsky explains in his Inc. column for December that, as a manager, you need to be able to do more than report cost/benefit analyses and calculate ROI in 3000 words or more:

Anyway, on my first day of work for the sergeant major, I didn’t know what to expect. I was sure it was going to be horrible, a suspicion that seemed to be confirmed when he took me to the officers’ bathroom and told me I would be responsible for keeping it clean. And then he said something I didn’t anticipate.

“Here’s how you clean a toilet,” he said.

And he got down on his knees in front of the porcelain bowl — in his pressed-starched-spotless dress uniform — and scrubbed it with his bare hands until it shined.

To a 19-year-old assigned to clean toilets, which is almost by definition the worst possible job in the world, the sight of this high-ranking, 38-year-old, manicured, pampered disciplinary officer cleaning a toilet was a shock. And it completely reset my attitude. If he can clean a toilet, I can clean a toilet, I thought. There’s nothing wrong with cleaning toilets. My loyalty and inspiration from that moment on were unflagging. Now that’s leadership.

To be a good QA manager, you need to be able to actually perform software quality assurance tasks as well as or better than your underlings.  You should probably be one of the team’s star players, able to teach and inspire and lead by example.

A lot of QA management without this capability is right now sucking wind through puckered lips, but it’s true.  Come crunch time, you have to be able to get in there and contribute to what your team is doing with a late deliverable and a looming deadline.  Walking around with a checklist on a clipboard and you’re only making things worse.

Although you could walk around, like Spolsky, with a power tool.  That sort of energizes/terrifies people.

Bonus defect!  The automatic pager on Inc.com content management system fails.  Go to page two of the article and click either prev or 1 links to go back to the first page, get a free 404 error.