Greetings From EuroStar 2006!

I'm in Manchester, U.K. this week presenting at and attending EuroStar 2006. The key theme of the week has been "wet"!

I guess I should have expected that. I'm glad I brought an extra pair of shoes. That allowed me to have one "wet pair" and one "dry pair!" Although the weather has been a little dreary, the conference has been good.

Seriously, the theme this week for the conference has been "Building the Dream Team" and the focus has been on the human aspects of software testing. Scott Barber, one of three or four us here from the USA, gave a very good keynote talk on Wednesday on "Special Teams" in testing. His focus being performance testing, Scott did a great job in comparing how the critical functions, such as Configuration Management, Performance Testing, Security Testing, etc., are like the special teams on a football team (US version). You can win and lose games based on the performance of the kicking team, punt return team, etc. Good analogy!

I attended a session that discussed the feasibility of trying to define a Body of Knowledge for software testing. There certainly are many issues and challenges in doing that, but I could see some value, especially if it were an open contribution, such as wikipedia. More to come on that.

I also attended a great session today about testing the accessibility of software by people with disabilities. I came away with an increased awareness of the importance of this type of testing and some good ways to perform it, so look for some of those ideas to be developed into an upcoming article in my newsletter.

It's been great to see friends here again. The folks at Grove Consultants are always a joy to be around. I must find a way to keep Lloyd Roden from buying all my meals. Thanks Dot, Lloyd, Mark, Clive and Julie for your hospitality! Thanks to Graham Freeburn for being a great track host and for the use of a cell phone while here! Thanks to all the people at QualTech for 1) inviting me to speak and 2) for being great hosts as well.

It's been a challenge to find Wi-fi from my hotel, so I resort to trying various places. So, I must sign off now. I'm back to the USA tomorrow (Friday) and will post again soon.

Thanks for reading!

Randy

Losing Credibility in a Moment

I spoke last Friday (11/17/06) at QAI's Testing Conference on the topic of how to build and keep your credibility. The main idea is that if people don't find you credible, they won't believe your findings. I also made the point that it takes a long time to build credibility, but it can be lost in a moment.

Well, little did I know that very evening Michael Richards (aka "Kramer") would validate that point by going on a racial tirade that lasted a few minutes but may have destroyed his career. (The video is at TMZ.com)

Richards doesn't have credibility at stake as much as he has reputation and marketablility. Both took a pretty big hit on Friday evening at the Laugh Factory.

There is also the issue of damage by association. This was really bad timing for Jerry Seinfeld since the 7th season DVD is soon to be released. Some think that sales will take a hit. We'll have to wait and see on that one.

The thing that amazes me is how long it takes to build a career and reputation and quickly it can be damaged or lost.

Want to view and listen to the presentation on credibility? Just go to the presentations page on my web site and register as a free member.

Your Tax Dollars at Work

I'm here at QAI's testing conference where I'll present a keynote address on Friday about Credibility.

Surfing today's top stories, I came across this jewel at msnbc.com:

Pentagon money-saving travel site - doesn't

Half-billion dollar system hardly being used

http://www.msnbc.msn.com/id/15746788/

Synopsis: "The Pentagon that gave taxpayers a $434 hammer and a $600 toilet seat cover now has a half-billion-dollar travel booking system that is bypassed by more than eight in 10 users.

Senate investigators found the Pentagon's Web-based product - despite its high price tag - fails to find the cheapest airfares, offers an incomplete list of flights and hotels and won't recognize travel categories used by the National Guard and Reserves."

My view is that this kind of thing is all too common. After all, wasn't the whole point of SEI's CMM and other work supposed to help prevent these kinds of things?

After seeing a lot of these types of projects up-close, I'm convinced that the contracting processes are beyond broken. The contract was awarded in 1998 to a company that is now part of Northrop Grumman Mission Systems. So, this has been in process for about 8 years.

