Now, you can sit down with the sales and marketing people and ask them what they tell customers (which is a good idea), but why don’t you take it a step further and actually be there for a product demo? You can have a sales person pitch to you directly at your office, pretending you’re a customer. Or, you can tag along on a sales call as a “technical rep” who can answer questions beyond the scope of the sales team.

You’re likely to hear a few things in the demo - both from the sales rep as well as from the customer - that will help you better understand what your product is really expected to do.

Leave your comments below … and until next time, keep adding (measurable) value, wherever you are.

- Dave Navarro, CQO

• Ten Requirement Gathering Techniques
• Undreamt Requirements
• 6 Tips To Double Your Requirements Interview Effectiveness

Keep it cranking,

Dave Navarro, CQO

What do you do when you’re asked to gather requirements and you have no guidance? Since it happens a lot (more often in small companies than large ones), you gotta do some legwork. Let’s talk about how it’s going to have to happen.

Ultimately, you’re going to have to talk with a number of people (management, marketing, engineering, etc.), and you’re going to have to get them to sign off on those requirements, saying “Yeah, this is what we want.” Now, you can walk up to all these stakeholders and say “Hey, spill your guts!”, but that’s probably not going to fly. They’re busy. No, they’re overloaded. And they want you to figure it out, not to ask them to come to a full stop and serve you.

Not fun. But there’s a way out of it, as long as you remember the CQO’s #1 Rule Of Information Gathering: It’s easier to get someone to edit a document than to write it. In other words, if you come to someone saying “Gimme all the info I need!”, you’re going to get a big fat “I-don’t-have-time.”

So Don’t Do That. Do This Instead
On the other hand, what if you arrive with a document full of bullet points and concise paragraphs, and you say “Hey, Chester, I’ve been hammering at this document and chunking in all the info I think I need, but I know I’m missing a few things. Can you please take a look at this with me and help me fill in the blanks?”

Ding! Bingo. Now instead of showing up like a hapless newbie you’re coming across as Mr./Mrs. I-did-my-homework and the other person is going to be MUCH more likely to help you, because you just made it easy on them. They will look at your info and respond with a whole big mess of hey-you-forgot-to-include-this and wow-I-just-thought-of-that gems that will help you round out your document. They will respect you more and be more willing to work with you in the future because they know you don’t want to waste their time.

So How Do You Get That Document?
Let’s talk about how you do your homework and get that requirements document started anyway. Below are a few good tips but are by no means the be-all and end-all of the requirements-gettin’ universe. But it’s a start, and a start is what you’re after.

• Dig Into The User Manual. If you’re lucky enough to have one of these, it can be a veritable goldmine of often outdated information. But it’s a start point. Open up that PDF/HTML and fire up a brand new document. Go through the user manual and pull out everything that talks about what the program should do.Don’t get into the gory detail of how you perform the functions, just get the purpose. It’s enough to know that the program needs to import 3 specific types of data files; you don’t care whether it’s by file/open or edit/import at this time. You should end up with a nice solid lists of “whats” (and not a single “how”), broken down by functional area.

• Dig Into The Marketing Material. Go to the product website. Scour the product packaging. Look at the press releases. Find anything anyone has ever sent that promises that your Widgetizer 2.0 really does whiten your widgets - and any other promises made. These get to be bullet points as well.
• Dig Into the Product Itself. Fire up the product and use it. Try to do the things that your previous exercises told you it should do. See if there are any features in there that weren’t covered anywhere else. Is there anything inside the program that suggests conformance to some outside requirements? You may not get a whole lot of additional functional bullet points here, but by the time you’re done you’ll have enough product knowledge to enter into conversations about requirements more intelligently than before.

Now, Start To Put It All Together
By now, you’ve got a boatload of bullet points that spell out your product’s functionality. Now,

• Take a look at all of them and try and figure out what kind of high-level functional or business requirements could have driven these functions to be created.
• Group the functions under the requirements where they make sense
• If you’ve got leftover “is-this-really-necessary?” functions, put them in their own group.

