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.

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.

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:

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.

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.

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.)

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.

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.

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.

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.