Giving the Customer a Little Extra

It's 108 today in Oklahoma City, so I find myself blogging, working indoors, and playing some guitar.

I had a revelation awhile back at Five Guys Burgers. I know, for many people, revelations happen in church, during a sunset, etc. Mine happen while I'm stuffing my face.

If you have ever eaten at Five Guys, you know the throw an extra handful of fries in your bag on top of everything. There's a good chance you may get full on the fries before you ever reach the actual container of fries. This got me thinking about why they did this. Then it struck me, this is a Purple Cow. How many other fast food places do that?

In contrast, I got a burger and large fries from one of our local chains (Braum's) recently. When I looked at the fries, I could count them. There were 15 I think. Plus, they were those frozen ones, unlike Five Guys which are cut in the store (like In-n-Out).










It probably costs five cents or less to throw in the extra handful of fries. In return, Five Guys gets loyal and raving customers. I've never seen an ad - print, TV, web, anything, but I've talked to many people who brag on them.

So, what's the attraction? What makes the difference?

Isn't it nice when you get more than you expect, not less?

This is our new Five Guys in Moore. Someone apparently thought it was a drive-in.










It's sad that in our society, people are cynics about deals. I see this all the time in dealing with our customers at Rice Consulting. I quote a price and people ask, "What's the catch?". It's simple. There are no catches.

For example, I give 12 months for people to finish an e-learning course. Most of our competitors give 90 days. If someone needs more time, I always extend the time to take a course.

After a class, I'm always available to answer post-class questions for free. During an e-learning class, I always answer questions as part of the class fee. After a consulting engagement, I always answer post-engagement questions.

In the past weeks, here are some other great examples:

We bought a 2010 Ford Explorer recently from Reynolds Ford in Norman, OK. I didn't haggle on the price, bought the extra protection package, got Ford financing, the works. The whole process took a little over an hour and went as smooth as silk. Our salesmen, Brent was helpful, friendly and knowledgeable. Then, I discovered there was only one set of keys. So, I called Jayna at the dealership for an extra set since they cost about $200 these days for the chipped keys. When I picked up my car from the service area, they had an extra set of keys for me. Oh, and when we took possession of the car, it had a full tank of gas, was washed and the tires were glossed. That's extra for the customer and I'm a fan now. Reynolds Ford knows the value of a lifetime customer is more than $200.

Today, I bought two pounds of coffee at a Starbucks in Norman. The barista offered me a free cup of coffee. Even at 108 degrees out, I accepted. Let it never be said that I ever turned down a free cup of coffee. As James Garner (a Norman native) said in Support Your Local Sheriff, "I never turned down a cup of coffee in my life."

I have actually asked for a free cup of coffee when buying several bags of coffee at other Starbucks and the response was "Sorry, we don't do that anymore." That left me unimpressed. I'm much more inclined now to buy from the Norman store.

There used to be a time when giving a little extra to the customer was common practice. Now it seems that the trend is to reduce the product and charge the same. I believe that's a short-sighted approach.

It appears to me that giving added value is the result of both good policy (that's the role of management) and good performance (that's the role of the person delivering the service.)

At Five Guys, their corporate policy is to top off the fries. At Braum's, their policy is to not under any circumstances exceed the size of the container.

In other cases, like at Reynold's Ford and Starbucks, it's the performance of the right people making the right decision by the customer.

In software testing, we need to be showing our added value. One way to do that is to give a little extra to your customers. Be helpful to them. Ask what they need. If they don't know what they need, help them see the possibilities.

Some people see their customers as "those which must be endured." For sure, there are challenges. I choose to see my customers as the reason I'm in business - to serve and to stay in business.

You may not have a "business" but I suggest that you have many of the same reasons to please your customers. Without them, you wouldn't have a job.

OK, enough for now. I'll go practice Black Dog (Led Zeppelin) and Bach Cello Prelude 1. What can I say? I have a wide range of musical tastes!

Have a great weekend!

Book Review - Documenting Software Architecture, 2nd. ED

Authors: Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford

Addison-Wesley, 537 pages

As a software tester, I rely heavily on system documentation. Unfortunately, documentation is often missing, obsolete, or never created in the first place.

Also, I have a great appreciation for software architects and the work they produce. As a former developer, I used to struggle with the best ways to express system architecture diagrams. After all, there are so many methods available to document systems – UML being a major one, but there are others.

When I started reading this book, I was struck by its practicality, beautiful simplicity, and integration between authors. Everything I read in this book is written in a clear and understandable way. The authors understand that different audiences will read this book, so they give graphical (of course) guidance in which chapters are most applicable to architects, stakeholders and novices.

This book covers the basics, such as module views and module styles, component and connector views, allocation views and styles.

Part two of the book goes beyond the basics and gets into issues regarding levels of detail, deciding among alternatives, documenting interfaces and documenting behavior. Part three is devoted to building the architecture documentation.

There are appendices devoted to UML, SysML and AADL to show how architectural documentation is shown in each of these.

It would be tempting to say that this book is needed for new technologies, such as SOA and the cloud, which is true, but too narrow. Actually, this book can be applied to any technology or approach – traditional, agile, iterative, or anything. That’s because the one thing people ask for and struggle with is documentation. This is especially true for architectural documentation.

Read this book and apply the things in it and you will stand out on projects - in a good way. And, of course, that’s a good thing!

Test Automation is Not Automatic

Recently while teaching a workshop on Testing Dirty Systems, I uttered this “Randyism” off the top of my head, “Test automation is not automatic.” I realized immediately that I had just concisely stated the problem in making test automation a reality in many organizations.

Most testers know that test automation is not automatic. (Wouldn’t it be great?) However, management many times does not know or accept that reality.

There are some test tools, such as unit test tools, that are practically automatically applied. My remarks in this article are aimed at the capture/playback and scripting tools for test automation.

The issues are that:

1) Not every test can or should be automated

