Monday, May 20, 2013

Update on May 20 Tornado

Hi Folks,

Thanks to everyone who has contacted me concerning the tornadoes here today. Thankfully, we were spared, barely.

I was at a client in OKC to attend at 2:00 meeting, which was canceled. It was looking stormy, so I decided to head home. About when I arrived home, the tornado sirens started to sound.

As the tornado approached, I was on the back porch watching it come directly toward us. Just like May 3rd, 1999 all over again. So, I hustled Janet and our two pugs into the car and drove north. We don't have a storm shelter (I think we will soon). The tornado took a turn toward the east, so no damage at our place. But, the loss of life and damage is terrible, especially the children at the school.

(This is a short video I shot from our car. You can see the tornado moving from the right of the screen to the left behind the Homeland store.)

Both our sons and families are fine, although had Ryan (our oldest) and his family not moved 6 years ago, they would have been wiped out and our oldest grandson would have been at the school where the 7 children died.

I don't what it is about Moore. It's like a tornado magnet. It's just really bad here right now. Your prayers are needed.

The people here are tough and resilient. We will rebuild and go on, but the loss of life is the worst part. 51 lives lost as of this writing.

Thanks,

Randy

Update: May 21

Here are some more pictures:

This is the path of the tornado:


















Here is what I was looking at on radar on my iPad when I decided it was time to bug out:

















Here is a pretty dramatic picture after the first tornado. This is a second lowering. This didn't form into a tornado:


Friday, May 17, 2013

Help With a Survey on Software Test Profesionals

I am working on an article about software testing as a profession. This is a controversial topic to some people and I would like to get your thoughts.

I have created a very short (10-question) survey that will help me write this article. It will only allow 50 respondents, but I would like to invite anyone to participate at:

http://freeonlinesurveys.com/s.asp?sid=prgud68m40uqzws270184
I will share the results and also let you know when the article is out.

Thanks for your help!

Randy

Wednesday, May 01, 2013

Thoughts on the ISTQB Open Letter

Since it is hard to elaborate a response in 140 characters, I am blogging this. First, full disclosure, I am on the board of directors of the ASTQB and I am a training provider of ISTQB certification courses, as well as over 60 other courses I have written. (I make a small percentage of my income from ISTQB training.) I was also a founding author of the CSTE test certification from QAI. This is from my own perspective and does not represent the views of the ISTQB or ASTQB.

Second, I really believe as testers we have the right and responsibility to ask questions. So my issue is not with the asking of questions. We can still be friends.

I tweeted yesterday that "The open letter to the ISTQB is meaningless." Here's why.

1. The letter fails to distinguish between the ISTQB and the country examination boards (such as the ASTQB, Canadian Testing Board, UKTB, etc.) that write and administer the exams. Therefore, the ISTQB does not write exam questions. To get the answers to the questions about the validity of questions and coefficients, you would have to write such a request to each individual country exam board. The ISTQB may provide a high-level response, but it can't answer the detailed questions posed because it simply doesn't have the information.

2. There are Non-disclosure Agreements in place to protect the intellectual property of each country board and the ISTQB in general. One of the challenges with any exam (ITIL, PMP, etc.) is to keep the contents of the exam confidential as to prevent questions from being passed around. There is a sample exam available on the ASTQB website that gives a flavor of the questions being asked. Kryterion would not release results because they also have confidentiality restrictions.

3. "Have there ever been any problems with the validity of the exams?" This is like asking, "Are you still beating your wife?" Everything has shortcomings. The reason the ASTQB invested in independent exam reviews and measurement was to make the exam as valid as possible.

I agree that the questions on the exam must be a valid reflection of the learning objectives in the syllabus.  As a training provider, I don't know what is on the exam. There is a firm line of separation. I focus on the methods and application as opposed to the brain cram approach.

That's it for now. Gotta get back to the test lab.

Thanks,

Randy





Wednesday, April 10, 2013

ISTQB Foundation Level Training Coming to Atlanta - June 5 - 7, 2013

We don't conduct many public courses, but are going to host an event in June in Atlanta. If you have been thinking about getting certified in software testing, here's your chance!

The instructor will be Dr. Tauhida Parveen, an authorized ISTQB trainer and author of two testing books. (And a great trainer!)



For more information and to register, click here:
https://www.mysoftwaretesting.com/ISTQB_Foundation_Level_Course_in_Software_Testing_p/ctflpub.htm

We hope to see you there!

Thursday, January 31, 2013

Notes from Today's Webinar - Test Data Strategies for ICD-10 Testing

Here are the notes from today's webinar on test data strategies for ICD-10 testing.

Download slides in PDF format.

In this session, Dexter Oliver, Randy Rice and Dr. Tauhida Parveen outlined the importance of test data in ICD-10 testing, and some ways that the test data challenge can be addressed. Getting the right test data is one of the most challenging aspects of any type of testing, but ICD-10 poses unique challenges, such as:


  • Which diagnosis codes will need to be included?
  • Which business conditions will need to be supported?
  • How much data will be needed?
  • Where will the data be obtained?
  • How will resources be allocated to create test data and perform testing? 
The video will be posted shortly.

Thanks,

Randy

Monday, January 14, 2013

Addressing Test Data Concerns in Your ICD-10 Test Planning

 Thursday, January 31st, 2:00 P.M EST

In this session, Dexter Oliver, Randy Rice and Dr. Tauhida Parveen will outline the importance of test data in ICD-10 testing, and some ways that the test data challenge can be addressed. Getting the right test data is one of the most challenging aspects of any type of testing, but ICD-10 poses unique challenges, such as:

  • Which diagnosis codes will need to be included?
  • Which business conditions will need to be supported?
  • How much data will be needed?
  • Where will the data be obtained?
  • How will resources be allocated to create test data and perform testing?
We invite you to join Dexter, Randy and Tauhida in this free and informative session to get the right test data in the most efficient ways.

Register Here:

http://www.anymeeting.com/PIID=E952DD84834D31

Thursday, December 27, 2012

Rolling Up The Year

Hi Friends,

Something I learned from one of my mentors, Jim Rohn, is to reflect at the end of a period of time and think about:

