My latest column...

Drive-by training. Never heard of it? It is exactly what it sounds like. You drive to a training facility (or an instructor drives to you), for a day or three the instructor delivers the pre-packaged training class, then everyone drives back home. It's not the best training model ever invented. There is generally no student assessment, and the only instructor/course provider accountability is reputation. Even so, many good ideas can be shared and lots of students come away feeling that it was well worth "the drive."

As it turns out, I've been delivering a lot of drive-by training to software testers this fall. That in itself isn't particularly noteworthy -- end-of-the-budget year is a popular time for drive-by training -- but something that is noteworthy is that I have noticed a rise in some disturbing behaviors among the individuals and organizations that select and attend drive-by training.

At first, I thought it was just me. But after an informal poll (and some lively discussions) with my employees and trainer friends in the testing realm, I became increasingly convinced that the behaviors I'm noticing are not exclusive to me and that I'm not the only one who thinks they are on the rise.

Read the rest of the column.

--

Scott Barber

President & Chief Technologist, PerfTestPlus, Inc.

Executive Director, Association for Software Testing

Co-Author, Performance Testing Guidance for Web Applications

 

"If you can see it in your mind...

     you will find it in your life."

Software testing is improved by good bug reporting

I recently completed (successfully, I might add) the second of the Association for Software Testing's all online, free to members Black Box Software Testing course. Each of these courses is four weeks in length. I've been involved with this program since years before it became a program, and I am an instructor for the first course in the series, called Foundations. For this course, called Bug Advocacy, I was a student.

The 3rd Annual Conference of the Association of Software Testing (CAST) 2008

Toronto, Ontario, Canada, July 14-16, 2008

Beyond the Boundaries: Interdisciplinary Approaches to Software Testing

Keynote Presentations by Gerald M. Weinberg,

Cem Kaner, Robert Sabourin, and Brian Fisher

Tutorials by Gerald M. Weinberg, Scott Barber, Hung Nguyen, and Julian Harty

The Association for Software Testing is pleased to announce its third annual conference (CAST 2008), to be held July 14-16. The meeting will be held in Toronto, Canada, a city which features enormous diversity in culture, businesses, educational institutions, and the arts. Toronto is the perfect location for a conference on this year’s theme: "Beyond the Boundaries: Interdisciplinary Approaches to Software Testing".

You can view the most recent brochure here, and you can see the conference program here.

December Issue of the Association for Software Testing Newsletter Now Available

Some time back, I blogged about a book I’d been significantly contributing to being available as a free .pdf download. (see the entry here)

Well, the book quietly appeared in “dead tree format” (as Stuart Moncrieff put it in his blog post about the book) a couple of weeks ago and I’ve been getting light heartedly scolded by some of my friends and readers for not making a big announcement, so here’s my “big announcement.”

Performance Testing Guidance for Web Applications

by: J.D. Meier, Scott Barber, Carlos Farre, Prashant Bansode, and Dennis Rea is now available on Amazon.

This is the second installment of a currently unknown number of posts about heuristics and mnemonics I find valuable when teaching and conducting performance testing.

 

Other posts about performance testing heuristics and mnemonics are:

 

• Installment 1 - Performance Testing Core Principles: CCD IS EARI
• Installment 3 - Model Workloads for Performance Testing: FIBLOTS

 

I have struggled for over 7 years now with first figuring out and then trying to explain all the different "types" of performance tests. You know the ones:

 

• Performance Test
• Load Test
• Stress Test
• Spike Test
• Endurance Test
• Reliability Test
• Component Test
• Configuration Test
• {insert your favorite word} Test

 

Well, I finally have an alternative.

 

IVECTRAS

This is the first installment of a currently unknown number of posts about heuristics and mnemonics I find valuable when teaching and conducting performance testing.

 

Other posts about performance testing heuristics and mnemonics are:

 

• Installment 2 - Classify Performance Tests: IVECTRAS
• Installment 3 - Model Workloads for Performance Testing: FIBLOTS

 

There is not a "one-size-fits-most" approach to performance testing, but I have become rather convinced that there are nine principles that are (almost always) applied (or at least actively considered) in successful performance testing projects. I remember those principles by remembering:

 

CCD IS EARI