2) For those tests that can be automated, it takes time and effort to build the automation

3) For those tests that have been automated, the tests must be maintained

4) It takes time to lean how to use a tool

5) It takes effort and planning to implement a test automation framework

None of these are automatic, even with the best of tools.

Not Every Test Can or Should be Automated

Think about the things you test that are not very repeatable. Or, they may be prone to constant change. Perhaps the things you test are developed in a technology that has little or no tool support.

Then, there are tests such as user acceptance tests that need people’s evaluation to judge acceptance.

Some tests require creativity and adaptation to perform. You may have to make judgments during the test, which may be too complex to describe in a script. Test automation leverages the mundane testing to give more time and attention to the unique tests.

Your job is to identify the tests that can be automated. (They don’t come labeled!) Then, you must understand the nature of the test, such as the pre-requisites, the steps to perform it, the exceptions and where to find the expected results. None of this is automatic. It’s all test design and test implementation.

For Those Tests That Can Be Automated, It Takes Time And Effort To Build The Automation

It’s one thing to automate a function, but another to design a good test of the function. That’s why capture/playback is so appealing, yet lacking. The issues are: What are you testing in the capture session? Then, how can you extend those tests to add value?

You have to apply approaches like data-driven testing and keyword-driven testing, which take time and effort to understand and implement. These are not “out of the box” deliverables.

For Those Tests That Have Been Automated, The Tests Must Be Maintained

This has been one of the consistent issues in test automation. There are things you can do to ease the maintenance burden, but it doesn’t do away with the issue.

For example, modular and reusable test scripts are very helpful in reducing the number of tests that must be maintained. Still, you must maintain the scripts you have.

This means you must know when the application has changed, what the changes were, and create new tests for those changes. This implies the presence of configuration management and traceability.

It Takes Time To Lean How To Use A Tool

Of course, the learning curve varies by tool, but the fact remains that a tool with sophisticated features will take some time to learn. The learning curve also varies by person. Some people with deep experience in automation may be able to learn very fast, but when you consider the wider deployment, most people will fall on the lower end of the experience scale.

The time also varies by the approach used to get training. Some people try self-learning which is noble, but typically takes longer than classroom training. Mentoring from an experienced person may be the best approach.

You must assess your organization’s skills and abilities to know even if mentoring will help. The best mentor in the world can’t help the person who isn’t ready to learn. Is that another “Randyism?”

It Takes Effort, Money And Planning To Implement A Test Automation Framework

The framework can take a variety of forms, but the context here is the organizational framework which provides a way to efficiently build and control test automation. Tools are only one-third of the picture. You also need processes with trained and motivated people to make everything work together.

Out of the box, tools are just software. A process framework helps with reuse and the maintenance of test automation.

Frameworks aren’t automatic, either. They must be adapted to fit each situation, therefore they require time, effort and funding to design and implement.

Conclusion

This article is certainly not an in-depth treatment of this topic. Entire books and training courses have been written to address these and other aspects of test automation.

I hope this expands on my simple statement “Test automation is not automatic” to provoke your own thinking on this reality.

For over twenty years now, I have seen a wide variety of test tool companies promote their tools as being effort-free, script-less, or however they choose to position their products. The evidence shows these are often empty claims. Just compare the numbers of people who have been successful in using test automation tools to those who have given up using the tools. It’s about 25% successful to 75% unsuccessful in my research.

I hope this article is an encouragement to those who have tried to implement test automation as well as to those who haven’t. It’s important to go into these projects with your eyes open and expectations at a realistic level. Once you get past the idea that the tools do all the work, you can do the planning and other work needed to increase your chances of success.

Test Manager Workshop with Randall Rice and William Perry

Name your software testing challenge and other test mangers and the workshop faculty will give you solutions!

As a software test manager, you face pressure from all directions. Customers expect high-quality products, project managers want to get the projects delivered on time, your management expects you to do more with less, and your team needs your leadership.

You could take a class in software test leadership or management, but much of the knowledge comes from the front of the room. What if you could determine the topics based on your own needs?

This is not a class or a conference, but a highly interactive and personal event. You will spend time personally with William Perry and Randall Rice to discuss your specific testing needs.

You need a mentor! Personal mentoring is one of the most effective ways to get guidance and build knowledge. Mentoring fills the gap that training cannot fill by giving you face-to-face, personal feedback about how to deal with tough issues.

In this unique opportunity, you can spend two days with two respected test management consultants, William E. Perry and Randall W. Rice to gain insight and solve your specific testing problems. Perry and Rice literally wrote the book on people issues in software testing. William E. Perry has written over 30 books on software testing and quality assurance. They share over 80 years of professional software quality and testing experience in world-class organizations.

Any and all topics are on the table. As an example, some of the topics suggested by test managers are:

• People issues in software development and testing
• Testing large and complex legacy systems
• Testing SOA and cloud-based applications
• Test metrics and measurements for showing your value
• How to grow as a test team leader
• How to communicate your value and your team’s value
• How to grow your team
• Test tools and test automation
• Software QA processes
• Software forensics
• Testing internal controls
• Testing information security
• Applying statistical methods to software quality
• Gathering and defining testable user requirements
• Managing expectations
• The Ins and Outs of software test certifications
• Any topic of interest to you!

However, the final topics will be determined by the attendees during the conference. That ensures your topic will be discussed!

You will leave this event with confidence and knowledge in how to best approach your situations.

Location – Orlando, FL (exact venue to be announced later)
Dates – Thursday, October 27 and Friday, October 28, 2011
Cost - $1,295 per person

Seats are limited, so reserve yours early to avoid disappointment.

Bonus Option!

Attend one day earlier to have an extra opportunity with Randy and Bill to learn how to test dirty systems.

The day prior to the workshop, William Perry and Randall Rice will be conducting a one-day interactive workshop based on their new book, Testing Dirty Systems. In this workshop you will learn:

• How to apply statistical process control (SPC) to software development and maintenance
• How to acquire system knowledge
• How to plan and perform the testing of large, complex and undocumented systems
• How to measure and report the test results in value-added ways
• How to use test results to clean a dirty system

Location – Orlando, FL (exact venue to be announced later)
Date: Wednesday, October 26, 2011
Cost - $550 per person if attended as part of the two-day Software Test Managers’ Workshop, $690 if attending only the one-day event.

Click here to register.

Click here to ask any questions.

Credibility

For those of you who have been in my tutorial Becoming an Influential Test Team Leader, you know I'm big on the topic of credibility. If people don't find you credible, they don't find your information credible either. So, credibility is huge for testers and test leaders.

Today, John Maxwell's "Leadership Word of the Day" is credibility. He has a nice one-minute video and you can also sign up to get these free at:

http://johnmaxwellteam.com/credibility/

If you want to view my 45 minute conference presentation on credibility, you can find it here:

http://softwaretestingtrainingonline.com/moodle/course/view.php?id=30

(When asked for a login, you can click the button that reads "login as a guest".)

I hope you listen to one or both of these and think about what it means to be credible as a person, a leader and a tester.

Have a great weekend!

Randy

Ten Proven Ways to De-Motivate Your Team

Thanks everyone for your kind words about my lightning keynote today at StarEast.



Here is the complete script:

10. Set unreasonable “stretch” goals just to see how hard people will work.

It really doesn’t matter what the goals are, or what the deadlines are, just make them really hard to achieve. If you really want to wear people down, do this at least once every 3 months. Overlapping stretch goals are especially fun.

9. Never explain your rationale for decisions.

Reasons? You don’t need no stinking reasons! “Because I said so” works just fine. In fact, it’s good mental exercise for your team to try to figure out your irrational actions.

8. Assign meaningless tasks.

The most important thing about work is that people look busy at all times. Whether it’s writing a PowerPoint presentation for you to impress your boss, or just to test until 6 in the evening, make sure everyone always looks busy.

7. No matter how good something is, criticize it.

Especially the first time you review it. Get a nice, big, red marker and go crazy. Forget about the main point of the content and focus on sentence structure or specific words you don’t like (such as “the” or “that”). Before long, people will give up and stop trying to make something right the first time.

6. Take all the credit for yourself.

After all, this team is your creation, right? This is especially important to remember at bonus time. Otherwise, you may have to suffer financially. (Don’t forget to attend all senior management meetings alone.)

5. Solve problems by building a new bureaucracy.

Remember, there are no simple solutions, only simple people. You are a much more complex person than that. You can design forms, approval processes and even spreadsheets. Of course, once you implement this required bureaucracy, you need to police it some way, so you will need a special team of spies to make sure everyone follows the “new way of doing things.”

4. Listen…like a brick wall.

The trick is to make people think you are listening. So, look them right in the eye, nod approvingly, but let your mind roam. Then, you can fulfill all your ADD fantasies. NBA scores, weekend plans, lunch plans….you name it.

3. Refuse to consider ways to do the job more effectively.

