Blog

As some of you might know, I'm a big proponent of risk based testing.  (For example, see the podcasts and videos on the RBCS Digital Library here.)  In fact, a major RBCS client--I can't mention their name but the odds are good that you own one or more of their products--just told us that an entire division of their enormous company is adopting risk based testing, based on their understanding of the technique from our Advanced Test Manager course.

When test professionals first learn about risk based testing, one important question that often comes up is, "How do I convince skeptical testing stakeholders (outside of the test team) that risk based testing of our software is smart?"  You can give them a whole lecture in response to this question, but long answers tend to produce a severe case of MEGO ("my eyes glazed over") in non-test people. 

In business, people talk about the "elevator pitch."  If you haven't heard this phrase, here's what it means: You have a powerful executive in an elevator with you.  She's getting off in about 10 floors.  You have just a few seconds to convey to this powerful person some important piece of information.  Start talking.

So, if you find yourself in an elevator, a conference room, or an office with an influential testing stakeholder, and you want to convince them to support your efforts to implement risk based testing, here's the elevator pitch:

• Risk based testing runs tests in risk order, which gives the highest likelihood of discovering the most important defects early (“find the scary stuff first”).
• Risk based testing allocates test effort based on risk, which is the most efficient way to minimize the residual quality risk upon release (“pick the right tests out of the infinite cloud of possible tests”).
• Risk based testing measures test results based on risk, which allows the organization to know the residual level of quality risk during test execution, and to make smart release decisions (“release when risk of delay balances risk of dissatisfaction”)
• Risk based testing allows, if the schedule requires, the dropping tests in reverse risk order, which reduces the test execution period with the least possible increase in quality risk (“give up tests you worry about the least”).

All of these benefits allow the test team to operate more efficiently and in a targeted fashion, especially in time-constrained and/or resource-constrained situations.

Are you a test manager estimating a new software or systems test project?  Here's a list of ten factors that will make the testing cost more, take longer, or both. 

1. Complexity (process, project, technology, organization, test environment, etc.).
2. Lots of test, quality, or project stakeholders.
3. Many subteams, especially geographically separated,
4. Need to ramp-up, train, and orient growing team.
5. Need to assimilate or develop new testing tools, techniques, technologies.
6. Custom hardware.
7. Need to develop new test systems, especially automated testware.
8. Need to develop highly detailed, unambiguous test cases (a.k.a., scripts and procedures).
9. Tricky timing of component arrival, especially for integration testing and test development
10. Fragile test data (e.g., time-sensitive)

Don't forget about these factors when you do your estimate.  Just one of these factors can cause some real pain and suffering when the consequences arise.

Hi all--

After years of hesitation, RBCS is finally initiating a blog on software testing.  We've hesitated in large part because I've always joked--and only half in jest--that the word "blog" seems to rhyme with "blab" given most blog content. 

However, as the cliche goes, better to light a candle than to curse the darkness.  In this blog, I'm going to focus on sharing immediately useful ideas about software testing, rather than merely opinions, bloviations, or jeremiads.  I'm also going to talk about what you tell me you want to hear about, so feel free to send me requests.

In the next couple days, I'll start with a series of blog postings on some key management concepts related to software testing.  I'll be happy to see comments on those, and we can use the blog postings as the start of a discussion of each of these concepts.

Regards,
Rex Black
President, RBCS, Inc.