When you’re done with this part, you should have a pretty good looking list of requirements. Granted, they may all be wrong (since you guessed at them), but it’s a start - and that’s what you’re after. Your SMEs (Subject Matter Experts) can correct you later.

Take It To The Streets
Now it’s time to start meeting all those wonderful SMEs.

• I’d suggest meeting with marketing people first, the rationale being that regardless of what management and engineering are working on, these people are PROMISING CUSTOMERS THINGS. And since it’s not unheard of for marketing to promise the big, comfy chair to customers, you need to know about it so that you can catch any disconnect between their priorities and those of development. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.
• I’d recommend talking to the project manager next to find out what expectations the customer has. If you can talk to a customer, that’s a bonus, but often you will need to go through the PM. They should know what they’ve committed to, and should be able to point you towards some sort of signed contract (Statement of Work, Service Level Agreement, etc.), that can give you an understanding of what your product is on the hook to deliver.They may also balk at what marketing is promising, and it’s a bonus for you to catch for them. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.
• Then you can meet with the development folks and find out where they get their marching orders from. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.

At this point you’ll have met with the major stakeholders and you’ll have an idea about the expectations of each. And because you did your homework, you were probably able to ask a lot of questions to uncover additional requirements that had never been put to paper before.

Your requirement-gathering job ain’t over, but it’s well begun. I’ll write more on that later - chew on this for now and don’t be shy with the comments.

- Dave Navarro, CQO

If you’ve just been hired to start/run a QA department, there are a billion things to do. But there are a few things you should put at the top of your list (and perhaps even cover these before you accept the position). Meet with management/boss/powers-that-be and ask these three questions:

#1 - “What is your expectation of what this position will accomplish at this company?”
Translation: What are you going to grade me on? It’s important to find out if the head honchos/honchettes expect you to roll out a total quality initiative (insert flavor-of-the-month model) or they just wanted someone to “be in charge of testing.” Don’t let it stay vague (”build a super QA team!”) - get specifics as best you can.

Once you find out what they expect (and don’t expect) of you - get it in writing. The easiest way to do this is to take mad notes and summarize them in an easy to read email. Send it to the right people with a “please reply and confirm this is what you are paying me for” note, and archive that email. While you’re at it, print it and tack it to your door.

This way you can manage expectations moving forward, when the scope of your job responsibilities changes (or someone tells you “nuh-uh, you’re not allowed to do that”). I can tell you from experience how important this is. Just like the products you test have “feature creep”, so will your job responsibilities. If you don’t get things in writing, the situation can get sticky later.

#2 - “What do you want me to accomplish over the next 12 months?”
Translation: What’s on this year’s list? Ask this to get a feel for what they expect you to actually get done in Year One of your reign. Again, get this in writing, get it confirmed via email.

#3 - “What resources/authority will you give me?”
Translation: Will you give me what I need to do what you just asked me to do? This is the toughie. All too often a new QA Manager is told to “make things right” without being given the power to do so. Find out what kind of resources they will give you (budget, people, etc.) and what kind of authority they will allow you to have.

A good way to test the waters here is to give scenarios. If you are trying to put a process in place to streamline/prevent issues in development, and you meet resistance, what happens next? It stinks to be tasked to do a job and get no management backup (and that happens a lot).

Caveat Testor: Testers Beware
Keep in mind while you ask these questions that you may not get any hard and fast answers at once. Budget numbers may not be available and highly dependendent on market conditions. Management may not have considered actually figuring out what they want from you. But this is your chance to start things rolling so you can figure it out and so you can start being hella productive for your company. So get to it!

- Dave Navarro, CQO

A test plan ain’t a test plan until you can prove it does the job. And that’s where a traceability matrix comes into play. It’s the magical bridge that links what everybody says the product has to have/do/be and what you, my little QA ninja, actually test for.