What went well?
What could have been better?
What can we build on?
What can we be thankful for?
What have we learned?

Mr. Rohn talked about the impact this would have over years and even a lifetime. I am convinced this is a big part of gaining true wisdom.

Prolific leadership author and coach, John Maxwell, says he does this on a weekly basis sitting in his hot tub. For me, I tend to reflect more on an annual basis (not in a hot tub).

In my "Becoming an Influential Test Team Leader" tutorial, we discuss this as one of the 15 ways you can add value to your team without spending a lot of money. This really is "low hanging fruit," but we tend to miss it. Even individually, as a leader, this is a good time to think back over the year and roll the lessons into major themes to remember and value.

I would caution you about being too hard on yourself. Sometimes, hard introspection is needed, but we have enough negativity coming our way from the external. Imagine what a coach might be telling you. Not the coach that was always berating you, but the one that you may have found encouraging, yet holding a hard line of accountability.

I don't know how many things you will have on your list. By the way, this is a good time to journal them. (You don't keep a journal? Fix that in 2013!) I typically have about ten to twelve things that stick out over the year. It is interesting to go back several years to see if I really am learning from my personal retrospectives.

In many ways, life and work is a test. So think of this as your annual "test summary report." I hope things went well for you this year. I hope in the areas they didn't go so well, that you find 2013 to be a better year. Inasmuch as things depend on you, I hope you gain the skills and knowledge to excel. In the areas that are circumstance-driven, I hope you will find peace and endurance. I'm pulling for you!

Randy

Thursday, December 20, 2012

Cheap Pizza and Software Testing

Yes, pizza and software testing have a relationship, and not in the way you might expect. Of course, pizza is the fuel of any test lab (One of my friends said there were visible rings in one of the test lab tables where pizzas were often set!).

However, my mind is going a different direction.

In our neighborhood, we have several pizza places, some small mom and pop places, some large chains, some franchises. You probably have the same mix in your area. They have varying levels of quality. In fact, the "big name" is the worst by far. The smallest place was the best by far. The word "was" is because they closed this week, which really disappointed me.

What has happened over the years is that the price point for a "large" one topping pizza has reached $5. Anything over that is seen as "too much". Quality isn't a factor, only speed and price. So a race to the bottom has ensued.

Really, at $5 a pie, that's in the frozen pizza range!

I see the same thing in software development and testing. How much is "expensive" for an iPad app? $1.99?  $5.99?  $19.99?

How much is a bug worth? $1, $5, $5,000, $40 Million (If you are Nasdaq!)

How much are testers worth? (What if they really knew your business and were the glue that holds a project together?)

How much is a good developer worth? (What if they were crazy good, not "kings and queens of their domain" and your products were amazing?)

Pizza has become a commodity and unfortunately so has software development, testing and training.

How much is a really good pizza worth to you? I'll bet it's more than $5. How much would you pay in a place like Rome, or with a good friend or loved one?

Cheap pizza, like cheap testing gives a false sense of value. Cheap doesn't necessarily mean bad. However, cheap is often bad.  Value is good outcomes for a reasonable cost.

By the way, I would have gladly paid much more to keep my favorite place open. At this point, I must confess that I am part of the problem whenever I buy things on price over value. It fuels the problem.

As testers and software people, we need to provide value to a market that wants cheap and quick. When we stretch things too thin, we provide little value and even negative value at times.

Now...I know you all will suggest great places for pizza that is not cheap. Feel free. I travel a lot and keep a list. I just need a good place close to me!

I wish you all a very blessed Christmas and a very prosperous and healthy 2013!

Randy

Friday, December 14, 2012

Free Webinar - Three Success Factors Critical to Determining Your ICD-10 Testing Strategy

Thursday, December 20, 2012
2:00 EST - 3:00 EST

Presented by Dexter Oliver of Integritas Solutions and Randy Rice, of Rice Consulting Services, Inc.

The Centers for Medicare & Medicaid Services (CMS) has mandated that everyone covered by the Health Insurance Portability and Accountability Act (HIPAA) use the ICD-10 coding standard by October 1, 2014.

This mandate will impact all entities that report and pay claims. This includes hospitals, clinics, insurance companies and physicians. Furthermore, service providers such as medical coding services and other vendors, such as software companies will also be greatly impacted.

The U.S. Department of Health and Human Services predicts that claim errors will rise to between 6% and 10% of all claims, up from an annual 3% under ICD-9. There are many technical challenges with the ICD-10 conversion because of the breadth and depth of how the classification codes are used in both clinical and business processes throughout the healthcare ecosystem. HIM Managers must partner with their IT organizations to implement solutions as well as develop testing strategies to mitigate the major financial and operational risks associated with this transformation.

In this FREE webinar, you will learn three critical steps to help develop a testing strategy that will help organizations achieve compliance cost effectively.

Register at: http://www.anymeeting.com/PIID=E951DB80854A30

Wednesday, December 12, 2012

Book Review – How Google Tests Software



How Google Tests SoftwareBy James A. Whittaker, Jason Arbon, Jeff Carollo
Published Mar 23, 2012 by Addison-Wesley Professional.
Copyright 2012, Dimensions: 7" x 9-1/4", Pages: 320
Edition: 1st
ISBN-10: 0-321-80302-7
ISBN-13: 978-0-321-80302-3

Click to see on Amazon.com

The main question you may be asking is “Why do I care how Google tests software if I’m not a start-up or a development company?” Great question!

While your situation will likely not be the same as Google’s, there is a lot to be learned in how they do things in development and testing. That’s because they seem to have the secret formula in getting features to market quickly and with good quality.

Not only did this book give me ideas about how to make testing software more productive, it can give anyone a perspective of software testing not found anyplace else. Most other books address testing from the perspective of “Here’s how testing should be performed.” This book comes from the angle of “Here’s how we do testing.” There is a big difference.

It is tempting to skip the preface and introduction when reading a book. However, these provide critical context and a good summation of what you can expect to take away from the book.

You will see several perspectives of testing at Google:

First, there is the historical perspective of how Google matured both as a company and test organization.

Second, you will read how James Whittaker, an already accomplished and notable testing guru, joined Google and had to do innovative things of value to carry his weight there.