Has anyone there heard of Orbitz, Travelocity, etc? I'm sure there are "reasons" why a simple solution like that would not be feasible (special government rates and all), but I bet they go back to contracting rules and regulations - the same framework that spends half a million dollars on a system that people won't use. In fact, I have asked for government rates at hotels before only to learn that the rate I got on the Internet was actually cheaper!

My friends that work for the government are also very frustrated by the way these types of projects are initiated and performed. So, my beef is not with them, it's with the system that rewards the "beltway bandits."

This is just one more example of what I often tell my students that "The best defect you can find is the system that shouldn't be built." The average cost per defect on that one is in the millions of dollars range!

Just something to remember next April 15th!

StarWest Post #2

Today (Wednesday, Oct. 18, 2006) we had three great keynote sessions.

First, Harry Robinson of Google spoke about "How to Build Your Own Robot Army". I thought this was one of the best presentations I have heard at a conference. The main thing I took away from Harry's talk was that test automation can move beyond just repeating carefully constructed scripts to test a variety of functions repeatedly and somewhat randomly.

I think this could find many more defects than the way we currently test and perform test automation. Also, the cost of testing using robots can be many orders of magnitude less than anything we are currently doing.

Do you know anyone who would test for $1.25/hour USD? Plus, you can share the robots with developers to advance testing in the development process, which reduces defects found in testing, and makes life better for everyone.

You can learn more about Harry's work at www.model-based-testing.org.

Gary McGraw of Cigital spoke on security testing. It was a great presentation as well. The main things I took away from the talk was that 1) the more code, the more bugs there are, 2) bad guys exploit bugs to gain access to systems, 3) to find these bugs, you must think like an attacker.

Finally, Lloyd Roden of Grove Consultants (UK) spoke on the Top Ten Myths and Illusions of Testing. Lloyd is a good friend and I greatly enjoyed his address. His talk was thought-provoking and entertaining. Just a few of the myths and illusions he covered were: anyone can test, senior managers are interested in bug counts, and quality can't be measured.

It was a good day with lots of great ideas and information!

StarWest Post #1

I'm at StarWest in Anaheim, CA this week. Thanks to those of you who attended my tutorial session on Monday on "Becoming an Influential Test Team Leader." We had a great time.

Some of you have asked for the list of testing challenges we made during the session, so here it is (not in any particular order):

1. Getting the right technology match (i.e., test tools) for the type of testing at hand

2. Not having enough time for testing

3. Lack of testing skills/training

4. Inability to reproduce defects

5. Insufficient documentation

6. Changing requirements

7. Knowing when to stop testing

8. Cultural resistance to testing

9. Lack of time for training

10. Holding back defect information to look good later in the project

11. Testers being seen as an obstacle to progress

12. No time reserves

13. Over-reliance on testing to find all the defects

14. Lack of human resources

15. Testing only along a narrow path (lack of rigor in testing)

16. Schedule-driven projects

17. The wrong people performing testing

18. Communication gaps

19. Resource planning

20. Non-tangible nature of QA/test

21. Transitioning to automation

22. Understanding how customers use a product

23. Managing offshoring of testing

Whew! What a list!

We determined that 18 are human in nature, 1 (#1) was purely technical and 4 were both. So, this validates the thesis of my book, Surviving the Top Ten Challenges of Software Testing, that most testing problems are people problems.

I'll check in later this week and give my thoughts on what I am hearing and seeing at the conference.

Randy Rice's Software Testing & Quality Blog

Remembering Steve Irwin

I was truly saddened to hear of the freak accident that killed Steve Irwin (The Crocodile Hunter) recently. It took me a while to realize what I will miss most about Steve. After all, it was so easy for me to drop a quick impersonation into a class – “Crikey, mate! That’s a mean defect!”

The thing about Steve that will stay in my memory is his passion for what he did. He died doing what he loved and there is no way he could have lived without being immersed in nature. Twenty feet away from a crocodile just wouldn’t do for Steve. He had to have his arms wrapped around the croc. I saw him once crawl right up to the opening of a den of rattlesnakes. I live in rattlesnake country and one mile away is a comfortable distance for me.

In my test team leadership courses and tutorials, I discuss the importance of finding where people are passionate and then letting them do things they really love to do. However, the first thing is that people must have a passion for something. I think most people have at least one thing they really love to do. I pity those that don’t.

Passionate people do what they love to do and perform with excellence. They go the extra step to make sure things are right because 1) they love getting it right and 2) they don’t want to appear to be a novice.