A good requirements traceability matrix (RTM, from now on) not only helps everyone sleep better at night, knowing that a QA team with superpowers is saving the day, but it can also save your important little butt in the process. Here’s how to make that happen.

Setting That RTM Bad Boy Up
Start with a heaping helping of requirements. Since you’re a super-ninja QA CQO, you already have a master document listing all the requirements/design specifications/industry standards that the powers that be in SuperGloboCorp expect you to be testing against (or a collection of documents that reference each other). These are what you’re using to build up your Ultimate Test Plan.

As you build up that test plan with its powerful army of test cases, you want to make sure that those patriotic little tests are loyal to the cause and completely test against those requirements. Once you do that, building the basic RTM is a cinch. You simply note which requirements are supported by which test cases/suites. Like this:

• Requirement THX-1138 - > Test Cases CYA-9901 thru 9999
• Design Spec. NCC-1701 -> Test Suite RTFM-01
• Conformance Spec. #9 -> Test Case LOL-1337

Manage It All In One Place
What’s important here is that the RTM is its own entity - that you track the linkage between requirement and test in one document, and not as annotations in the requirements docs and the design specs. That is the path of pain, because you’ll never know where/when something gets updated.As long as the specs themselves have identifiers for the important stuff, all you have to do is link those IDs to your tests in the RTM.

Crack The Whip, Or You Are Toast
Don’t forget the most important part of the RTM … enforcing updates like a harsh samurai warrior. Nothing will undo all your hard QA work like having test plans and specifications that get updated separately and, like so many once-happy couples, drift apart. Be the bad guy (or girl) and lay down the law like a cranky mob boss, saying, “you touch-a my spec, you update-a your QA team.”

Bottom line is - you don’t do this, then suddenly you get the blame because the test plan you wrote to test apples doesn’t count anymore because someone in marketing added oranges to the spec, without telling you.

The Short of It
So to sleep like a double-burped, milk-fed baby at night, you need to make sure that:

• You have and understand all the requirements you can get your grubby little hands on
• You have created cry-your-eyes-out beautiful tests that put those requirements to the test
• You can prove it with your solid gold, awesome-plated linktastic RTM.

So get to it, and tell ‘em Dave sent you.

Just like the Chief Operating Officer keeps the company chugging along, just like the CEO (presumably) sets the company’s course, you directly impact, create and manage quality every day - whether you’re a senior manager or an entry-level tester. But the challenge is, as I mentioned earlier, you can’t assure quality. You don’t have the power of a CEO.

But then again, you do. Tom Peters talks about treating yourself - regardless of your job description or rank - as your own “PSF” or Professional Services Firm (PDF here). That makes total sense because you, essentially, are the boss of you. You dictate the quality of your work. You’re the CEO of the work you produce, the footprint you leave on your company, and the influence you have over others (as it relates to evangelizing quality).

So this means you can’t play the victim. I’m not saying you are, but it’s a typical feeling in the QA world to feel hamstrung by short-sighted executives, limited resources, and unreasonable schedules (especially when everyone’s looking to you to “assure” quality). In my decade-plus run in the QA trenches this is pretty much the norm when you look at it from the typical perspective of QA being at the bottom of the food chain. It can wear people down and make them feel powerless to work under the restrictions that often result from resource constraints and internal politics.

But what if you treated things from a different perspective - instead of seeing yourself as an employee (tester), or a manager (test lead/QA manager), what if you viewed yourself as the Chief Quality Officer of your own PSF - and handled your workload accordingly?

As the boss of your own PSF, “assuring quality” is equivalent to assuring your continued employment with a client - you’ve got to give them value greater than what you’re extracting from their payroll department. So as the head honcho of your own one-man/woman PSF, you have three possible avenues to take to add quality to the development process for your customer (your employer).

The “I”s Have It - 3 Roles of the CQO
As a CQO, you add value to your customers when you do one of the following:

• Inspect. In other words, this is testing. Either you do it yourself, or you assign it to testers under your care and feeding. This also includes making the tests better as often as you can.

• Infuse. This means adding value by improving the process. This happens at a higher level than testing and requires either some position of power (e.g., being a manager) or the savvy ability to …

• Influence. This is the big one. This is where you work to educate people outside the QA department to adopt improvements to the development cycle that make sense. But because people are people, you often have to do it in a way that makes them think they came up with idea. As someone once said, “Diplomacy is the art of letting somebody else have your way.”

I’ve seen many people locked into the first stage of QA - the role of testing (and nothing else). There’s nothing necessarily wrong with that, because every Quality Services department needs people to, well, test the hell out of software. But to truly take on the role of the CQO, you’ve got to do more.

Most QA managers I’ve seen understand the concept of Infusing. It’s part of their role to make the process better. Their skill set allows them to infuse the process with new energy, new strategies that make the test cycle simply run better. Sadly, though, many managers stop at just improving the test process.

Getting Your Company Under The Influence
That’s why becoming an influencer is so important. A savvy CQO needs to learn the needs of the departments around him/her and see where they can help them work together. In most companies different departments develop adversarial relationships because each has its own agenda, its own pressures, its own constraints. On top of that, they have their own history of strife among members of each department. How many decisions have you seen made (or shot down) for political reasons?

A good CQO will subtly work to reconnect departments with each other again and dissolve the adversarial relationship. And that leads to a better development effort, and ultimately a better product for you to test. And how to do that is fodder for a whole slew of other articles. For now just chew on the three “I”s and ask yourself how you would approach “QA” different if you saw yourself as the CQO of your own PSF. OK? We’ll pick up on this again soon.

Till then, focus on adding massive value, wherever you are.

- Dave Navarro

Now, don’t get me wrong - I’m sure you’re exceptionally good at what you do, and I don’t doubt your skills when it comes to testing software (or managing the test process, if that’s what you do). I would never dream of suggesting that your attempts at assuring quality will fail because you’re not good enough.

The real problem I’m talking about is that “assuring” quality is an impossible task. “Assuring” means “making sure of.” It means guaranteeing. But in reality, you can’t. Don’t believe me? Well, let me ask you this …

On any given project, can you:

• Guarantee that upper management gives the project proper funding?
• Guarantee that project management accurately estimates project task times?
• Guarantee that marketing doesn’t bloat the scope of work by promising new features?
• Guarantee that the customer provides clear, specific business requirements?
• Guarantee your programmers/designers don’t get pulled sidetracked by other projects?
• Guarantee that the test team has all the resources it needs (hardware, software, people)?
• Guarantee that the test team receives stable builds on time?
• Guarantee that code freeze is enforced when it needs to be?
• Guarantee that absolutely nobody quits, gets sick, or changes roles?
• Guarantee that stupid decisions - or impasses - aren’t caused by office politics?
• Guarantee that everyone agrees in their definition of “quality” itself?

The cold, hard truth is that a sizable chunk of what it takes to make any software project a success is totally out of control of anyone in the “Quality Assurance” group. Unless upper management grants you special, CEO-level authority, you can’t enforce the job roles of other departments. And so the concept of assuring quality is a goal that is doomed to fail even before the project begins.

But don’t lose heart. Sure, your very job title itself creates a paradox that dooms you to an unrealistic expectation of what you can deliver. But you’ll be okay? Why? Because of Rule #1 of the Chief Quality Officer:

CQO Rule #1:
You can’t assure quality … but you can sure as hell influence it.

Over the course of the next few articles I’ll be explaining exactly what it is I mean by that by discussing the three roles of the Chief Quality Officer (and why no matter what your QA position, you should consider yourself one of these CQOs). As you read the articles, you’ll get a better understanding of how you can take the elusive goal of shipping top quality products and make it fun again. Or at least more tolerable.

Till then, focus on adding massive value, wherever you are.

- Dave Navarro