Third, you will read perspectives by the co-authors and their interviews with developers, testers and managers at Google about their roles and responsibilities.

Finally, the authors outline in complete detail both how Google tests, and why they do things they way they do. Some key takeaways for me were:

·      Using tours as a basis for exploratory testing,
·      The concept of writing a 10-minute test plan,
·      The value of crowdsourcing for testing,
·      Getting maximum value from early testing from test engineers who are developers at their core (People always want to get better testing earlier in projects. This book explains how to do that!),
·      Seeing Google's testing framework in action.

I can highly recommend this book to people who are looking for new ideas to revamp testing processes and organizations.

Monday, November 19, 2012

CTE-XL 3.1.3 - A Big Disappointment

For those of you who have attended my classes and tutorials, you know I have been a big fan of CTE-XL to create test cases with classification trees. This tool has been provided in a free version and pro version by Berner-Mattner in Germany.

In the most recent version of CTE-XL, 3.1.3, the vendor has made virtually every feature except drawing a tree (which you can do with many other free tools) a "professional" option. The pro version is 1,250 Euros per node-locked user, plus VAT. So, the free version is worth what you pay for it. Is the pro version worth the cost? Probably, if you are going to use it a lot and don't plan to deploy it to a lot of users. My issue is, why bother with a "free vs. pro" option if the free version gives little idea of the concept of the tool, which is test generation?



So, it was good while it lasted. For those of you with prior versions installed, stay with them.

Just as an example, here is a tree created in an awesome, free tool called yEd:


You can't generate test cases with yEd, but you can't do that anymore with CTE-XL, either. At least with yEd you can also create flowcharts, UML models and many others.

http://www.yworks.com/en/index.html

In the meantime, I am looking for a good developer and others who would like to join in an effort to develop a similar tool to stay in the Free category of test case generation tools. If interested just comment below.

Thanks!

Randy

Thursday, November 01, 2012

Join Us in Supporting Relief Efforts for the Northeast

In Oklahoma, we have experienced the devastating impact of natural disasters, especially tornadoes. Each time we have had a major disaster, people from the Northeast were here to help us. Members of the NYPD and NYFD were here to help after the Murrah Building bombing. Also, the Red Cross and Salvation Army were here for months afterwards in these disasters.

Now it's our turn to return the help.

We are making an initial donation, but ask you to join with us either directly at:

http://blog.salvationarmyusa.org/category/eds/

or by enrolling in an online e-learning course. We are donating 10% each week for all e-learning enrollments. Please understand this is not a sales ploy. It's just our way of helping by sharing what we earn.

http://www.mysoftwaretesting.com/

Thanks!

Randy

Wednesday, October 03, 2012

Self-Assessments from Becoming an Influential Test Team Leader Tutorial at StarWest 2012

Hi Folks,

I promised the people in my Tuesday tutorial at StarWest 2012 the Word versions of the two self-assessments: One on the people issues in testing and the other on building core competencies in testing. Here they are!

People self-assessment
Core competency self-assessment

Feel free to modify for your own purposes. Thanks to everyone who attended my tutorial. It was a great time!

Friday, September 07, 2012

How to Wow Customers Even When You are Closed

Here I am in Cuchara, Colo, sitting on a boardwalk in 72 degrees and light rain (elevation 8,600 feet above sea level), outside a great little coffee shop, Brewed Awakenings.

Don't you love catchy names?

Unfortunately, almost every store in the village, including the coffee shop is closed because the Summer season is over. The owner of the shop (at least I think she is the owner  :-)  ) walked by a few minutes ago, unlocked the door to go in and I heard her say to someone, "I just need to get the cinnamon rolls."  (They have AWESOME ones.)

Me being vocal self, said "Sure, I'll take one," and just laughed. A few minutes later, out she comes with one on a paper plate. Keep in mind, the shop is closed!

I said, "Please let me pay you." She said, "Oh, just come back in sometime."

Isn't that great?  I'll be back tomorrow morning for sure!

So, I'll just finish my awesome cinnamon roll and wish everyone a great weekend.

Friday, June 01, 2012

Software Defect of the Week - Nasdaq Crash

http://www.huffingtonpost.com/2012/05/20/facebook-ipo-nasdaq_n_1531869.html

This one makes me go, "Hmmm."

The quote that got my attention was, "Greifeld [Nasdaq Chief Executive Robert Greifeld] also said extensive testing that was performed ahead of the deal failed to spot this problem."

I wish I had a dollar for every time I have heard or said that.

In other reports, Greifeld alluded to coding problems.


"Nasdaq’s systems fell into a “loop” that prevented the second-largest U.S. stock venue operator from opening the shares on schedule following the $16 billion deal, he [Geeifeld] said."

Just a few thoughts:

1.  This is a good example of the public impact of a software defect.
2.  The CEO took the heat, publicly (I shudder to think of what was going on in the testing group), which shows that when the stuff really hits the fan it is senior management that talks to the reporters.
3.  Life went on, but the public perception of the Nasdaq trading system has been eroded, at least for a while.
4.  I'll bet that the performance test team gets all the test resources they request. (If things are really that simple.) 
 
I guess the part that troubles me is if the general public is so accustomed to software failure that it's not seen as anything more than a "hiccup" or "glitch."

I would like to hear your thoughts on this.

Friday, May 25, 2012

Friday, May 04, 2012

Software Defects of the Week

This has been one of crazy weeks, but I have to write about these two incidents. I'm one of those people who, like a bug collector, love to study these problems to learn from them for future prevention.

The first one happened right here in my home city of Oklahoma City. We have this awesome NBA team, The Thunder, that is in the playoffs.

When the tickets went on sale online, some people in Oklahoma City were not allowed to buy a ticket. They received an error message to the effect they didn't live in Oklahoma, Kansas or Arkansas. OK....Turns out, there is a business rule that said priority for tickets go to people who live in the area. Fine. But, these people live in OKC. What happened was that the front office used a file from the U.S. Postal Service to validate the zip codes from customers. I mean, who better to know which zip codes are valid, right? However, there were a few zip codes missing.