A passionate customer service representative spends the extra time with a customer to make sure things are right and gives friendly service, not treat a customer like they just interrupted Monday Night Football.

A passionate delivery person doesn’t leave perishable items on the doorstep in 100 plus degree heat without ringing the doorbell.

I think you get what I mean.

There's a great little book called "The Fred Factor" which I highly recommend. It's a true story about a postman named Fred that does an ordinary job in an exceptional way.

A passionate software tester looks for ways to improve their craft. They mentor other testers and contribute to the profession. They take pride in what they do. They don’t blame others for mistakes. Instead, they learn and improve from them.

I love what I do. (A special shout out to American Airlines “That’s why I fly!”) It means a lot to me when others see that I have passion for what I do. Sometimes people will comment on a class evaluation that they can tell I am passionate about software testing. I know that may seem odd that something as detailed (and sometimes boring) as software testing would float my boat.

Software testing is just the vehicle. What I love is to help people be their personal best so they will have a better job and live. I love helping people that create software find, or better yet, avoid, the problems that may one day cause a user to experience problems, perhaps even injury or death.

I personally hate defective software and the ensuing frustration, but I really love being part of the solution instead of the problem. So, as an honor to Steve Irwin and his contribution to this world, I invite you to join me in praying for Steve’s family and reflecting on:

“What am I passionate about?”

“How can I do more of what I love?”

“Do others see my passion for what I do?”

I’m sure that honors Steve’s life and keep his memory going in our own lives.

At the end of the day, there is much more to life than work. However, as a wise person once said, "If you love what you do, you'll never work another day in your life." As I say, love what you do, but before that, love those around you.

By the way, remember the movie "City Slickers?" Passion is that "one thing" that you care about more than anything else.

Take care and have a blessed day,

Randy

Links of Interest

Here’s an interesting link. It’s the text of a commencement address given by Steve Jobs that echoes this theme:

http://news-service.stanford.edu/news/2005/june15/jobs-061505.html

Here’s a link about “How to Do What You Love by Paul Graham:

http://www.paulgraham.com/love.html

Randy Rice's Software Testing & Quality Blog

The Risks of Risk-Based Testing

I'm sorry about not posting sooner. Things have been busy lately.

I've been doing a lot of writing and training lately. I've been working on some cool new projects as well.

One thing I want to let you all know about is an article that will be published in the October 2006 issue of Better Software. It is titled, The Risks of Risk-based Testing. It occured to me while listening to a recent presentation about risk-based testing that although I use risk-based testing quite often, I have also been burned by risk. So, I wrote an article to detail the 12 ways I have been fooled by risk. In the meantime, you can read a rough version of the article at: http://www.riceconsulting.com/articles/risks_of_risk_based_testing.htm.

Bill Perry and I are also working hard to finish our next book, Testing Dirty Systems. I'm not making any predictions on when the book will be available, but we are working diligently on making final comments for the editors at Dorset House.

Thanks for your support and for reading my blog. I'll be back soon!

Randy

Lessons Learned and Re-learned

This week I embarked on a search for one particular conference presentation I remember hearing at a testing conference a few years ago. This journey down memory lane took me through conference notebooks from the last 15 years.

I started seeing things that I had forgotten from software testing conferences since 1989. Of course, there's a lot of water under those bridges.

Just a couple of weeks ago I was talking with Rick Craig at StarEast about some of those conferences we were at a long time ago and he remarked about how interesting it is that many things are still the same in software testing. A test plan is still a test plan, management still doesn't "get it", we are still on the search for the "magic" test tool, etc.

There have also been some notable new things such as exploratory testing, pairwise testing, and agile methods that have added greatly to the software testing profession.