Tools? We don’t need no stinking tools, either! Besides, we can’t afford all those fancy tools. Free tools? We can’t use those – we do have rules to follow, you know. Training? We had a class 5 years ago. Can’t you people remember anything? Learn at lunch? Heck no, your team is too busy working through lunch. (See point #8 – always look busy.)

2. Treat your team like they are machines that should never break down.

I mean really. Why do these people call in sick and let you down when you least expect it. Who’s going to write your status report? And don’t even get me started about bathroom breaks!!

1. Never, ever, in any circumstance, give anyone praise or recognition.

Otherwise, people would start to feel hope and happiness, like when we saw all the teenagers leaving for home today. Remember, if you never praise anyone, you don’t have to insult them, just ignore them. Eventually they will leave and you can hire someone else to de-motivate.

StarEast 2011 - Free and Cheap Test Tools

Thanks to everyone who attended my half-day tutorial today! Here are the tools that were mentioned by people in the session, plus a few more from me:

Axiom - Requirements Management tool - http://www.iconcur-software.com/solutions.html

Dia (Visio alternative, helpful for drawing process flow diagrams, etc for test planning) - http://live.gnome.org/Dia

Gliffy (a web-based diagramming tool) http://www.gliffy.com/

Shapes - Shapes is a simple, elegant Diagramming app for Mac OS X Snow Leopard. http://shapesapp.com/

FreeMind (Mindmapping, useful for test design) - http://freemind.sourceforge.net/wiki/index.php/Main_Page

Runtestrun.com - Test case management

Sikuli - Sikuli is a visual technology to automate and test graphical user interfaces (GUI) using images (screenshots) - http://sikuli.org/

IcuTest - GUI Unit Testing for WPF - http://www.nxs-7.com/icu/

Selenium Grid - Selenium Grid transparently distribute your tests on multiple machines so that you can run your tests in parallel, cutting down the time required for running in-browser test suites. http://selenium-grid.seleniumhq.org/

eggPlant - Image based test automation - http://www.testplant.com/

TestRail - Test Management - http://www.gurock.com/testrail/

InCtrl - By monitoring the changes made to your system when you install new software it enables you to troubleshoot any unexpected problems that come up. http://www.pcmag.com/article2/0,2817,25126,00.asp

Paloma Print Perfect - STREAMDiff - Comparison of PDF docs - https://www.palomaprintproducts.com/STREAMdiff/printPerfect.asp

Skitch - Screen capture, crop, resize, sketch (Mac) - http://skitch.com/

TimeSnapper - Take screenshots automatically in background as you test - http://www.timesnapper.com/

VM Ware and MS Visual Studio 2011 Test have record features.

Snagit - Screen capture - http://www.techsmith.com/

BrowserMob - Cloud-based performance testing and monitoring - http://browsermob.com/performance-testing

WebTrends - web monitoring and analytics - http://www.webtrends.com/

Presently.com - allows individuals to post short, frequent updates that are tracked or "followed" by others. Unlike Twitter, Present.ly provides a secure and private way to share updates among members of a company, without them being visible to the outside world.

Sharepoint - www.microsoft.com

Skype - www.skype.com

Fluid - lets you create a Real Mac App (or "Fluid App") out of any website or web application, effectively turning your favorite web apps into OS X desktop apps. http://fluidapp.com/

Fake - Fake is a new browser for Mac OS X that makes web automation simple. Fake allows you to drag discrete browser Actions into a graphical Workflow that can be run again and again without human interaction. The Fake Workflows you create can be saved, reopened, and shared. www.fakeapp.com

TeamViewer - You can remote control your partner's PC as if you were sitting right in front of it. http://www.teamviewer.com/en/index.aspx

Logmein.com - Remote PC access. Free for up to 2 computers.

Joinme.com - Screen sharing

IE Tester - IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE10 preview, IE9, IE8, IE7 IE 6 and IE5.5 on Windows 7, Vista and XP, as well as the installed IE in the same process. http://www.my-debugbar.com/wiki/IETester/HomePage

Thanks for all your input!

Randy

Minnesota Taxpayers to Foot a $7.25 Million Bill for a Failed Software Project

For many years, when software projects failed, the vendors almost always had to pay up big time. Well...it looks like the taxpayers in Minnesota are getting stuck with a $7.25 million bill on this one. Why? Basically, the judgment was that the state also contributed to the failed project. Get this..."The payment will bring HealthMatch's total cost to more than $41 million, a department spokeswoman said. The original budget was about $13 million"

You can do a LOT of process improvement and optimization for $41! However, that's all seen as "QA stuff".

I really feel for the people of Minnesota on this one. But, I've seen this happen far too many times. The problem is that software projects are not performed in a vacuum. A vendor goes into an organization to work "with" the people, not "for" the people. So, if the organization is dysfunctional, so will be the project. The reality in this case (as I understand it) is that there were shortcomings on both sides. However, what often happens is that both sides get sucked into a death spiral. Neither can afford to leave, so they keep thrashing until the money runs out and/or someone decides to pull the plug.

Read more at Computerworld.com.

Abbott & Costello Meet Microsoft Outlook

I found this on Computerworld's Shark Tank and thought about the old "Who's on First?" bit. It's also a great example of trying to understand the users' true needs and expectations of software.

"He (Big Boss) wanted me to help him understand how Microsoft Outlook calendar appointments work with changing time zones," says fish. "I updated the online docs, then walked down the hall for the explanation to the big boss."

But as soon as the big guy hears the explanation -- how Outlook will automatically reflect the time-zone shift when the clock is changed -- he tells fish, "No, that's not what I need. I need to be able to set an appointment up for a certain time slot in the other time zone for next week, but then appear in the same time slot when I look at it with my PC set to my current time zone, this week.

"If I set it for 2 p.m. there, then it needs to show up as 2 p.m. on my calendar when I look at it from here, but for next week.

"And I want everyone else invited to the meeting to see it correctly when viewing both here and in the other time zone. And, oh yeah, it needs to show the correct time slot on my smartphone calendar, and on all the attendees' smartphones, next week when we're traveling."

Fish scratches his head and then attempts to explain that an appointment set in the other time zone will always appear in a different hour time-slot when viewed from a device set in the current time zone, and that it all depends on the time and time zone set on the device.

Big boss says, "No, you're not getting what I need. I need to be able to set an appointment up for a certain time slot in the other time zone for next week, but then appear in the same time slot when I look at it with my PC set to my current time zone. I can't believe that there isn't a way built into the software to do this!"

Reports fish, "I tried to explain it one more time, but in the end the big boss looked back with glazed-over eyes and said, 'Well, since the technology can't help me, I'm just going to print out my calendar and carry it with me to the other time zone.'

"Then he proceeded to print out next week's calendar on paper."

Book Review - "Glitch - The Hidden Impact of Faulty Software"

I have a great interest in the topic of software defects, their impact and how software failures happen. Books in the past such as "The Day the Phones Stopped", "Bad Software" and "Fatal Defect" have been great sources of documenting what has gone wrong due to software defects. These books serve as case studies for anyone who is involved in creating, testing or buying software products.

So, I was excited to see that a new book has been written on the topic. I'm not crazy about the title of "Glitch" because it tends to convey that a problem is minor. We see this a lot in the popular media as major system failures are described as glitches. I think the problems that Papows describe in this book are more than minor ones. Setting the title aside, I was happy to see a very recent accounting of computer failures in many domains - financial, government, medical, etc. Of course, I'm not happy for the problems, but it's good to see recent information.

This book is written at a level that non-technical people can understand and technical people can read without feeling insulted. That's a nice balance. The information is also sourced well. When it comes to reporting about failures, there are ten sides to every story. But having some objective sources is helpful.

To me, the strongest chapter was Chapter 8, "The Way Forward." In this chapter, Papows (who was the former President and CEO of Lotus Development) describes what organizations and individuals can do to help reduce the risk of computing failures. This is the only place QA and testing are mentioned in the book, which was a little disappointing to me, but I come from a biased perspective. I think people need to understand the project management reality of rushed deadlines, skimpy testing and lax attitudes toward quality to truly understand why software fails. This book gets into that to some degree, but not very deeply.

In fact, much of the book is written from a top-down perspective as opposed to an "in the trenches" perspective. I was hoping for a more detailed analysis of why some of the problems happened.

I can recommend this book to business managers to raise awareness of software risks and to software quality professionals who need good examples of past failures to make the case for better software development and testing processes. However, it may disappoint those looking for root cause analysis of software defects.

Six Seats Left for Test Automation and Test Team Leadership Training in Salt Lake City - Jan 25 - 27, 2011

I just wanted to get the word out to anyone that is in the Salt Lake City area, or who may be able to travel there, that I have six seats open for two great workshops:

Practical Software Test Automation (Tues & Wed, Jan 25 & 26, 2011) - Learn hands-on techniques and approaches for building an efficient test automation architecture. We get into scripting and test tool integration. Bring your notebook computer!

Becoming an Influential Test Team Leader (Thursday, Jan 27, 2011) - This is an interactive workshop that will help you bring out the best in your test team. If you are a test team leader, or aspire to be in that role, this workshop will help you influence your team and those you interact with.

These two workshops are at special pricing for the Salt Lake City QA Focus Group, but I am extending that pricing to everyone! $750 for the Test Automation 2-day workshop (normally $1,400) and $375 for the 1-day Test Team Leadership workshop (normally $790).

The workshops will be held at The Pavilion Inn - http://www.slpavilioninn.com/

To see details and to register, just visit https://www.mysoftwaretesting.com.

Register soon to save your place! I hope to see you there!

Randy Rice

Tiger Woods Needs a Golf Teacher?

On my last trip to Rome, while flipping the two English channels in my hotel room, I happened to catch a story on CNN about Tiger Woods and his need for a new golf teacher/coach. This fascinated me.

Now, I’m not a golfer so that explains some of my curiosity about why one the world’s greatest golfers would need a teacher. In fact, Tiger is arguably the best golfer in the world today, although in tough times right now. I don’t even watch much golf on television, so I’m really a neophyte.

Tiger’s most recent coach was Hank Haney, who coached him from 2004 to May of 2010. Haney resigned because he felt he had taken Woods as far as he could.

http://www.cnbc.com/id/37192697/Instructor_Haney_Explains_Parting_Ways_With_Tiger_Woods

But still, I kept thinking, if the world’s best (or at least in the top five) needs coaching, what does that say about the whole concept of personal improvement. How does that apply to what testers do?

After thinking about this, I started to see some reasons why even the best in what they do need a coach, teacher, or mentor.

1. Objectivity

We all need someone who will tell us the truth, no matter how ugly it may be. And, they need to be able to do that from an external and unbiased perspective. True, a golfer can have a video camera and other ways to capture their golf swing, but it takes a lot of experience and insight to see the one little flaw that can increase a score.

Tiger probably has lots of people he can ask for opinions, and most of them will tell Tiger what they think he wants to hear. I find managers like this all the time. They can’t get the real story because so many people are either afraid to give bad news, or they are people-pleasers.

2. Broad context

Hank Haney has coached thousands of golfers, and also many golf pros. He has seen more bad swings than just about anyone. He has also seen the best. He knows what makes a difference because he has seen the techniques work in practice. Haney understands the mental aspect of golf as well.

3. Accountability

If you want to improve at anything, you have to practice and take positive action. Things that are easy to do are also easy not to do. A coach or mentor can ask you if you are on track doing the things needed to improve. They can’t make you do things, but they can remind you of your goals.

4. Encouragement

Everyone needs encouragement. Encouragement is interesting because it comes from others. You can have affirmations and self-talk, but a little encouragement from someone does so much more than what you can muster up yourself.

The Results

The results of these things are motivation and improvement. You’ll notice that I didn’t include either of these in the list the coach brings. These must come from the one being coached. These are brought out by a good teacher or coach.

Likewise, desire and the choice to change must come from those wishing to improve.

Keep in mind that I’m not necessarily talking about large steps of improvement. Whether you’re at the top of the game or just starting out, one tiny change can make a world of difference.

What About Testing?

Since many of you who read this blog are software testers or involved in software quality in some way, here are some tie-ins to what testers do.

Objectivity – This is the value of independent testers. The reason testers are needed is that they have a fresh view of something. They can see defects that someone with a lot of familiarity may miss. However, some testers are fearful of giving the bad news. That’s why a good testing process with measurements and metrics is so important. The process can deliver the news, whether good or bad.

Broad context – Testers do best, I believe, when they have worked in different companies and on different types of projects. You may not have much control over this, but you can still explore and expose yourself to different things. You can read, attend conferences, and get training to broaden your horizon.

Accountability – Testers can ask probing questions like, “Has this code been reviewed?” or “Has the business user seen this requirements document?” If there are development and testing processes in place, testers can tell if those processes are being followed.

Encouragement – Testers can give more than the bad news of defects. They can also give credit for great work.

Doing It

I’ve been sitting on this article for two months. I’ve wanted to write it, but for some reason just could not get off the dime. Perhaps it was my own lack of motivation.

Then, this week I happened to be flipping through my “300 channels of nothing” on TV and came across “The Haney Project” on the Golf Channel. I had no idea what this show was about, but soon saw that it tied everything together for me. In this episode, Hank Haney was teaching Rush Limbaugh how to improve his golf game.

A couple of things that stood out to me were that 1) he told Rush to only think about one thing during his swing, not twelve, and 2) Haney was very encouraging. At the end of the program, Limbaugh remarked about how impressed he was about working with Haney. Unlike other teachers who had been negative and overbearing, Limbaugh found Haney to be supportive and positive.