This brings up an interesting and common testing problem. How does one find such a defect? In this case, it's a conundrum.

You could say, use equivalence partitioning and test each zip code as a class. But, how do you identify all the zip codes? Especially, if the postal service info is incomplete to begin with! Plus, that would take a long time to do manually. Automation could do the job quickly, but you need a secondary source to compare the correct codes.

My solution would be to either 1) do an automated test using the known customer zip codes (like from a mailing list), or 2) do a manual test that samples from the customer list. This still would not assure the defect would have been found.

In the end, the team did the right thing and sold the affected people seats at a discounted price, once they learned of the problem. Now, perhaps, hopefully, this can be a test case for the future!

The second issue occurred in Auburn, California. Here's the account according to NPR:

"Traffic jams in California - well, they're nothing new. But one recent tie-up on Interstate 80 was noteworthy since it was caused by a computer glitch. The Placer County court accidentally summoned 1,200 people to jury duty on the same morning. Taking their duty seriously, residents tried to be on time at 8:00 a.m. and were in a line of traffic with other would-be jurors. The court apologized but said a real jury summons could be coming soon."

"We apologize profusely," court executive officer Geoff Brandt said of the error.

My take: I'm skeptical. Sounds like there could be some human error involved! I mean, if I input the wrong selection criteria in for the summons, I wouldn't want to take the blame either.

I doubt we will hear of the root cause, but it would be interesting to know.

Keep taking those backups!

Thursday, April 19, 2012

Mac Test Automation Tool

I had a brain freeze today during my live online interview with James Lyndsay. D'oh! The cheap Mac test automation tool that slipped my mind at the time is called "Fake". It's $29 USD and found at www.fakeapp.com.

Wednesday, April 18, 2012

Risk Assessment Slides from Star East 2012 Tutorial

Thanks to everyone who attended my tutorial at StarEast 2012 on Becoming an Influential Test Team Leader. In that session, I briefly discussed my risk assessment method. Here are the slides, plus the flipchart notes for the challenges of testing (yes, all of them!) we listed. For those not there, you will see in the fourth picture, the "human" or "both" (technical and human), were the big winners.

























This is the chart for short-term, mid-term and long-term goals.

Tuesday, April 03, 2012

Software QA Ranks #3 in the Robert Half Technology Salary Guide

I normally don't get excited about being #3, and sharing the honor as well. But after years of being almost ignored on salary surveys, QA and Business Analysts hit it big in the Robert Half 2012 Technology Salary Guide. Thanks to Hubert Lee (The Dashboard Spy) for publicizing this!

According to the study, QA and Business Analysts are #3 in the "Top 5 Tech Professionals Businesses Want Now" category:

"With more dollars available to IT projects, managers are focusing on quality control and assembling more accurate project requirements. Quality assurance professionals can relieve developers so they can focus on coding, while business analysts can help build trust among stakeholders and serve as go-betweens for technology and business."

You can download the report here:

http://s3.amazonaws.com/DBM/M3/2011/Downloads/RHT_SalaryGuide_2012.pdf

Want to get into QA or Business Analysis? Check out these courses:

http://riceconsulting.com/home/index.php/Table/Basic-Training-Courses/

Or, if you want to get certified in testing, we have the training for you!

http://riceconsulting.com/home/index.php/Table/ISTQB-Training-for-Software-Tester-Certification/

Add value to your company by getting the knowledge to support better project results!

Wednesday, March 28, 2012

Random Thoughts After the Conference

I had the pleasure of ducking in and out of STPcon today. So, the conference is still going on, I just had to leave early. I've been doing the testing conference thing for 24 years, speaking for 23 of those years. So, I've been to the rodeos quite a bit.

So many ideas are swirling about, which is a good thing. The challenge is sorting them out to make sense in your own situation.

I was observing the panel discussion about agile testing and some things struck me:

1) What happened to XP... and then, Crystal and then...? What I mean is they apparently went out of style. In 2001 I was at a conference where XP was the solution to all problems. Now, it seems there is a new kid on the software block, Kanban. So, the discussion is around Scrum vs. Kanban.

This all makes me think there is "nothing new under the sun." People seem to want to follow the new thing, which I totally get, but why? Typically, it's because the present methods have problems. Why?

The reasons go to deeper issues, I think, than the flavor of the methods being used. I keep going back to my mantra that "the magic is not in the method." It is something deeper and more esoteric than a methodology.

I am convinced I was on an agile team in 1979.

2) People, tools and process...if you gravitate to just one or two of these, you will be out of balance.

OK, so you love the people and the team. That's great and the right people, all being able to get along is key to good projects. But...even the best teams need the right tools and the right methods to get the job done.

3) The customer is king, regardless what your process is. Your customer may be the end-user or the CEO. If they want something, you better get it to them (thanks, Scott Barber, for making this emphatic point today!). If you stick with your process in opposition to what your customer wants or needs, you will be replaced.

I once was teaching a class when on the afternoon of day 1, half of the class had to leave. Some of you cynics are thinking "I can totally see that" but no, it wasn't due to the teacher. It seems they had to restore functionality of a change back to the original version. They got the requirement totally right. They implemented the change 100% correctly. However, a powerful stakeholder got so much push-back on the change, he said "pull it." So, even though everyone had done their job correctly, there was still a problem that had to be dealt with. (By the way, this was all based on a new state law that was passed and was being implemented. The stakeholder was a state senator.)

4) Software development is a creative process and has to be managed as such. It's also a knowledge-based process and knowledge-based workers are not the same as other types of people. Otherwise, we could create software with software all the time, not just some of the time. I know, we have visual tools and the like, but remember CASE tools? There are some principles of manufacturing that can be applied well in software, but we must remember that software is intellectual in nature.

5) Release processes drive almost everything else. If you get this wrong, you can get really bound up. Some of us can recall the famous "I Love Lucy" episode where she and Ethel work in a chocolate factory wrapping the candy as it travels down the conveyor belt. The candy keeps coming faster and faster. They can't keep up and start eating it, stuffing it...funny stuff. I see this in software projects all the time. Too much work, too fast pace, people just try to get the stuff out of the door. Then when things don't work, the testers get blamed.

