Satisfice, Inc.
Rapid Tester Newsletter
January 2014
Quick Links
 
An easy way to keep in touch: join our list!

 

Rapid Testing Intensive Online Class

January 28-30 is SOLD OUT! (The next one will be in May) 
 
Click for More Details and to Register Now

"RTI is a unique learning experience. Especially after attending so many training programs with very little return on the time I invested. A workshop where you can immediately apply what you are learning is fabulous! I am extremely busy as a Testing Manager and I also test - so anything that takes me away from my job must be valuable. RTI is a valuable use of my time." --Bernice Niel Ruhland, New York 

   


Upcoming Travels


McLean, Virginia

Boxborough, MA

New York, NY

For more schedule details, and to find out when I'll be in your part of the world, see My Schedule 

    

 

 

Public Classes on
Rapid Software Testing
organized through Software Testing Club

April 7-9 Stockholm, Sweden
organized through AddQ Training 

Noteworthy Blogs


Welcome to the newsletter.

It's a new year for Satisfice (our 15th year of operation!), after another busy fall season for me in Europe, and a holiday season dominated by moving our home and headquarters to another part of Orcas Island.

New Class Offering: This year we are creating a special version of the Rapid Software Testing class aimed at teaching testing skills especially to programmers. It's special in that the third day will focus on how technical skills can be used in the service of testing.

Scheduling Note: I have openings in my schedule for February, especially if you are on the East Coast of the USA and need me to teach a class or consult.

Per Scholas: We are excited to be working with Per Scholas to provide Rapid Software Testing training to bright and hardworking men and women. As their website puts it, "Per Scholas is a national nonprofit organization that breaks the cycle of poverty by providing technology education, access, training and job placement services for people in low-income communities." We have been startled, frankly, by how eager Per Scholas students are to learn testing. It's been a real privilege working with them. If your company is hiring, consider recruiting Per Scholas graduates for your test team.

 

Happy New Year!

-- James
 

Terminology Tune-Up
If you take testing seriously, Agile can be a challenge to your craft. There are several reasons for this. I'm going to talk about one here: some Agilists change the meaning of the word "tester" in such a way as to dilute and hobble the whole enterprise of testing. I'll describe that change in a moment. 

 
First, let's get it straight what a tester is. A tester is someone whose role on a project is to perform testing. There should be no controversy about this. It's an ordinary English construction. It hinges on two further concepts: testing, and role. Testing is evaluating a product by means of experiment. Every sensible definition of testing, including all of my previous definitions and those of my colleagues, are consistent with this, but it should be noted that lots of different activities, if performed with the intent of testing become part of the testing umbrella. If I read a specification, I'm doing testing in the broad sense of the word, as long as I'm reading the specification for the purpose of preparing an experiment that will allow me to evaluate the product. Meanwhile, a "role" is a characteristic set of services that a person agrees to provide. If my role is testing, and you ask me to test something, it would be strange for me to wander off and do non-testing work, instead.

The challenge I sometimes hear from Agilists is that a tester should be someone who improves the product. This seems like an innocent and laudable idea. Who wouldn't want to improve the product? Quality is everyone's job, right?

Here's the problem with that: Think of a goalie in soccer. The goalie's role is to protect the goal. A goalie can score a goal, though. Isn't scoring goals a good thing? So, why does everyone yell at the goalie when he runs forward and tries to score a goal? The other players yell at him because he has forsaken his role-- an important role-- in order to do something useful that nevertheless is someone else's job.

Of course if a goalie can score goals without in any way sacrificing the quality of his goal-tending, that's perfectly fine. But, is that possible?

Now back to testing. If you as a tester want to improve the product, don't call that testing (because it is not part of the testing role at all), instead, face the truth and name it for what it is: part-time development. You are the goalie running forward, in that situation, and when you do so you have temporarily abdicated your role on the team.

I am not saying that a person, who is called a tester, cannot help improve the product. I'm simply saying that when and if he does so he is doing something beyond testing. That's why in testing classes and textbooks it would be weird to talk about how to architect an e-commerce site, or for that matter to talk about giving first aid or a nice haircut. A tester can give CPR, or shave your head, but no one would call that testing!

I am not telling you to stay within one role. I'm saying that you better know what your role is, or else you won't do it very well. When testers shift roles casually and chronically, they themselves, and all who work with them, risk losing sight of the skills and difficulties of deeply evaluating the product. And in any team where there is no role called tester, be not surprised when the testing process, done perhaps by "the whole team" is dismissed as unworthy of deep and systematic study.

From My Blog

Author's Note:

My blog post on testing as performance is part of an ongoing effort to reframe and reinvent the popular mindset of the testing industry. We need to wrestle the craft away from people who like to pile rocks and counts rocks and covet rocks and who have rocks in their heads. The important part of testing is the thinking part, but thinking about thinking is not easy, so managers long for a physical object, like a test case or a nice little doll, that they can cuddle and think "this is my testing! I love her!"

Time to grow up, folks. Adults must deal with abstractions. Testing is abstract and thinking-like, not concrete and doll-like. 
 
Blog Post: Testing is a Performance

Testing is a performance, not an artifact. Artifacts may be produced before, during, or after the act of testing. Whatever they are, they are not tests. They may be test instructions, test results, or test tools. They cannot be tests....
(Read More)