When I watch TV, I like to watch programs that show how people can improve. I found this program very interesting just watching Hank Haney’s coaching style in action.

Oh, and after watching Rush play golf, I'm thinking, "Hey, I can do at least that good!" So who knows? I may actually dust off my garage sale clubs and hit the links.

The big take-away for me in all this is that we all need people around us to help us improve, to encourage us and to bring accountability. I encourage you to find someone who can be that coach to you or your team. If you need help in that effort, let me know.

I would like to hear your comments on this topic!

3 Ways to Stretch Your 2010 Training Dollars

As we wind down 2010 and look forward to 2011, you may be left with some training dollars in your budget. I know I try to make the best use of my money right at the end of the year. Here are 3 ways you can do that:

1. Buy e-learning courses. I have placed several of my e-learning courses on sale until December 31, 2010. The great thing is that you have 12 months to complete the course!

2. If you live in the Utah area, or even in that region of the country, you may be interested in two workshops I will be conducting there in January. These are on the topics of test automation and test team leadership - and they are deeply discounted.

For details on either of these, visit https://www.mysoftwaretesting.com.

3. Study groups are forming for ISTQB Advanced certification. These are 6 to 7 weeks in length to support self-study. They are held online and have live web meetings with me as facilitator. You can pay in 2010 and attend in 2011. To get more details on this, visit http://riceconsulting.com/home/index.php/Home-Page/istqb-advanced-study-groups-forming.html.