No matter which method you use, if you can't control scope and pace, you won't succeed. You will always be behind and your customer will always be complaining.

Well, those are some thoughts in the airport. I would like to hear your thoughts.

Tuesday, March 13, 2012

Wednesday, January 11, 2012

Webinar - Everything You Wanted to Know About ISTQB Advanced Certifications

Many people who hold the ISTQB Foundation Level certification are curious about what is involved in the ISTQB advanced level certifications. This session will walk you through the structure of the advanced certifications, what you need to know, the pre-requisites, ways to prepare and the value of holding an advanced certification. There will be plenty of time for questions along the way.

I hold all three ISTQB advanced certifications and will explain the things you need to know about ISTQB advanced certification.

Time: 1/20/2012 1:00 PM (UTC-06:00) Central Time (US & Canada) for 60 minutes
Register: http://www.anymeeting.com/PIID=EB54DE818249

I hope to see you there!

Randy

Thursday, January 05, 2012

Book Review - Making it Big in Software


There is a great "secret" I tell software professionals. That "secret" is that if you want to rise to the top of your field, it's not that hard to do because so few people do the simple things to rise to the top. You will learn those things in this book.

Making it Big in Software brings a great perspective to the idea of breaking through to becoming an elite thought leader in the software profession. The first thing that caught my eye was the stellar nature of the people Sam Lightstone interviewed for this book. These include James Gosling, the inventor of Java, Steve Wozniak, inventor of the Apple computer, Grady Booch, co-founder of Rational Software, and many other luminaries in our field.

Lightstone anticipates the question most people have right out of the gate, "Why bother?"

"But with long hours, considerable stress, and no guarantees, the obvious question is whether it’s even worth trying to make it big. I believe the answer is unequivocally yes. The most compelling reason is that, in most cases, you have to show up to the office and work like a lunatic anyway—it’s really not optional (if you want to eat). So if the difference between being a midlevel career programmer and making it big is an incremental strategic investment of time and energy, then it’s more than worth it for you and for your family. In the long run, the benefits are significant: a more satisfying career, greater influence and impact within your company and the industry, more fun, and more money. And while there may not be less “crap” to do, at least it’s strategic work rather than “grunt” work."

Some of the enticing things about making it big are:
  • Fun and interesting work
  • Corporate and industrial influence
  • The betterment of society
  • Freedom to work on what you want, when you want (Lightstone makes clear that this is what you want to work on, not how much you have to work!)
  • Fame
  • Travel

(As an aside, I humbly say that as a minor software testing celebrity, I experience these things on a regular basis and it is good. While travel can become a chore, it is cool to teach in Rome twice a year.)

Software testers and QA professionals will appreciate Chapter 2, "What Good Software is Really About." This chapter is a concise case for better software and why we need to refine our craft, profession, or whatever you call what we do as software people.

Lightstone lays out all kinds of practical, real-world advice, such as "What to Look for in a Company." I like this list and it reinforces a key idea that you do not have to strike out on your own to make it big.

"1. Is this a company that has experience in building professional, high-quality systems?

2. Are there really talented people here I can learn from?

3. Is the position I’m being offered one that is interesting, with long-term growth potential on something I can believe in?

4. Do they have savvy business executives who really understand the business requirements for success and have a track record for delivering it?

5. Does the company have clarity of vision for the product it produces?

6. Is there an independent research arm?

7. How does the company innovate, and how profound has their innovation been?

8. Is the work environment pleasant and flexible, and does it suit my lifestyle?

9. Does the company seem stable? Do I believe it will still be around in ten years?

10. Is the pay in line with industry standards?"

The book goes back and forth between interviews and practical guidance, which is a good thing. The interviews let you get inside the heads and hearts of these gurus, while the guidance gives you a plan of attack.

Good economy or bad economy, it doesn't matter in terms of the importance of standing out and making your mark. Economies rise and fall. We all need to learn to not let our jobs distract us from our careers. This book helps light the way to do that. I highly recommend it to anyone in the software field!

Killer Weeds and Killer Defects



Recently I was listening to a radio interview about genetically modified crops. During the discussion, the guest mentioned the fact that farmers are starting to see “killer weeds.” These weeds are resilient to known herbicides which makes them very difficult to control or eradicate.

Being the tester I am, I immediately thought of the “Pesticide Paradox” that Boris Beizer wrote about in the 1980’s in his book, Software Testing Techniques. That principle says that just like bugs that become resilient over time to pesticides, software tests can become ineffective at finding new defects.

Another way to express this principle is to realize that your tests will grow weaker over time in terms of finding new defects.

My way of saying this is that when you repeat tests with the same conditions and test data, the tests become more confirmatory in nature than being discovery-oriented.

Similarly, there is the minefield example in which we can see that the safest way to cross a minefield is to walk in the footsteps of someone who has been successful previously in crossing from one side to the next. Seeing software defects as a mine, if we go down proven paths we don’t hit the mines.

Of course, in testing our goal is to hit the mines. As I say, “Failure is not an option, it is an objective.”

This discussion about killer weeds got me thinking about some other tie-ins with software testing and the “killer defects” we deal with.

Weeds are Ubiquitous

I don’t have a green thumb, I have a killer thumb. I’m sorry, but plants and I don’t get along that well. I have been successful in growing some things, like tomatoes, but my climate is harsh and the main things I can grow are grass and weeds.

However, I seem to have no problem with growing weeds. Have you ever noticed how resilient weeds are? They can grow in the cracks of a sidewalk!

Similarly, software defects are everywhere. Those of us in the weed control business of software (testers), have an abundant supply of defects to find. But like the killer weeds, it seems that no matter how often we spray, or pull, or mow, the weeds return.

Even when I pull the weeds out by the roots, they return because the seeds from neighboring yards (and my own yard) float into the yard or garden. Before long, there they are again.

What are the seeds of your defects and where do they originate? Inadequate requirements? Bad code? Inadequate testing?

The good news is that in software development we can actually control the seeds of defects at their source. It’s not always easy. In fact it hardly ever is easy, which leads me to the next point.

Weed Control is Maintenance