I could not help but wonder about how much of all of this collective testing knowledge has actually been put to use. I hope for the investment in presenting and receiving this information, it has been helpful to many people, but still I wonder...

I also saw presentation by many friends and remembered many fun times at the conferences with these people.

I've been an independent consultant for over 16 years now and last week I had to relearn a lesson forgotten. The exact lesson is not the important thing. The point is that we often take for granted what we have learned and we can forget even hard lessons over time if we don't revisit them occasionally.

Journaling is helpful for reviewing past lessons learned, but so is reflection. I may even embark on a project to write my own "lessons learned book" just for me.

The great thing is that after relearning this recent lesson, I feel it has burned in even deeper to my being. These are not trivial things. These can be life lessons as well as professional lessons.

How do you revisit your "lessons learned?"

Sudoku - A Great Learning Game for Testers

It happened innocently enought. I was getting ready to board a flight to London and this book of Sudoku puzzles caught my eye in the airport. So, with 7 hours of time ahead of me and 1.5 hours of laptop battery life, I thought, "why not?"

I had seen people engrossed over these puzzles with only numbers instead of words. They look similar to crossword puzzles, but only have the numbers 1 through 9 in the completed puzzle. It normally takes between 15 to 45 minutes to solve a puzzle.

I am now an addict. What I have discovered that these puzzles are a great way to develop mental abilities of deduction and elimination. (Guessing only messes you up.) Of course, these are key skills for testers - to be able to deduce software processing rules and behavior by only what you can observe. (Unfortunately, testers all too often lack access to well-defined software requirements.)

There are also strategies you can learn that makes the process go faster. That's also part of the fun - developing a system you can use over and over. Sound like testing?

So, if you are looking for ways to build you or your test team's abilities to solve problems by deduction, try working a Sudoku puzzle (I recommend starting with the easy ones.), but be careful - they can be addictive!

Here are a couple of links: www.sudoku.com
www.websudoku.com

The Habit of Software Testing

In a software testing class I was teaching last week, the manager of the department made some opening remarks to his team. In emphasizing the importance of the class, he said that his goal was that people would see testing as a habit.

This got my attention because I have heard testing described as an art, a craft, a process, a discipline, but never as a habit.

I have used the illustration before of testing being like flossing teeth - at least for developers. We all know we need to do it, but for lack of time, lack of floss, messes on the mirror, etc., we (at least "I") many times neglect to floss. Then, the dental hygenist gets onto me about it. I feel guilty for awhile, floss every day, then I start skipping days. Before long I'm out of the habit I never really developed in the first place.

Habits are both good and bad, developed over time by repeated performance. You don't necessarily need a written set of instructions to follow every time you do something, but at first they may help.

Before long, you do something so regularly, it starts to feel natural - like stopping by Starbucks every morning on the way to work, or picking up a morning paper at the newsstand.

What would testing look like if it were a habit? Perhaps we would by second nature take a second or third look at something. Or, we would have a checklist or set of test cases we would perform each time just before we sent something to someone.

As testers, we have the habit. We check and double-check things. We look both ways before crossing one-way streets because...well, we just do it.

My thought is that if we can make testing easier, less intimidating, people may see it as more achievable and do it more often until...it becomes a habit instead of a duty.

I've always said in my presentations that if something is easy to do, it's easy not to do.

I really believe this is true in testing. Sure, there are things about testing that can get complex and hard to wrap our minds around. However, there are many aspects of testing that are more related to habit or discipline than knowledge.

So, regardless of your role in your organization - developer, tester, user, etc., I encourage you to do the little things in testing one step at a time and get into the habit of testing.

Welcome!

Hi everyone!

Well, I finally took the plunge and decided to start this blog dedicated to software testing and other software quality-related issues. I still plan to continue to publish The Software Quality Advisor Newsletter online, but this will allow me to create and share information much quicker than I ever can with the newsletter.

I also look forward to interacting with you through the comments to the postings.

Here we go...enjoy the ride,

Randy