I am working on a jam-packed newsletter for January, so stay tuned for that.

Finally, I wish you a Merry Christmas, Happy Hanukkah, and a prosperous and healthy New Year. Thanks for your support this past year!

Warm holiday regards,

Randy

New York City Voting Machine Problems - Implementation? We Don't Need no Stinking Implementation Plan!

I've spoken out before on voting machines and the related quality issues which cause me concern. So, this article caught my eye. It seems that today in New York there were major problems (not glitches) in the rollout of new voting machines. One might think perhaps the cause was software or hardware related. However, upon reading the account, it seems that the problem was largely in the implementation.

$160 million spent and this was the result.

I like the "teachable moment" and this is one. It doesn't really matter how good the software if you don't have the hardware plugged in!

http://newyork.cbslocal.com/2010/09/14/new-yorkers-head-to-the-polls-on-primary-day/

Do You Test SaaS, Or Does SaaS Test You?

Imagine you are sitting at your desk one morning and your phone rings. It's not your boss - it's your boss's boss, the CIO. He's upset because the online sales database is down and the entire sales staff is paralyzed. "The sales software is broken!" he exclaims. Then he asks, "Didn't you test this?" You take a deep breath and say, "No, that software is a service we subscribe to. We have no way to know when it changes." The CIO isn't happy, but now sees the reality of Software as a Service (SaaS).

I believe that SaaS is not a trend, but a major force that will shape the future of IT and, therefore, software testing. In fact, SaaS could dramatically change the way we think about and perform software testing from here on.

This article has a definite angle toward the risks of SaaS. I fully embrace the benefits and appreciate them. I use SaaS, as you will see later in this article. My point here is to point out the risks. Only you can weigh them against your own benefits.

What's Different?

1. You have little or no control over the software, the releases, and any remedies for problems.

In some cases, you may get the choice of when to accept an upgrade. However, even when you are on a specific version of the application, the vendor may choose to make a small change without advance notice.

In other cases, you may come in to work and notice that things on the application look a little different. Or, you get the dreaded phone call that something is broken.