I really wish I could just spray or weed once a year, but that doesn’t work. In Oklahoma last summer, we had 63 days that were 100 degrees or more, plus we were in a very severe drought. Basically, most of the vegetation died, then caught on fire. I told people, “Welcome to Hell.”

Every blade of grass in the vacant lot next door to me was brown. There were inch-wide cracks in the clay soil that had the same consistency of bricks. There were also bright green weeds! Yes, the weeds thrived even in the absence of water in soil as hard as bricks.

Have you ever asked why, despite all your testing and other efforts, the defects seem to occur? The best answer I have is that people are human and humans make mistakes. These mistakes can be misinterpretation of needs, incorrect implementation of solutions, or just forgetfulness.

Another reason for mistakes may be the rate and nature of change. The faster we go, the easier it is to forget something or to simply become careless.

Perhaps the number one thing I hear testers complain about is maintaining their tests. This causes me to ask, “Where did this false expectation start that says tests are maintenance-free?”

The fact is that most tests will require maintenance, just like the software we are testing. However, the thing we deal with as testers that is unique is that changing one line of code may require changes hundreds of tests.

Some may say that this is why agile testing is great. I agree that agile approaches help. However, even in agile there are tests you want to remember and repeat. Yes, these may be automated. However, that may not matter in terms of maintenance since changes ripple through automated tests as well as manual ones.

Timing is Critical

Since I am horticulturally-challenged, I hire my friend Marty to spray and fertilize my yard five times a year. The first spraying in late winter is a pre-emergent. This treatment is very important to kill the weeds while they are still in the seed stage. Failure to catch weeds early means you play catch-up the rest of the year!

In software projects, early defect prevention and detection methods are key to stopping defects before they “bloom” and become larger and nastier. Activities such as reviews, walkthroughs and inspections can be your pre-emergent detection of defects.

Know Your Weeds

Marty doesn’t spray for all possible weeds in my yard. Instead, he sprays for those weeds common to our area. If rogue weeds appear, he sprays them individually as needed.

If you have ever ventured out to the hardware or garden store to buy weed killer, you know that there are many kinds, each oriented to specific types of weeds – grassy weeds, broadleaf weeds, and so on. There are treatments such as Roundup that will kill every bit of vegetation, but his is not a good option if you want to keep the good plants. That is overkill except when you want to clear out everything.

In testing, we need to know the types of defects we most often encounter. We also know that defects tend to cluster and we also know that people fall into patterns of repeating mistakes.

If we orient our tests to find the defects we most commonly encounter, that’s a good first pass. In the past, I have called this “starting a bug collection.” Now, I can also call it “a weed collection.”

Then, we can drill-down down as needed to branch out and find new types of defects.

Conclusion

Basically, we can pull weeds (a.k.a software defects), or we can work on preventing them. Pulling the weeds is hard work and seems to never end (sound familiar?). Preventing weeds takes discipline as well, but spraying in advance is easier and cheaper in the long run. Similarly, preventing defects with process improvement and finding defects early with reviews pays off in the long run.

If you know your source and types of defects, you can test wider and then focus on trouble spots. Just remember that the tests that work well today, may not be as productive in finding new defects the next time you test.

In the second installment of this article, I’ll explore why these killer defects are so hard to eradicate and the results of failing to find and eliminate them.

Friday, December 16, 2011

Video on How to De-Motivate Your Team

Hi Folks,

The featured video this week on Techwell is from the lighting keynote I did at StarEast 2011:



A little context to help understand my remarks: 1) Osama Bin Laden had just been killed and 2) there was a DECA conference at the hotel at the same time with many teenagers running around. They were well-behaved for the most part, but at the same time, we were happy to see them leave.

Enjoy!

Randy

Monday, November 28, 2011

Drilling for Gold


I was watching Gold Rush last Friday night on Discovery channel. The crew felt that they needed assurance that there was some gold in the ground below them. As one of the guys remarked, "Unfortunately, there is no arrow on the map that says, 'dig for gold here'".

In fact, one veteran gold miner said, "No drill, no dig."

So, they hired a guy to bring a drilling truck out to the site to drill all the way down to bedrock. Then, they removed the dirt from the drill bit, placed it into individual buckets (one per hole), and panned the dirt for gold.

By doing this, they confirmed there was gold in the ground where they were currently digging, and no gold at all in their "plan B" location.

Does this sound familiar? They were "testing" for gold by taking samples. The results of their tests were very valuable in guiding the next steps of their work. The risk is that it costs about $1,000 per day just in fuel costs to run the earth movers.

I think this is a really great analogy of what we do as testers, especially in black-box, top-down testing. The defects are like the gold. In fact, a software defect is more valuable than one ounce of gold when you consider the cost savings of post-implementation re-work! Then, when we learn from the defects and improve our practices, the defects have even greater value.

The main difference between gold mining and testing is that we're not always sure when something is a defect, but you can't miss gold.

My approach in top-down testing is to cover the critical workflow processes (scraping the surface). When defects are found, drill down to find others. This form of sampling makes use of the principle that defects tend to cluster.

Like gold mining, in testing, there are no indicators that say, "Look here for defects." We have to sample wisely to gain insight where to focus our efforts. There's gold (or defects) in them there hills!

Monday, November 21, 2011

Small Business Saturday and Cyber Monday Specials

We are excited to be a part of Small Business Saturday!

small business saturdayThis is a special opportunity for you to support us as a small business and to get major savings on our e-learning training courses in software testing and software quality.

Every e-learning course will be discounted from Saturday, Nov. 26 through midnight on Monday, Nov. 28th. This even includes our ISTQB Foundation-level course, which includes the exam and additional text book!

There are no limits. Buy as many courses as you like!

Plus, if you pay with American Express, you can get an extra $25 back!

American Express is promoting Small Business Saturday again this year. Register your American Express when it opens November 1st, and then use your registered card to shop at a participating small business on Saturday, November 26th. You’ll receive a $25 statement credit when you spend $25 or more at participating small businesses. From this press release:

"For the second year in a row, American Express will help drive traffic through the doors of small businesses with a special incentive: a $25 statement credit offer for Cardmembers when they register their Card and spend $25 or more on Small Business Saturday at any qualifying small business that accepts the American Express Card. Cardmembers will be able to register their cards in early November."

To register your American Express card, visit http://www.facebook.com/SmallBusinessSaturday

Here's how to get these savings on our e-learning courses:

1. If the training is for your team, get your budget allocation and approvals from your management. This is a great way to make the best use of remaining 2011 training funds!

2. If the training is just for you, don't spend all your money on Friday!

3. Visit our e-commerce site at http://www.mysoftwaretesting.com and buy the courses you like. The discounted prices will be shown.

Remember that you have 12 months of access to the courses, even after you complete the course! To see other benefits and features:

http://riceconsulting.com/home/index.php/e-Learning/benefits-of-e-learning.html

http://riceconsulting.com/home/index.php/e-Learning/features.html

To see demos of the courses:

http://softwaretestingtrainingonline.com/moodle/course/category.php?id=11

Of course, I am always happy to answer any questions:

http://riceconsulting.com/home/index.php/component/option,com_chronocontact/Itemid,90/

I hope you take advantage of this rare opportunity!

Randy

Wednesday, November 09, 2011

Book Review - The Economics of Software Quality

Publisher: Addison-Wesley
ISBN-10: 0132582201 ISBN-13: 978-0132582209
Publication Date: August 3, 2011
587 pages, hardcover


In this book, authors Capers Jones and Olivier Bonsignour quantify the factors that influence software quality and provide information for people to gain insight into how their projects might compare to others. The measurements in this book are based on thousands of software projects.

One of my frequent complaints about the software industry is that we just don't measure very many things. However, thankfully there are people like Jones and Bonsignour that do have a rich source of metrics from enough projects that we can learn from them.

Capers Jones has long been considered the source for software quality metrics. To me, Capers is the "numbers guy" of our profession. With over 40 years in the field, Jones has a wealth of information he has maintained and published over many years.

Olivier Bonsignour is responsible for Research & Development and Product Management in a continual effort to build the world’s most advanced Application Intelligence technology. Prior to joining CAST, Mr. Bonsignour was the CIO for DGA, the advanced research division of the French Ministry of Defense.

For example, the authors state that "high quality levels are invariable associated with shorter-than-average development schedules and lower-than-average development costs." This finding is based on over 13,000 projects between 1973 and today.

The authors maintain that the real economic value of high quality software is not the cost to fix defects, but rather:
  • the reduced likelihood of canceled projects
  • the reduced risk of litigation
  • shortened development schedules
  • lower development costs
  • reduced warranty costs
  • increased customer satisfaction
This book addresses:
  • What is software quality and how do we define its value?
  • How can we estimate and measure software quality?
  • How can software defects be prevented?
  • How can we find and remove defects before testing?
  • What are effective ways to test software and measure its effectiveness?
  • What is the current state of post-delivery software defects?
  • How do projects of various characteristics (low, average and high-quality) compare?
  • How can technical debt be addressed from a business value perspective?
You will find a multitude of data from projects in a variety of industries, at various levels of quality, and at various levels of practice maturity. You will see by the numbers which project approaches work and which ones don't work very well.