But here's the real rub: Even if you isolate the problem and report it, you are still at the vendor's mercy to fix the problem.

At least with Commercial Off-the-shelf (COTS) software, you get the choice when to deploy it. So at least you get the chance to test and evaluate it beforehand in a test environment.

2. You have almost zero knowledge of structure, and often no knowledge of new and changed functionality.

Forget white-box testing, unless it is for customized interfaces (for example, APIs). Now, let's say you have noticed some functional changes. What really changed? What stayed the same? What are the rules? When are they applied? Many times, none of this is published to the customers.

Not only is SaaS a black-box, it is more like many black boxes, all in a cloud. Your SaaS application is most likely comprised of many services, each with their own logic. In fact, some of the services may be supplied by a vendor you are not even aware of.

3. There is no lifecycle process for testing.

In the past, we could test at various levels - unit, integration, system, and UAT. That's all gone with SaaS. It's all UAT. Sure, you can test low-level functionality and integration, but it's from the customer, not the developer perspective. In the lifecycle view of testing, your tests can build on each other. In the UAT or customer view, testing is a "big bang" event. So, forget "test early and often." That changes to just "Test often."

4. Testing is post-deployment.
There may be some exceptions in the case of beta testing, perhaps. But for most people, you get to see the software only after it is deployed. That's too late to prevent problems. All you can do is race to find them quickly. In other words, you are in reaction mode instead of prevention mode. Then, even if you find the problems before your customers do, they may not be fixed for some time.

5. Test automation is fragile (and futile).

You get no return on investment because ROI is achieved when tests are repeated. When a new version is released, there's a good chance your automated testware will not work. This means you are at risk of reworking your test automation at every release. That said, some people may find test automation of basic functions a way to monitor when changes have been made.

6. Test planning is also futile.

This is because there is little detailed knowledge about the application in advance of using it. There is no specification basis for testing unless you write them. Use cases might be effective for describing work processes supported by the application.

Is There Any Hope?

Yes, and it's called validation. Not validation in the sense of "all forms of testing", but validation in the sense of making sure the software supports your needs.

In Point #6 I mentioned use cases. This is a form of test planning you can perform. You can create test scenarios based on work flows you perform in your organization. However, you must not think in terms of software behavior. Instead, you must describe work processes that can be tested no matter which software is being used.

You can create use cases to describe work processes, not software processes. These can be used as a basis for testing. The flows are perfect for mapping test scenarios.

You can assess the relative risk of work flows to prioritize your testing. You can even use pairwise testing to reduce the numbers of combinations of test scenarios and test conditions.

However, only in certain situations will this help you avoid problems: 1) You are a beta tester or 2) you get to choose when to apply an upgrade.

There Will be Pain
You arrive at work on Monday morning and discover one of your SaaS applications has changed. You and your team scramble to test the high-risk scenarios (manually) and discover that many things are broken. You call the vendor only to learn that your wait time on hold is 30 minutes. You file issue reports and just get the auto-responder messages. Days go by. You keep trying, your manager tries calling, but hey, you're just one customer out of thousands. In many cases, there is no "Plan B."

This is the extreme end of the risk scale. Not all releases fail, and when they do fail, not all fail to this degree. However, the risk is real.

My Story

Just last week I experienced a problem that would have been very painful had it happened at a time I was teaching an online class. My online training services provider upgraded to a new version of the web presentation platform, but gave no notice. All they indicated was that the site would be down for maintenance on Friday evening. Turns out, they introduced a totally new and upgraded platform with several improvements. However, several key things failed: 1) I could record a session, but never get the file (I wasted an hour recording a session to find this out!), 2) I could not upload a file for presentation, 3) I could not install the new screen sharing software on Windows XP. There's not much you can do with web meeting software behaving like this.

I called tech support on Saturday. Guess what? Nobody home, even after a major release. I filed 3 problem tickets which as of this date have still not been closed out, even though the problems were fixed about 2 days later. (I did get one response.) I'm happy things are working now, but troubled about the way the release and post-release were handled. If I had been scheduled to teach an online class on Monday, I would have been stressed out for sure.

My case is fairly low-impact, but it did show me the risks of SaaS. I encourage you to keep these risks on your radar because like it or not, SaaS is in your future.

I would like to hear your experiences and ideas for testing SaaS, so leave a comment!

Software Test Automation Workshop in Oklahoma City - Sept 14 and 15, 2010

(This event has passed, but we offer an e-learning version, or will be happy to bring this training course to your company.)

I'm excited to announce we're holding the Practical Software Test Automation workshop in Oklahoma City on Tuesday, Sept. 14 and Wednesday, September 15, 2010.

The workshop will be held at the Hampton Inn, I-40 East (Tinker AFB) location at:

1833 Center Drive
Midwest City, Oklahoma, USA, 73110
1-405-732-5500

You can see the details (outline, pricing, etc.) and register at:

https://www.mysoftwaretesting.com/Practical_Software_Test_Automation_eLearning_p/pstaelearn.htm

GSA discounts are available for this workshop. Just contact me for details.

I hope to see you there!

U.S. To Train 3,000 Offshore IT Workers

I ran across this article in Information Week and I'm thinking, "What's wrong with this picture?" We have unemployed IT workers here in the USA and it seems that we are training people who will eventually compete with them for the few jobs that exist. By the way, there is an update that we will be doing the same thing in Armenia. Of course, this will all be done with borrowed money.