By reading this book, you will gain insight not only into the current state of software quality, but you will also learn about measurement and metrics of software. These are critical things for any software quality professional to learn. In fact, after reading this book, you will know more about software measurement than 95% (that's my estimate) of testers and QA professionals.

I highly recommend this book, not only as a guide for software quality efforts, but also a benchmark for your own efforts.

Tuesday, November 08, 2011

The Greatest Risk of All

I perform quite a few risk assessments on projects and in organizations. There is one risk common in almost every situation although it is not always identified. This risk is also something I have experienced generally in life. In fact, it is a risk so familiar it’s easy to miss. People get burned by this risk all the time.

Hans Solo understood this risk when he admonished young Luke Skywalker, “Don’t get too cocky, kid.”


There are many ways this risk can be seen:
  • People who tune out mentally in training because they think they already know the material. However, these people hardly ever ask any questions, either.
  • Project planners who indicate all contingencies are considered.
  • Everyday situations where we buy something, then learn the details about the product that are discovered only after trying to resolve a problem.
What is this risk that is so common and so elusive?

It is the “unknown unknowns.” There is nothing new about this. British Mathematician Alfred North Whitehead, who lived from 1861 to 1947, said “Not ignorance, but ignorance of ignorance is the death of knowledge”.


In an article published recently in the journal Science Communication, Jerome Ravetz writes:


“The idea of ignorance of ignorance is quite unfamiliar. Indeed, scientific culture generally suppresses awareness of ignorance. But ignorance of ignorance was quite well-known from Plato and Socrates onward; it became unpopular in the scientific revolution with Galileo and Descartes. Since then, the triumphalist faith that science would provide the good and the true has put ignorance to one side, and led scientists to the sin of pride in their scientific conquests.” 1


We know some thi
ngs pretty well. For example, we know we need to test software. We also know we can’t find all the defects in software. We know where we have missed defects in the past.

The problem is, when we tackle something new, the rules change and no one is there to tell us what the rules are and how others play to the rules or cheat the rules. The risk comes into play when we ignore that fact or minimize it.



I find much of the programming on television to be lacking, but sometimes I do get hooked on a show. One “reality” show in particular, “Gold Rush” on the Discovery channel, has grabbed my attention. This show demonstrates the unknown unknowns very well.

Looking for Gold in All the Wrong Places


Gold Rush Alaska ” is about a team of rookie gold miners who go to Alaska to find gold. The oldest member of the team tried many years ago to find gold, but that’s about all the experience that exists on the team. It seems that at almost every step in their gold finding effort, they discover what they didn’t know.
The first hurdle came when they had to drive their main earth mover through a wide river because the bridge was too old and weak to handle the weight. Then came the time when they called in a gold mining expert who showed them how their dirt washer was letting much of the gold pass right out the exit and into the river. Once again, an “unknown unknown”. There were also dozens of other things these guys learned and are still learning. I admire their tenacity and faith. I hope they succeed before they run out of money and hope.

It is often said that “Beginners make dumb mistakes.” I prefer the way that Jerry Weinberg says it instead – “Beginners make beginner mistakes.” That’s a good thing for us software people to reme
mber.

Phases of Realization


I have observed that people tend to go through phases when faced with a new situation:


1. Cluelessness (Blissful ignorance)


At this level, people are so unaware of their situation and risks, they “don’t know that they don’t know what they don’t know.” This is total cluelessness, but also very common. It’s like deciding to build a house without really understanding all the problems and stress. It’s very exciting at first to be thinking of your dream home, but then the decisions arise, delays are encountered, things may be done incorrectly and so forth. Ask anyone who has ever had a house built and they probably have a list of ten or more major things they would do differently. One of those things might be “not to have a house built.”


2. Curiosity


This is where you have enough
objectivity to at least ask, “What are we missing?” You try to analyze and plan as much as possible, but it’s still only partial understanding of the possibilities. It’s much like going on a trip, thinking through all the clothes you will need, only to learn that the weather at your destination is much different than what you expected it to be.

3. Cautious awareness


In this phase, you are aware of the possibility of that “unknown unknowns” exist. You try your best to anticipate the unknown, but you hit the wall everyone hits. That is, you can’t prepare for everything. You might also think of this as “risk acceptance”.


4. Contingency planning


Realizing that you c
an’t prepare for everything totally, you put in place reserves to account for the unexpected. These are your Plan B, C and D for dealing with the unknown. In fact, some of the contingencies may seem totally outrageous.

In Oklahoma, where I live, most people have some type of tornado precautions and contingencies. Not so much for earthquakes until this week. Last Saturday evening, November 5, 2011, about 11 P.M. we had a 5.7 earthquake in central Oklahoma. In the past year, we have had a sharp increase in earthquakes. It’s odd to think that I have experienced more earthquakes in Oklahoma than I did while working nine months in San Francisco a couple of years ago! Sure, we’re small time compared to other places, but I’m thinking that more Oklahoma businesses are thinking about earthquake drills. 2


5. Confidence

Now that you understand the risk of the unknowns and have some back-up plans in place, you start to feel more confident in your ability to succeed. However, it is a false level of confidence in the contingencies.


Next to the early phases of cluelessness and curiosity, this may be the most dangerous phase because it easy for us to think we know more than we actually do know. We think, “Don’t worry, we have contingency plans in place.”


This reminds me of the time many years ago when one of my clients needed to restore the main database to recover from a power outage. Then they learned that the operator had failed to mount the second tape during the backup process. For some reason, the operator had misinterpreted the message that prompted for the next tape. This had been going on for months!


6. Comprehension


There is an old adage about judgment and experience. “To avoid mistakes, you need to have good judgment. To get good judgment, you have to make some mistakes.” Comforting, isn’t it?


There are two basic ways to learn: From your own mistakes and from other people’s mistakes. The good thing about learning from other people’s mistakes is that you avoid their pain. The bad thing is that we tend to observe these mistakes and think, “Oh, that not going to happen to us.”


A good thing that happens in this phase is that people may have the foresight to get an external opinion. This would have really helped the gold miners early on.


7. Calibration

Once you have asked the key questions, developed some contingencies, and reached out to others, you are ready to make adjustments. The question is, what will those adjustments look like?


Another bit of wisdom I learned from Jerry Weinberg is the “
Hudson Bay Start.” Back in the days of the Hudson Bay Trading Company, when the Canadian frontier was being settled, part of the plan was to travel west for one day. Then the next day, they would go back to the start and pick up the things they realized they missed the first time.

This is why I like pilot projects with low risk. You get a chance to learn what you don’t know. You can make mistakes without a lot of the downside risks.


It’s important to understand in this phase that the risk of the unknowns still exist. Going forward, you have to rely on your ability to adapt to new challenges and find a way to overcome them. This is where all of your experience and wisdom are needed.

8. Compilation and completion


It’s amazing how quickly we forget things. A good practice is to actually write down the things you learn and review them from time to time. My own practice for this is to keep a journal of the important lessons I experience. I may experience a lesson several times before I really “learn” it.


As someone has said, “All lessons will be repeated until learned.” I don’t know who said that, maybe I read it on a bum
per sticker. But, I know it’s true.

Albert Einstein is often quoted, “Insanity: doing the same thing over and over again and expecting different results.”

My point here is that if we don’t learn from our mistakes and omissions, then we deserve the pain from them.

I’ll admit that achieving this kind of learning at an organizational level is
difficult and rare. This is not about sponsoring training programs – it is much more experience-based than training. I think this level of learning must be personal. Organizations and institutions don’t learn – people do. It takes individuals to think, reflect and change their behavior.

What Can We Do?


This is the troubling thing about the unknown unknowns. You never totally mitigate this risk. However, there are some things we can do that may or may not help:

  • Stay humble and recognize that unknown unknowns exists.
  • Be flexible and adaptive when mistakes and problems occur.
  • Learn from yourself and others.
  • Reach out to others to ask questions before you embark on something new.
  • Keep a record of things you learn.
  • Have contingency plans and resource reserves, just don't place total trust in them.
Summary

The recent master of the concept of the unknown unknowns is Donald Rumsfeld. Unfortunately, people failed to follow the message and it was the brunt of jokes.

Here is how he stated it, transformed into poetic form:

The Unknown

As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,

The ones we don't know
We don't know.
—Feb. 12, 2002, Department of Defense news briefing

Here is a challenge for you. Check out the blog youarenotsosmart.com written by David McRainey. He has recently published his blog as a book titled, You are Not so Smart. It’s an interesting read. The premise as stated on the blog: "The central theme here is that you are unaware of how unaware you are. There is branch of psychology and an old and growing body of research with findings that suggest you have little idea why you act or think the way you do. Despite this, you create narratives to explain your own feelings, thoughts and behaviors, and these narratives become the story of your life."


I hope this article helps us all to realize the inherent risk of the unknown unknowns. I would like to hear your comments. How have you seen this risk?

1. Jerome R. Ravetz , “The Sin of Science - Ignorance of Ignorance”, Science Communication, September 2011
2. In fact, as I am writing this article, we experienced an F4 tornado and 4.7 earthquake within just a few hours of each other on November 7, 2011.