Some key quotes:

"Despite President Obama's pledge to retain more hi-tech jobs in the U.S., a federal agency run by a hand-picked Obama appointee has launched a $36 million program to train workers, including 3,000 specialists in IT and related functions, in South Asia. Following their training, the tech workers will be placed with outsourcing vendors in the region that provide offshore IT and business services to American companies looking to take advantage of the Asian subcontinent's low labor costs.

Under director Rajiv Shah, the United States Agency for International Development will partner with private outsourcers in Sri Lanka to teach workers there advanced IT skills like Enterprise Java (Java EE) programming, as well as skills in business process outsourcing and call center support. USAID will also help the trainees brush up on their English language proficiency."

I don't know. I've stopped asking "why?" Back when outsourcing became all the rage we were told that in a new service economy people would rise to higher level positions. Instead, these US IT workers are trying to find the best position they can in an economy where there is a race to the bottom in terms of pay.

I know there are job training programs here in the USA, but even trying to find the front door to those programs is difficult. How often do you see those advertised? And now even those programs are being cut due to lack of funds. I guess we need to pay for other training programs for people in...Sri Lanka, Armenia and who knows where else.

I would love to hear your thoughts on this.

The SaaS Performance Risk - An Example from Twitter.

Recently I was interviewed about application performance risks. The final question was, "What are some performance risks you see in new technologies?" My answer was the cloud computing and Software as a Service (SaaS) risk.

Actually, there are many risks and concerns in the SaaS model. This is not to say the model does not have value, even great value. It's just that there are things you need to know before adopting SaaS.

The basic idea of SaaS is that you use software applications that are developed, hosted and maintained by a vendor. You trust that the processing will be correct, fast enough for you, secure, easy to use, available, reliable, etc. However, you have no control over those things. When the vendor has a problem, you have a problem. That can be a rude awakening to people.

To illustrate the performance risk, I saw an article recently about the overload at Twitter:

http://www.computerworld.com/s/article/9179446/Twitter_s_tech_problems_take_a_toll_on_developers?source=CTWNLE_nlt_app_2010-07-22

Twitter has a huge challenge with extreme traffic spikes. Now, on the upside, this is not a national security type of application, and most of us Twitter users have gotten used to the "Fail Whale" picture and just say, "Oh, well...I'll tweet that later."














Then, other things happen:
















But there is a business impact to the companies that sell services interfaced to Twitter:

"'Twitter API issues in the previous weeks have been terrible for us," said Loic Le Meur, founder and CEO of Seesmic, which makes Twitter client applications for various desktop and mobile platforms. 'Users always blame Seesmic first since it's their primary interface to Twitter. It's extremely frustrating because there is nothing else we can do than warning users Twitter has problems. It is very damaging for us since users start to look for alternatives, which fortunately have the same problems, but damage to the brand is done,' he said via e-mail.'"

To be fair to Twitter, they've done a lot to improve reliability in recent years.

In a related story, from last week, I read on Bloomberg.com:

"Interest in the SaaS (software as a service) delivery model is growing to the point that by 2012, almost 85 percent of new vendors will be focused on SaaS services, according to new research from analyst firm IDC. Also by 2012, some two-thirds of new offerings from established vendors will be sold as SaaS, IDC said."

http://www.businessweek.com/idg/2010-07-26/idc-saas-momentum-skyrocketing.html

So, what does all this mean to you?

If you are considering SaaS as a major application delivery method, then be aware of the risks. In reality, there isn't a lot you can do during a SaaS failure. For example, you can't just call up the folks at Twitter and tell them to "get it fixed" (like perhaps you can speak with the developers in your own company).

Some of this goes back to service-level agreements (SLA), but no vendor I know of will guarantee 100% uptime. Even if they did, there are other risks, such as correctness, not typically covered in an SLA.

I wish I had a handy list of things to mitigate the risks, but every case is different.

I would be interested in hearing your experiences with SaaS and how you deal with the risks, so please leave a comment.

How to Create a Fear-Based Culture

Hi folks,

Here is a great blog post from The Next Level Blog by Scott Elbin. Those who know me, know I'm big on the human factors in software development and testing. A big part of that is culture. One of Dr. Demming's 14 points is to "Drive out fear." What does that mean? Well, here's seven ways NOT to do it. See if you recognize any of them. Have a great day!

http://scotteblin.typepad.com/blog/2010/07/seven-simple-rules-to-create-a-fear-based-culture.html

Practical Software Test Automation Course Now Available in eLearning!

I am excited to announce the release of my newest course, Practical Software Test Automation, in e-learning format.

This course focuses on the basics of software test automation and expands on those topics to learn some of the deeper issues of test automation. This course is not specific to any particular tool set but does include hands-on exercises using free and inexpensive test tools. The tool used for test automation exercises is Macro Scheduler.

The main objective of this course is to help you understand the landscape of software test automation and how to make test automation a reality in your organization. You will learn the top challenges of test automation and which approaches are the best ones for your situation, how to establish your own test automation organization, and how to design software with test automation in mind. You will also learn many of the lessons of test automation by performing exercises using sample test automation tools on sample applications.

I hope to see you there!

Click here to see the course outline.

Click here to take a demo. (You can login as a guest)

Click here to register for the course.