Just got back in from Tampa, FL where I conducted a private workshop there on SOA Testing. (BTW, thanks for those of you who were in the class for making it a good one!) It's quite a temperature change from the 70's to the 30's coming back home.
It is an interesting challenge to be both learning and teaching. Although I have been working with a variety of companies in SOA testing, some as early as 1999, even those companies are still learning. It's like many people (including myself) are on "the bleeding edge" of this topic. We're still learning as we go. I hope to be sharing many more lessons learned in SOA testing soon on this blog. I would also like to hear more of your experiences.
By the way, here is an interesting quote (not about SOA, but about learning while doing):
"You must learn in real time and in action. You cannot afford to wait until everything is perfect to go out and do what you want to do. If you wait for perfection to go out into the world and do big things, you're never going to get there - or anywhere else for that matter. Many people hold themselves back because they think they have to know everything about how to do something before they actually do it. This is not true. You can and should learn while doing."
Michael Port
If you are into testing SOA, tell others about my blog so we can all get into the discussion.
One big lesson I have learned in SOA testing is that when you go to the conferences, read the articles, etc., many of the approaches are oriented toward a particular vendor's toolset and/or methodology. While the tools are great in providing leverage in SOA testing, vendor stuff happens (like being sold, etc.), which can place your entire testing effort in limbo. Plus, not everyone has the deep pockets for the tools. At least there are open source tools like soapUI that can help.
And it's not only because of tools there may be a skewing of information. It may be the variety of opinions from many people as to what works and what doesn't. These opinions are shaped by many things - the business itself, technologies, people, etc. I'm not saying to disregard anything, just test it for yourself.
It would be much like someone doing a Google search on "software testing" and trying to build a test approach just from the wide variety of opinions and techniques. Take it from a guy who has been around for awhile in software testing that you still need to try, prove and adapt your own testing approaches.
When trying to make it up the learning curve on SOA testing, keep in mind that everyone is learning. As validation, just look at articles written 3 years ago on SOA and compare them to what is being written today. The approaches are maturing. What was important then may not be so important today.
One of the things I learned in teaching the class was a great tool/service called generatedata.com. This is a really cool web-based script that generates test data and lets you export it in a variety of formats, even in SQL commands. I plan to add this to my list of cheap and free test tools and also add a video tutorial soon. Thanks to Ronan Madjar for finding that one and calling it to my attention!
I look forward to continually improving and extending this course to bridge the gap between SOA development and testing. With your help, we can do it!
Friday, March 07, 2008
Wednesday, March 05, 2008
The Loss of Two Quality Leaders
I just want to post my comments on the loss of two people that have impacted my journey of understanding what software quality is all about.
The first person I'll mention is Rodger Drabick, the author of "Best Practices for the Formal Software Testing Process."
I had the pleasure of working with Rodger and learning from his vast knowledge in software quality. When I went to my first QAI software testing conference in 1989, Rodger had been speaking about software testing and QA for many years. After hearing Rodger speak, I truly realized how much I didn't know about software quality! I have always looked up to him as one of the people of which we stand on their shoulders to practice software testing and QA today. I will remember him as one of the foundational people in my career. I will miss him!
Rodger is survived by his wife, Karen, his mother, two daughters, three grandchildren, and his four siblings. An obituary is posted here: http://www.mountvernonnews.com/notices/12/11/03.html
The family suggests memorial contributions be made to the Juvenile Diabetes Foundation, 120 Wall St., 19th Floor, New York, NY 10005: https://www.jdrf.org/index.cfm
The other person was Dr. Joseph Juran, who passed away last week from natural causes at age 103. I didn't know Dr. Juran personally, but he also shaped my view of quality through his writings, and impacted the worldwide quality movement for many, many years. Dr. Deming quoted Juran often!
I was very inspired as I read the tribute to Dr. Juran's at http://www.juran.com/. At age 103, he was still making a contribution, working on another book and caring for his wife of 81 years, Sadie.
As quoted in the press release, "In 1937, Dr. Juran coined the Pareto Principle, which millions of managers rely on to help separate the “vital few” from the “useful many” in their activities. He also wrote the first standard reference work on quality management, the Quality Control Handbook, first published in 1951 and now moving into its sixth edition."
These men both ran the race well and they will be missed by many.
The first person I'll mention is Rodger Drabick, the author of "Best Practices for the Formal Software Testing Process."
I had the pleasure of working with Rodger and learning from his vast knowledge in software quality. When I went to my first QAI software testing conference in 1989, Rodger had been speaking about software testing and QA for many years. After hearing Rodger speak, I truly realized how much I didn't know about software quality! I have always looked up to him as one of the people of which we stand on their shoulders to practice software testing and QA today. I will remember him as one of the foundational people in my career. I will miss him!
Rodger is survived by his wife, Karen, his mother, two daughters, three grandchildren, and his four siblings. An obituary is posted here: http://www.mountvernonnews.com/notices/12/11/03.html
The family suggests memorial contributions be made to the Juvenile Diabetes Foundation, 120 Wall St., 19th Floor, New York, NY 10005: https://www.jdrf.org/index.cfm
The other person was Dr. Joseph Juran, who passed away last week from natural causes at age 103. I didn't know Dr. Juran personally, but he also shaped my view of quality through his writings, and impacted the worldwide quality movement for many, many years. Dr. Deming quoted Juran often!
I was very inspired as I read the tribute to Dr. Juran's at http://www.juran.com/. At age 103, he was still making a contribution, working on another book and caring for his wife of 81 years, Sadie.
As quoted in the press release, "In 1937, Dr. Juran coined the Pareto Principle, which millions of managers rely on to help separate the “vital few” from the “useful many” in their activities. He also wrote the first standard reference work on quality management, the Quality Control Handbook, first published in 1951 and now moving into its sixth edition."
These men both ran the race well and they will be missed by many.
Thursday, January 31, 2008
What is a Test Case?
I've been training testers for 18 years by now. The thing I've dealt with, struggled with, whatever...is that everyone seems to have their own interpretation of what a test case is.
I guess this is on my mind today because I had to sort through it all again in a class. Don't get me wrong - I don't mind the exercise, but it makes me wonder about where we are in the testing profession when there isn't even anything close to a common definition of a test case.
Sure, there's IEEE Standard 829, but even that definition can be taken many different ways and does not prescribe a format (not that I think it should dictate a format).
So, here's my point. Don't get hung up on the format you use, just make sure you understand why you are using it and that it meets your needs.
I use the format I do because I feel it has some distinct advantages both in manual and in automated testing. However, I'm cool with the fact many people will take one of my classes and still create test documentation in their own ways. Hey, whatever works for you is fine with me. I do think, though, that having a common set of test terminology has tremendous value for a test project and organization.
(By the way, I take the view that test cases are small, distinct tests that can be specified as inputs, predicted results, and a set of execution for each item to be tested.)
However, I would suggest that you take a look at how other testers in other organizations define test cases, why they use the definition and format they use, and if it might be helpful to consider adopting a different approach. Of course, if it ain't broke you don't need to fix something just to be fixing it.
Will we ever have a unified view of test cases as a professsion? I doubt it. Don't even get me started on test scripts, test plans, test scenarios, QA, QC...
What do you think?
Till next time...
I guess this is on my mind today because I had to sort through it all again in a class. Don't get me wrong - I don't mind the exercise, but it makes me wonder about where we are in the testing profession when there isn't even anything close to a common definition of a test case.
Sure, there's IEEE Standard 829, but even that definition can be taken many different ways and does not prescribe a format (not that I think it should dictate a format).
So, here's my point. Don't get hung up on the format you use, just make sure you understand why you are using it and that it meets your needs.
I use the format I do because I feel it has some distinct advantages both in manual and in automated testing. However, I'm cool with the fact many people will take one of my classes and still create test documentation in their own ways. Hey, whatever works for you is fine with me. I do think, though, that having a common set of test terminology has tremendous value for a test project and organization.
(By the way, I take the view that test cases are small, distinct tests that can be specified as inputs, predicted results, and a set of execution for each item to be tested.)
However, I would suggest that you take a look at how other testers in other organizations define test cases, why they use the definition and format they use, and if it might be helpful to consider adopting a different approach. Of course, if it ain't broke you don't need to fix something just to be fixing it.
Will we ever have a unified view of test cases as a professsion? I doubt it. Don't even get me started on test scripts, test plans, test scenarios, QA, QC...
What do you think?
Till next time...
Friday, January 25, 2008
What's Wrong With This Picture?
OK, I don't actually have a picture here, so I'll explain.
The last two or three times I've been at my local post office, I've noticed a friendly gentleman standing by the "Automated Postal Center" (APC) assisting people using it. Meanwhile, at the main counter, there are four windows, one attendant and a line winding out the door. (Personally, I only try to get counter service at the post office at 12:15 p.m. on Saturday because everything thinks they close at 12:00, but they are actually open until 12:30!)
Ideally, the APC would help reduce the load of the long line. However, it takes some people longer to use the machine than it does to get help at the counter. Then there was the day when a local business was at the APC shipping about 40 boxes!
I've used the APC and I can't really fault the machine or the software. However, I do think the postal rules have become more complex, which leads to people taking longer to read and interpret the rules.
Now, back to my original thought and a question. Does an automated assistant really help when it must be accompanied by a human assistant?
Maybe it's just a matter of cultural conditioning, but good grief, we've had these things for years now. Whether it's at the post office or grocery store, it takes a live human being on a regular basis to help people use the technology.
All of this makes me think about software usability. I'm sure in these automated service machines there has been due attention paid to usability. Yet, people still struggle. I can think of two notable exceptions: ATMs and airline check in kiosks.
Do you have similar observations, or is it just me?
Oh, and by the way, could we PLEASE get more people at the Post Office counter?
The last two or three times I've been at my local post office, I've noticed a friendly gentleman standing by the "Automated Postal Center" (APC) assisting people using it. Meanwhile, at the main counter, there are four windows, one attendant and a line winding out the door. (Personally, I only try to get counter service at the post office at 12:15 p.m. on Saturday because everything thinks they close at 12:00, but they are actually open until 12:30!)
Ideally, the APC would help reduce the load of the long line. However, it takes some people longer to use the machine than it does to get help at the counter. Then there was the day when a local business was at the APC shipping about 40 boxes!
I've used the APC and I can't really fault the machine or the software. However, I do think the postal rules have become more complex, which leads to people taking longer to read and interpret the rules.
Now, back to my original thought and a question. Does an automated assistant really help when it must be accompanied by a human assistant?
Maybe it's just a matter of cultural conditioning, but good grief, we've had these things for years now. Whether it's at the post office or grocery store, it takes a live human being on a regular basis to help people use the technology.
All of this makes me think about software usability. I'm sure in these automated service machines there has been due attention paid to usability. Yet, people still struggle. I can think of two notable exceptions: ATMs and airline check in kiosks.
Do you have similar observations, or is it just me?
Oh, and by the way, could we PLEASE get more people at the Post Office counter?
Wednesday, December 19, 2007
Price vs. Value
Thanks for the comments on my most recent article, TQM is Not Just Dead, It's in an Unmarked Grave. I especially liked the additional tag added by my friend Jim Anderson in Florida, who added, "and the unmarked grave is surrounded by armed guards to ensure nothing miraculous occurs." I love it. If you have a similar comment, please let me know. By the way, I plan on writing some book reviews and other articles to keep the thoughts on processes and systems alive. It's not about documentation - it's about profits and effectiveness!
On a different note, I was in a store yesterday with my wife and grandson just to pick up a few small Christmas wrapping items. They had some action figures for $1, and my grandson really wanted one, so I thought, "OK, what the heck." and bought it for him.
Of course, I knew that for a dollar, not to expect too much. However, my 3 year old grandson was expecting more.
When the figure didn't hold the sword very well, he started getting frustrated. He also didn't understand my explanation about "you get what you pay for."
Why am I going down this trail? It reminded me of how people think first of the price of services, but fail to consider the value (or lack of it).
For example, a prospective client may ask for a price quote for me to come in and train their people. When I provide the quote, I also convey the value of the services, such as more defects found, better information provided to management, etc. I encourage people to consider how many defects prevented or found it will take to pay for the training. I have known some companies that measure defects that have found an average defect costs in the neighborhood of $5,000 to fix in production use.
However, some people just look at price alone. They will get a variety of quotes (nothing wrong with that), but then the comparison is on price alone. They may choose the cheapest option and then ask me to match the price but still deliver the same value as with my normal pricing. I will work with people to get a "win-win", but I don't play the car dealer game to match my competitor's lowest price. I just feel that it's a no-win situation. The client doesn't win because although they might get a low price, I'm not feeling good about my end of the deal and I don't like to risk that affecting my delivery of the service.
On the other hand, when I'm making my rate I go the extra mile for my clients and the results are spectacular. I have clients who think I should be charging higher rates. How often do you hear that?
I know this seems self-serving, but I don't talk about rates very often and it's on my mind so I thought I would blog it. Setting rates is a strange art, but I believe that someone's rate should be based on the benefit delivered, not on the "going rate" or how much it takes to keep the lights on. Consultants and trainers often get a black eye because the service doesn't give the value in relation to the rate. My motivation is to deliver the value in excess of my rate. I like for people to know my thought process about rates.
Speaking of rates, sometimes people ask why I don't post them on the site. I feel that 1) the rate depends on the job and each job is unique at some point and 2) I don't like to let my competitors know. All I'll say is that I'm not cheap, but I'm good!
So, if you ask me for a rate quote and choose someone else, I'm not offended. I just want to make sure you understand that just like the $1 action figure, you get what you pay for.
Have a great day!
Randy
Friday, December 14, 2007
Lessons Learned in a Boston Snowstorm
Well, I'm trying to get home from a class (Adding Value to QA and Testing Processes) I presented in the Boston area this week. It was a great session and I really enjoy teaching people who are engaged in the topic. I was so glad to be able to actually get to the class because in Oklahoma City we were hammered last Sunday by a devastating ice storm.
There were lots of trees destroyed and 700,000+ people without power at some points. (My thanks to the folks at OG&E and the people who came in from outof state to help us! God bless you!) In fact, my flight was one of the first to take off Tuesday afternoon, as the airport had been pretty much shut down most of the weekend.
As it turned out, I was jumping out of the refrigerator into the deep freeze!
As those of you in the U.S. know by now, Boston was hammered by a snow storm on Thursday (Gee, it seems like last week already!). Here's what made it interesting.
Despite the warnings and planning, most of the state was paralyzed. In fact, the warnings may have actually contributed to the problem in a major way.
It took me 4 and one-half hours to travel about 16 miles on the highway. The highest speed I reached was 15 mph, and the average was about 4 mph. I was not alone. In fact, I fared pretty well as compared to some.
The crazy thing was that the snow wasn't that bad. Listening to the radio was a riot. People who have lived there all of their lives were ranting about "what's happened to us here?" I'll admit, as a "Okie", I was thinking that even we handle winter weather better that this. (No offense intended.)
Here's what I think happened and it applies in other situations as well. Warnings went out the day before that the snow would hit during the evening rush hour, so people should plan on leaving work early. So, as people are (including myself), we waited until it started snowing around 1:00 p.m., then left. It was snowing about 1" per hour, so it didn'y take long for it to start getting messy.
However, because EVERYONE left work early, rush hour started at 1:00 instead of 3:00 or 4:00. So, the snowplows couldn't move the snow because of all the people trying to get through the snow. What irony! You might say, the perfect storm.
As much as the weather caused a problem, so did people's response to the weather. I think we may have been better off just giving the forecast and letting people figure out for themselves when to leave work.
We see the same thing happen with software and systems. Consider the web site to buy concert tickets that only gives people two minutes to complete the transaction. Because of the heavy load seen when the tickets go on sale, it's hard to get the response time to finish in two minutes! (As you can tell...I have experience in this scenario.)
When thinking about system performance, give very careful consideration about what people may do that could actually aggrevate problems (like hitting the Enter key multiple times just to make the system go faster). That's why good system performance (and weather response) needs to be well thought-out.
While we can't control what people do, we can influence what they do.
OK, lesson learned. If all goes well, I should get home to Oklahoma City just in time for another snow event. I think I feel a "sick day" coming on.
There were lots of trees destroyed and 700,000+ people without power at some points. (My thanks to the folks at OG&E and the people who came in from outof state to help us! God bless you!) In fact, my flight was one of the first to take off Tuesday afternoon, as the airport had been pretty much shut down most of the weekend.
As it turned out, I was jumping out of the refrigerator into the deep freeze!
As those of you in the U.S. know by now, Boston was hammered by a snow storm on Thursday (Gee, it seems like last week already!). Here's what made it interesting.
Despite the warnings and planning, most of the state was paralyzed. In fact, the warnings may have actually contributed to the problem in a major way.
It took me 4 and one-half hours to travel about 16 miles on the highway. The highest speed I reached was 15 mph, and the average was about 4 mph. I was not alone. In fact, I fared pretty well as compared to some.
The crazy thing was that the snow wasn't that bad. Listening to the radio was a riot. People who have lived there all of their lives were ranting about "what's happened to us here?" I'll admit, as a "Okie", I was thinking that even we handle winter weather better that this. (No offense intended.)
Here's what I think happened and it applies in other situations as well. Warnings went out the day before that the snow would hit during the evening rush hour, so people should plan on leaving work early. So, as people are (including myself), we waited until it started snowing around 1:00 p.m., then left. It was snowing about 1" per hour, so it didn'y take long for it to start getting messy.
However, because EVERYONE left work early, rush hour started at 1:00 instead of 3:00 or 4:00. So, the snowplows couldn't move the snow because of all the people trying to get through the snow. What irony! You might say, the perfect storm.
As much as the weather caused a problem, so did people's response to the weather. I think we may have been better off just giving the forecast and letting people figure out for themselves when to leave work.
We see the same thing happen with software and systems. Consider the web site to buy concert tickets that only gives people two minutes to complete the transaction. Because of the heavy load seen when the tickets go on sale, it's hard to get the response time to finish in two minutes! (As you can tell...I have experience in this scenario.)
When thinking about system performance, give very careful consideration about what people may do that could actually aggrevate problems (like hitting the Enter key multiple times just to make the system go faster). That's why good system performance (and weather response) needs to be well thought-out.
While we can't control what people do, we can influence what they do.
OK, lesson learned. If all goes well, I should get home to Oklahoma City just in time for another snow event. I think I feel a "sick day" coming on.
Sunday, October 28, 2007
StarWest 2007 Recap
Hi everyone!
Janet and I had a good week at StarWest last week, along with 1,300 or so of our fellow software testers. I thought I would pass along a few observations for those of you who didn't make it there.
First, many thanks to SQE for inviting me to speak again this year. And many thanks to those who attended by tutorial on Becoming an Influential Test Team Leader and the track session on Taming the Code Monolith – A Tester's Perspective. I plan to have the narrated slide show posted this week sometime.
The full-day leadership tutorial is always a joy to present because I get to meet so many people from all over the world that want to be the best at leading their team. We had over 100 people in the tutorial, which can be a challenge in terms of exercises, but those went well.
I sometimes wonder why some people do the things they do, but I also realize that you can learn a lot by just observing. Case in point – there was one lady on the very front row that from the outset of the workshop chose to read a magazine. Everyone else was engaged and appeared to be interested.
At the first exercise, she left and didn't return. The interesting thing is that the exercise involved working in small teams and everyone getting a card. Each card had a different action or indicated a role. She must have gotten the card that read “You are the Leader!” because that team started the exercise and learned they had no leader. However, someone in the team stepped up with no prompting and led. I guess I know who the real leader was!
I wasn't offended that she left and I truly hope she found a session that was more to her liking. I just could not help but note the contrast between the people who were engaged and those who just sit back and watch. That's why I give everyone a chance to participate – ask a question, share a tip, debate a point, you name it.
So, if you ever attend one of my leadership workshops be prepared. You may be called upon to lead!
By the way, we also made our own list of major testing challenges. We arrived at 30 of them! Guess what, there were none that were purely technical. Most were human in origin and a few were both human and technical.
As for keynotes, one of my favorites was Dot Graham's and Mark Fewster's (Grove Consultants, UK) keynote address on the “Five Doings of Software Testing”. It's not easy to do a duet keynote and they did it very well. On every “doing” they kept the audience engaged. The five doings are searching, checking, assessing, measuring and sampling.
Another keynote address I really liked was Lee Copeland's “The Nine Forgettings.” It was all about the things it seems we software testers have forgotten in recent years, such as lessons from the early pioneers of our field. (Only a few people could name even three out of seven of the pioneers on the slide.) It was a great session to remind us that we need to keep the foundations in mind. Lee handled an interesting group of questions toward the end on topics ranging from the future of testing to the value of test certifications.
My favorite presentation on SOA (Service-Oriented Architecture) was by Brian Bryson of IBM. He used the basic Eclipse framework to build and test a simple web service. He presented some lessons learned by the teams at IBM and was just overall a very informative presentation. By the way, there was a decent sized group in the room and it seems that quite a few people are looking to learn how to test SOA. That's encouraging as I am rolling out my new SOA Testing course in two weeks!
I finally got a chance to attend Julie Gardener's (of Grove Consultants, UK) presentation on classification trees. Julie did a great job and her session brought me up to speed quickly on this technique which I plan to add to my intermediate testing course.
Speaking of the “Grovers”, they all did a great job and I appreciate them making the long trip over. They always share very valuable information in very engaging ways. Lloyd Roden presented his Top Ten Testing Myths and Illusions talk, which is always a great session to get people thinking about testing.
(Thanks to the Grove Players for inviting me to be part of their "A Christmas Carol - Testers Version". That's one of my favorites!)
One final note is on Robert Watkin's presentation on the Top Ten Signs You Need to Improve Your Testing Process. I felt a special sense of appreciation for his presentation since we both hail from Oklahoma City and I was able to give him a little advance feedback. Robert had a good sized group in his session and I liked the way he opened up the session for other people to contribute their experiences. Job well done!
I regret that I didn't see the “Testing on the Toilet” presentation by Bharat Mediratta and Antoine Picard from Google. I heard good things about it.
As I close this posting, my thoughts and prayers are with the people in California who have lost their homes and possessions in the fires which started last week. Last week was brutal weather-wise. Temps were in the high 80s+, winds were very high (clocked at over 100 mph on the mountain tops – I estimate about 60 mph at the hotel) and the smoke was everywhere. In the DFW airport on the way home I saw the interview on Larry King's show with Ken Blanchard, who lost his home in the fires. His attitude and faith are an inspiration to me. His words of wisdom were that his family was safe and that's what mattered most, He told about how his church and Christian friends had rallied around him and the other victims. That's how it should be – the Church being there for people.
Thanks for reading this long and winding post. More to come soon.
Best regards,
Randy
Janet and I had a good week at StarWest last week, along with 1,300 or so of our fellow software testers. I thought I would pass along a few observations for those of you who didn't make it there.
First, many thanks to SQE for inviting me to speak again this year. And many thanks to those who attended by tutorial on Becoming an Influential Test Team Leader and the track session on Taming the Code Monolith – A Tester's Perspective. I plan to have the narrated slide show posted this week sometime.
The full-day leadership tutorial is always a joy to present because I get to meet so many people from all over the world that want to be the best at leading their team. We had over 100 people in the tutorial, which can be a challenge in terms of exercises, but those went well.
I sometimes wonder why some people do the things they do, but I also realize that you can learn a lot by just observing. Case in point – there was one lady on the very front row that from the outset of the workshop chose to read a magazine. Everyone else was engaged and appeared to be interested.
At the first exercise, she left and didn't return. The interesting thing is that the exercise involved working in small teams and everyone getting a card. Each card had a different action or indicated a role. She must have gotten the card that read “You are the Leader!” because that team started the exercise and learned they had no leader. However, someone in the team stepped up with no prompting and led. I guess I know who the real leader was!
I wasn't offended that she left and I truly hope she found a session that was more to her liking. I just could not help but note the contrast between the people who were engaged and those who just sit back and watch. That's why I give everyone a chance to participate – ask a question, share a tip, debate a point, you name it.
So, if you ever attend one of my leadership workshops be prepared. You may be called upon to lead!
By the way, we also made our own list of major testing challenges. We arrived at 30 of them! Guess what, there were none that were purely technical. Most were human in origin and a few were both human and technical.
As for keynotes, one of my favorites was Dot Graham's and Mark Fewster's (Grove Consultants, UK) keynote address on the “Five Doings of Software Testing”. It's not easy to do a duet keynote and they did it very well. On every “doing” they kept the audience engaged. The five doings are searching, checking, assessing, measuring and sampling.
Another keynote address I really liked was Lee Copeland's “The Nine Forgettings.” It was all about the things it seems we software testers have forgotten in recent years, such as lessons from the early pioneers of our field. (Only a few people could name even three out of seven of the pioneers on the slide.) It was a great session to remind us that we need to keep the foundations in mind. Lee handled an interesting group of questions toward the end on topics ranging from the future of testing to the value of test certifications.
My favorite presentation on SOA (Service-Oriented Architecture) was by Brian Bryson of IBM. He used the basic Eclipse framework to build and test a simple web service. He presented some lessons learned by the teams at IBM and was just overall a very informative presentation. By the way, there was a decent sized group in the room and it seems that quite a few people are looking to learn how to test SOA. That's encouraging as I am rolling out my new SOA Testing course in two weeks!
I finally got a chance to attend Julie Gardener's (of Grove Consultants, UK) presentation on classification trees. Julie did a great job and her session brought me up to speed quickly on this technique which I plan to add to my intermediate testing course.
Speaking of the “Grovers”, they all did a great job and I appreciate them making the long trip over. They always share very valuable information in very engaging ways. Lloyd Roden presented his Top Ten Testing Myths and Illusions talk, which is always a great session to get people thinking about testing.
(Thanks to the Grove Players for inviting me to be part of their "A Christmas Carol - Testers Version". That's one of my favorites!)
One final note is on Robert Watkin's presentation on the Top Ten Signs You Need to Improve Your Testing Process. I felt a special sense of appreciation for his presentation since we both hail from Oklahoma City and I was able to give him a little advance feedback. Robert had a good sized group in his session and I liked the way he opened up the session for other people to contribute their experiences. Job well done!
I regret that I didn't see the “Testing on the Toilet” presentation by Bharat Mediratta and Antoine Picard from Google. I heard good things about it.
As I close this posting, my thoughts and prayers are with the people in California who have lost their homes and possessions in the fires which started last week. Last week was brutal weather-wise. Temps were in the high 80s+, winds were very high (clocked at over 100 mph on the mountain tops – I estimate about 60 mph at the hotel) and the smoke was everywhere. In the DFW airport on the way home I saw the interview on Larry King's show with Ken Blanchard, who lost his home in the fires. His attitude and faith are an inspiration to me. His words of wisdom were that his family was safe and that's what mattered most, He told about how his church and Christian friends had rallied around him and the other victims. That's how it should be – the Church being there for people.
Thanks for reading this long and winding post. More to come soon.
Best regards,
Randy
Tuesday, October 02, 2007
Making the Leap to a Mac
Last week was a very difficult week for me, technically speaking. On Monday morning, about 3 hours before leaving to conduct workshops in Chicago and Indianapolis, my Toshiba notebook would not boot. Actually, I did get it to boot after waiting about 30 minutes.
Thankfully, I managed to burn a CD of all my presentations for the week, but it was with a sense of fear and dread that I powered it down. Long story short is that Windows went bye-bye on me.
You might be thinking, just reinstall Windows, right? No, Toshiba didn't make it that easy. Their “recovery” CD is actually a reformat CD, which formats the hard drive before it reinstalls Windows.
So I found myself in downtown Chicago (with no vehicle) early Monday evening searching for a new notebook. I've had it with this Toshiba. Nothing but problems since I've had it. Even as I type this, I realize that “hey, the cursor doesn't randomly jump four or five lines above where I'm typing.” That's nice. How sad that I had grown to accept such poor quality.
First stop was Staples. At first I was excited because they were having a blow-out sale on notebooks. The bad news was that they were all blown out. The shelves were empty of computers.
Next stop was Office Max Express where they only had pens, paper clips and other office supplies for the office worker in a paper-based emergency.
Finally, I headed up the Magnificent Mile to the Apple Store. Things seemed to be leading me to this choice. I've been thinking about switching to a MacBook for sometime now and I guess this was the right time.
After explaining my situation (er, crisis) to the salesperson, she hooked me up with a sweet little 13” MacBook that is a pleasure to use. The next evening, I got the Parallels application and Windows XP, so I can now run my Windows applications that won't run on a Mac. It looks odd to see the XP desktop on a Mac (desecration, I'm sure some would say), but aside from a procedural bug in Parallels, the whole thing with XP works great. In fact, it seems to run faster than my Toshiba, which isn't much of a surprise.
Another cool thing is the 30 second boot up time. That may not last for long, but for right now it's great.
I am having to get used to the differences in usage, such as the mainly single-click and the no right click (it's ctrl and click). I'm a fast learner, though!
I've been working now for over 2 hours and the batter is still going strong. My Toshiba's battery life was down to around 8 minutes (really). I had bought an external power source just so I could work on the plane.
And then there's the coolness. I've never owned a cool computer (and I'm not talking about not overheating like my Toshiba does on occasion). No longer than 30 minutes after I had bought the MacBook, two people commented that I wouldn't regret buying it. Some expressed envy.
I really don't think I'm going to regret the switch. One week now, and things are still great. No regrets at all - only smooth computing. I'm sure I'll have to work through a few issues along the way, but for now, it's just nice to be able to work on the road with a fast, reliable, usable and , oh a cool, computer.
Thankfully, I managed to burn a CD of all my presentations for the week, but it was with a sense of fear and dread that I powered it down. Long story short is that Windows went bye-bye on me.
You might be thinking, just reinstall Windows, right? No, Toshiba didn't make it that easy. Their “recovery” CD is actually a reformat CD, which formats the hard drive before it reinstalls Windows.
So I found myself in downtown Chicago (with no vehicle) early Monday evening searching for a new notebook. I've had it with this Toshiba. Nothing but problems since I've had it. Even as I type this, I realize that “hey, the cursor doesn't randomly jump four or five lines above where I'm typing.” That's nice. How sad that I had grown to accept such poor quality.
First stop was Staples. At first I was excited because they were having a blow-out sale on notebooks. The bad news was that they were all blown out. The shelves were empty of computers.
Next stop was Office Max Express where they only had pens, paper clips and other office supplies for the office worker in a paper-based emergency.
Finally, I headed up the Magnificent Mile to the Apple Store. Things seemed to be leading me to this choice. I've been thinking about switching to a MacBook for sometime now and I guess this was the right time.
After explaining my situation (er, crisis) to the salesperson, she hooked me up with a sweet little 13” MacBook that is a pleasure to use. The next evening, I got the Parallels application and Windows XP, so I can now run my Windows applications that won't run on a Mac. It looks odd to see the XP desktop on a Mac (desecration, I'm sure some would say), but aside from a procedural bug in Parallels, the whole thing with XP works great. In fact, it seems to run faster than my Toshiba, which isn't much of a surprise.
Another cool thing is the 30 second boot up time. That may not last for long, but for right now it's great.
I am having to get used to the differences in usage, such as the mainly single-click and the no right click (it's ctrl and click). I'm a fast learner, though!
I've been working now for over 2 hours and the batter is still going strong. My Toshiba's battery life was down to around 8 minutes (really). I had bought an external power source just so I could work on the plane.
And then there's the coolness. I've never owned a cool computer (and I'm not talking about not overheating like my Toshiba does on occasion). No longer than 30 minutes after I had bought the MacBook, two people commented that I wouldn't regret buying it. Some expressed envy.
I really don't think I'm going to regret the switch. One week now, and things are still great. No regrets at all - only smooth computing. I'm sure I'll have to work through a few issues along the way, but for now, it's just nice to be able to work on the road with a fast, reliable, usable and , oh a cool, computer.
Friday, September 07, 2007
Losing Respect for a Mentor
No, I'm not going to name names.
I just experienced something yesterday that concerned/disturbed me and it got me thinking about the role model aspect of being a mentor.
I have many mentors. Some are personal mentors who I meet with for lunch or at least I can personally correspond with and can interact with them. Others are what I'll call "impersonal" mentors who I may never meet, but I learn much from them, their books, their tapes, etc. Examples would be John Maxwell, Zig Zigler, Jim Rohn, etc.
I'm working on a project right now that requires about 5 or 6 mentors (seriously!) and I need each and every one of them.
About a month ago I came across a guy who had some great teaching on business, personal growth, and matters related to being the best. I bought his mp3 series and have listened to it several times. I also subscribed to his e-mail list for updates.
Yesterday, I received his "rant" (That's what he called it as well) and I was OK with the rant and even though I disagreed with some of his conclusions, I fully agree with his freedom to express them.
The thing that really put me off was the prolific use of the F-word, followed by his announcement that he would be leading his weekly study group at his church.
In that moment, he went from a 10 to a 6 in my level of esteem for him.
I can understand and forgive a "slip" of the tongue, but this caused me to ask some questions:
What does this tell me about his respect for his audience?
What does this tell me about his judgment in general?
Is this being consistent?
Is this the type of person I would like to emulate?
Then I thought about some of the other people I mentioned above - would they do this? I know 100% for sure they wouldn't.
I don't expect my mentors to be perfect, but I do expect them to be good role models. I also really try not to be judgmental, yet I do need to exercise discretion. Some of my biggest mistakes have occurred because I didn't listen to my own sense of discretion.
Here's my lesson learned/reinforced - Give a mentor relationship time so that you can learn about their character as well as knowledge. You may learn that they have great knowledge, but do not exhibit the type of behavior that you want to exhibit. By the way, the behaviors can be much worse than the use of profanity!
Before you put your mentor on a pedestal, be careful. People do fall off those things! (That's what Bing Crosby told Rosemary Clooney in White Christmas, except he was talking about knights on white horses.)
I like what Steve Brown of Key Life Ministries says, "When you pick a hero, pick a dead one. That way, they can't disappoint you!"
On the flip side, as a mentor to others, it causes me to be on my guard about how I act and the example I set for others. Once again, perfection isn't the issue, but intent and judgment are critical things to model. It's painful to hear from someone that you've done something to hurt a mentoring relationship. Although I would want to know about it if it did happen, I would prefer it not happen in the first place.
Have you ever had an experience where you were "put off" by a mentor? Let me know in the comments!
Have a great weekend,
Randy
I just experienced something yesterday that concerned/disturbed me and it got me thinking about the role model aspect of being a mentor.
I have many mentors. Some are personal mentors who I meet with for lunch or at least I can personally correspond with and can interact with them. Others are what I'll call "impersonal" mentors who I may never meet, but I learn much from them, their books, their tapes, etc. Examples would be John Maxwell, Zig Zigler, Jim Rohn, etc.
I'm working on a project right now that requires about 5 or 6 mentors (seriously!) and I need each and every one of them.
About a month ago I came across a guy who had some great teaching on business, personal growth, and matters related to being the best. I bought his mp3 series and have listened to it several times. I also subscribed to his e-mail list for updates.
Yesterday, I received his "rant" (That's what he called it as well) and I was OK with the rant and even though I disagreed with some of his conclusions, I fully agree with his freedom to express them.
The thing that really put me off was the prolific use of the F-word, followed by his announcement that he would be leading his weekly study group at his church.
In that moment, he went from a 10 to a 6 in my level of esteem for him.
I can understand and forgive a "slip" of the tongue, but this caused me to ask some questions:
What does this tell me about his respect for his audience?
What does this tell me about his judgment in general?
Is this being consistent?
Is this the type of person I would like to emulate?
Then I thought about some of the other people I mentioned above - would they do this? I know 100% for sure they wouldn't.
I don't expect my mentors to be perfect, but I do expect them to be good role models. I also really try not to be judgmental, yet I do need to exercise discretion. Some of my biggest mistakes have occurred because I didn't listen to my own sense of discretion.
Here's my lesson learned/reinforced - Give a mentor relationship time so that you can learn about their character as well as knowledge. You may learn that they have great knowledge, but do not exhibit the type of behavior that you want to exhibit. By the way, the behaviors can be much worse than the use of profanity!
Before you put your mentor on a pedestal, be careful. People do fall off those things! (That's what Bing Crosby told Rosemary Clooney in White Christmas, except he was talking about knights on white horses.)
I like what Steve Brown of Key Life Ministries says, "When you pick a hero, pick a dead one. That way, they can't disappoint you!"
On the flip side, as a mentor to others, it causes me to be on my guard about how I act and the example I set for others. Once again, perfection isn't the issue, but intent and judgment are critical things to model. It's painful to hear from someone that you've done something to hurt a mentoring relationship. Although I would want to know about it if it did happen, I would prefer it not happen in the first place.
Have you ever had an experience where you were "put off" by a mentor? Let me know in the comments!
Have a great weekend,
Randy
Tuesday, August 21, 2007
Whoda Thunk It? A Tropical Storm Hits Oklahoma!
Normally when it comes to weather events in Oklahoma, we're 1) so dry the ground is like a brick 2) so hot it seems like we can fry eggs on the sidewalk, or 3) dodging tornadoes.
So, it was surprising even to me to see people being rescued from flood waters by helicopters, boats, jet skis, etc. You may have seen this on the national news this weekend.
Well, folks, that's not normal for us. I looked online to see where the rain was heading and I saw a perfectly formed tropical depression swirling just north of Oklahoma City. There was even an "eye"!
What I was seeing were the remnants of tropical storm Erin, which made landfall in Texas and moved north, even gaining strength along the way.
Some towns got 10 inches or more of rain. At my house we got about 6 inches in less than 24 hours. There were flash flood warnings, but hey, we've been getting those quite a bit this year.
The thing that made this event even more unique and devastating (at least 6 people have died) was that the ground is so saturated, the water ran off the ground very quickly.
All this got me thinking about the local forecasts for the weekend. I think we had a 40% chance of rain going into the weekend. Even during the event, I saw no urgent evacuation warnings on TV. To be fair, much of the rain fell in the early morning hours of Sunday. Things that everyone agree on were that 1) this was a really big and unusual weather event, 2) it was largely unexpected and 3) we were totally unprepared.
By the way, there was also a tornado verified during this event!
What does this have to do with testing?
I've been giving this presentation on the Risks of Risk-based Testing lately. My premise is that even though risk-based testing is a good way to test, it is possible to miss risks for a large number of reasons. At this point, my list is at 12 reasons, but I think I have #13 ("We ain't never seen this before!")
There are some risks that we simply don't realize because we have never seen them in our context before. This weather event was an example of that in a non-software context.
In the context of software, perhaps a software application may fail in a way you have never seen before, in a place you've never seen failures before. A big part of dealing with those situation is to be able to identify them quickly and react accordingly. This applies big-time in dealing with security threats, which there is sometimes the surprise of a totally new type of attack.
As you plan your tests, keep in mind that "You don't know what you don't know" and keep an eye out for things you never seen before. As some say "Expect the unexpected." Oh, and a good set of hip waders can come in handy at times also.
So, it was surprising even to me to see people being rescued from flood waters by helicopters, boats, jet skis, etc. You may have seen this on the national news this weekend.
Well, folks, that's not normal for us. I looked online to see where the rain was heading and I saw a perfectly formed tropical depression swirling just north of Oklahoma City. There was even an "eye"!
What I was seeing were the remnants of tropical storm Erin, which made landfall in Texas and moved north, even gaining strength along the way.
Some towns got 10 inches or more of rain. At my house we got about 6 inches in less than 24 hours. There were flash flood warnings, but hey, we've been getting those quite a bit this year.
The thing that made this event even more unique and devastating (at least 6 people have died) was that the ground is so saturated, the water ran off the ground very quickly.
All this got me thinking about the local forecasts for the weekend. I think we had a 40% chance of rain going into the weekend. Even during the event, I saw no urgent evacuation warnings on TV. To be fair, much of the rain fell in the early morning hours of Sunday. Things that everyone agree on were that 1) this was a really big and unusual weather event, 2) it was largely unexpected and 3) we were totally unprepared.
By the way, there was also a tornado verified during this event!
What does this have to do with testing?
I've been giving this presentation on the Risks of Risk-based Testing lately. My premise is that even though risk-based testing is a good way to test, it is possible to miss risks for a large number of reasons. At this point, my list is at 12 reasons, but I think I have #13 ("We ain't never seen this before!")
There are some risks that we simply don't realize because we have never seen them in our context before. This weather event was an example of that in a non-software context.
In the context of software, perhaps a software application may fail in a way you have never seen before, in a place you've never seen failures before. A big part of dealing with those situation is to be able to identify them quickly and react accordingly. This applies big-time in dealing with security threats, which there is sometimes the surprise of a totally new type of attack.
As you plan your tests, keep in mind that "You don't know what you don't know" and keep an eye out for things you never seen before. As some say "Expect the unexpected." Oh, and a good set of hip waders can come in handy at times also.
Wednesday, August 01, 2007
Are You Competent or Extraordinary?
I'm going to keep this posting short, since I'm busy putting final touches on a workshop I'm conducting next week in Norman, OK - Software Testing for Weather Applications. I've always been a weather "enthusiast" and being in Oklahoma we get our share of wild weather for sure!
I was watching a program on CNBC the other evening in which a panel of millionaires were giving insight into their motivations for becoming rich. The thing that really stuck with me and I think applies to anyone that wants to be successful (regardless of how much money you make) is that really successful people go way beyond just being competent in what they do. They work hard to become the best. They are exceptional in what they do.
I've taught for many years that testers need to build "core competencies". I'm thinking I need to start teaching that is just the starting point. Just being able to write a test plan isn't good enough anymore. How can you show your value in other ways?
In fact, in my workshop, "Becoming an Influential Test Team Leader" (which I'll be presenting in September in Indianapolis and October at StarWest) I describe seven ways you can add value and it doesn't require any money. It does require dedication and motivation, though.
This also requires that you work on yourself. The reason I know this is because that's what I've been doing the last 20 years. What I mean is that you have to become a person of character, trust, and integrity. You will be tested!
It means reading the right books - inspiring ones, not comics, listening to the right teaching to get a solid philosophy of life.
To be extraordinary doesn't mean you won't make mistakes. The panel of millionaires also agreed that they've all made plenty of mistakes. The key is to learn from them and not to be derailed by them.
Helping people become extraordinary is what I do. That's why I train all over the world and give stuff away on the web site (www.riceconsulting.com). If I can help you, just let me know.
Enjoy the journey!
Randy
I was watching a program on CNBC the other evening in which a panel of millionaires were giving insight into their motivations for becoming rich. The thing that really stuck with me and I think applies to anyone that wants to be successful (regardless of how much money you make) is that really successful people go way beyond just being competent in what they do. They work hard to become the best. They are exceptional in what they do.
I've taught for many years that testers need to build "core competencies". I'm thinking I need to start teaching that is just the starting point. Just being able to write a test plan isn't good enough anymore. How can you show your value in other ways?
In fact, in my workshop, "Becoming an Influential Test Team Leader" (which I'll be presenting in September in Indianapolis and October at StarWest) I describe seven ways you can add value and it doesn't require any money. It does require dedication and motivation, though.
This also requires that you work on yourself. The reason I know this is because that's what I've been doing the last 20 years. What I mean is that you have to become a person of character, trust, and integrity. You will be tested!
It means reading the right books - inspiring ones, not comics, listening to the right teaching to get a solid philosophy of life.
To be extraordinary doesn't mean you won't make mistakes. The panel of millionaires also agreed that they've all made plenty of mistakes. The key is to learn from them and not to be derailed by them.
Helping people become extraordinary is what I do. That's why I train all over the world and give stuff away on the web site (www.riceconsulting.com). If I can help you, just let me know.
Enjoy the journey!
Randy
Monday, June 18, 2007
Please...No More Eight Hour Training Days!
I'm sorry to be so remiss in my postings. If you think this is bad, you should see my personal journal! I promise to do better. (I say that in my journal, too!)
When I started this blog, I promised not to use it as a platform for rants. Today I would like to suspend my rule for one day.
I've been training testers, business analysts, and other professionals for over 18 years. However, I do not consider myself to be primarily a "professional" trainer. I'm a software quality professional that has learned to be a good trainer. I guess I've succeeded because people keep asking me to come back and train more people.
I do, however, pay a lot of attention to learning methods and how people learn. That's what brings me to my point.
I got an e-mail today asking if I had a 5-day course on a certain testing topic, with each day of training being 8 hours. This alone would not have bothered me much. But a couple of months ago I responded to a Federal Government proposal that assumed 8 hours in each training day. So, it seems to be on my mind more.
I'm thinking, "Are the organizers trying to punish people?" I might could handle sitting though a one-day course for 8 hours, but two days or more and I would be less than enthusiastic.
My standard is a 6.5 hour training day, not including breaks and lunches. I give the class breaks every hour or so because the human mind can only stay on topic that long. Actually, the experts say the average attention span is more like 15 minutes before some type of different activity is needed. I think the length of the day is also important. People can only retain so much information in one day.
I know that some people might be thinking they want to get their money's worth in training, but I've learned that the greater cost in training isn't the cost of the trainer, but the cost of the people being trained and being away from work. I have found that giving people the freedom to leave a little early and tie up loose ends of the day - e-mail, voice mail, etc., is very much appreciated by the people. (Actually, one of the great benefits of e-learning is being able to learn at your own pace in little segments during the week.)
When people are having a good time, they are more relaxed and retain more information. That doesn't happen on marathon training days. I suppose one exception to this are the true "boot camps" that are really hard core. But in those at least you know what you're getting in to when you sign up.
By the way, I have taught classes that were specified to be 8 hours long, but around 4:00 (hour 7), I get no argument from anyone, including the sponsor of the class, about ending "early".
So, if you are ever in the position of specifying the times and lengths of training, please...don't make it punishment. Keep the times around 6 or 7 hours and your team (and the trainer) will really appreciate it. You'll find that the overall impact of the training will also be much greater.
Thanks for reading!
Randy
When I started this blog, I promised not to use it as a platform for rants. Today I would like to suspend my rule for one day.
I've been training testers, business analysts, and other professionals for over 18 years. However, I do not consider myself to be primarily a "professional" trainer. I'm a software quality professional that has learned to be a good trainer. I guess I've succeeded because people keep asking me to come back and train more people.
I do, however, pay a lot of attention to learning methods and how people learn. That's what brings me to my point.
I got an e-mail today asking if I had a 5-day course on a certain testing topic, with each day of training being 8 hours. This alone would not have bothered me much. But a couple of months ago I responded to a Federal Government proposal that assumed 8 hours in each training day. So, it seems to be on my mind more.
I'm thinking, "Are the organizers trying to punish people?" I might could handle sitting though a one-day course for 8 hours, but two days or more and I would be less than enthusiastic.
My standard is a 6.5 hour training day, not including breaks and lunches. I give the class breaks every hour or so because the human mind can only stay on topic that long. Actually, the experts say the average attention span is more like 15 minutes before some type of different activity is needed. I think the length of the day is also important. People can only retain so much information in one day.
I know that some people might be thinking they want to get their money's worth in training, but I've learned that the greater cost in training isn't the cost of the trainer, but the cost of the people being trained and being away from work. I have found that giving people the freedom to leave a little early and tie up loose ends of the day - e-mail, voice mail, etc., is very much appreciated by the people. (Actually, one of the great benefits of e-learning is being able to learn at your own pace in little segments during the week.)
When people are having a good time, they are more relaxed and retain more information. That doesn't happen on marathon training days. I suppose one exception to this are the true "boot camps" that are really hard core. But in those at least you know what you're getting in to when you sign up.
By the way, I have taught classes that were specified to be 8 hours long, but around 4:00 (hour 7), I get no argument from anyone, including the sponsor of the class, about ending "early".
So, if you are ever in the position of specifying the times and lengths of training, please...don't make it punishment. Keep the times around 6 or 7 hours and your team (and the trainer) will really appreciate it. You'll find that the overall impact of the training will also be much greater.
Thanks for reading!
Randy
Thursday, December 07, 2006
Greetings From EuroStar 2006!
I'm in Manchester, U.K. this week presenting at and attending EuroStar 2006. The key theme of the week has been "wet"!
I guess I should have expected that. I'm glad I brought an extra pair of shoes. That allowed me to have one "wet pair" and one "dry pair!" Although the weather has been a little dreary, the conference has been good.
Seriously, the theme this week for the conference has been "Building the Dream Team" and the focus has been on the human aspects of software testing. Scott Barber, one of three or four us here from the USA, gave a very good keynote talk on Wednesday on "Special Teams" in testing. His focus being performance testing, Scott did a great job in comparing how the critical functions, such as Configuration Management, Performance Testing, Security Testing, etc., are like the special teams on a football team (US version). You can win and lose games based on the performance of the kicking team, punt return team, etc. Good analogy!
I attended a session that discussed the feasibility of trying to define a Body of Knowledge for software testing. There certainly are many issues and challenges in doing that, but I could see some value, especially if it were an open contribution, such as wikipedia. More to come on that.
I also attended a great session today about testing the accessibility of software by people with disabilities. I came away with an increased awareness of the importance of this type of testing and some good ways to perform it, so look for some of those ideas to be developed into an upcoming article in my newsletter.
It's been great to see friends here again. The folks at Grove Consultants are always a joy to be around. I must find a way to keep Lloyd Roden from buying all my meals. Thanks Dot, Lloyd, Mark, Clive and Julie for your hospitality! Thanks to Graham Freeburn for being a great track host and for the use of a cell phone while here! Thanks to all the people at QualTech for 1) inviting me to speak and 2) for being great hosts as well.
It's been a challenge to find Wi-fi from my hotel, so I resort to trying various places. So, I must sign off now. I'm back to the USA tomorrow (Friday) and will post again soon.
Thanks for reading!
Randy
I guess I should have expected that. I'm glad I brought an extra pair of shoes. That allowed me to have one "wet pair" and one "dry pair!" Although the weather has been a little dreary, the conference has been good.
Seriously, the theme this week for the conference has been "Building the Dream Team" and the focus has been on the human aspects of software testing. Scott Barber, one of three or four us here from the USA, gave a very good keynote talk on Wednesday on "Special Teams" in testing. His focus being performance testing, Scott did a great job in comparing how the critical functions, such as Configuration Management, Performance Testing, Security Testing, etc., are like the special teams on a football team (US version). You can win and lose games based on the performance of the kicking team, punt return team, etc. Good analogy!
I attended a session that discussed the feasibility of trying to define a Body of Knowledge for software testing. There certainly are many issues and challenges in doing that, but I could see some value, especially if it were an open contribution, such as wikipedia. More to come on that.
I also attended a great session today about testing the accessibility of software by people with disabilities. I came away with an increased awareness of the importance of this type of testing and some good ways to perform it, so look for some of those ideas to be developed into an upcoming article in my newsletter.
It's been great to see friends here again. The folks at Grove Consultants are always a joy to be around. I must find a way to keep Lloyd Roden from buying all my meals. Thanks Dot, Lloyd, Mark, Clive and Julie for your hospitality! Thanks to Graham Freeburn for being a great track host and for the use of a cell phone while here! Thanks to all the people at QualTech for 1) inviting me to speak and 2) for being great hosts as well.
It's been a challenge to find Wi-fi from my hotel, so I resort to trying various places. So, I must sign off now. I'm back to the USA tomorrow (Friday) and will post again soon.
Thanks for reading!
Randy
Wednesday, November 22, 2006
Losing Credibility in a Moment
I spoke last Friday (11/17/06) at QAI's Testing Conference on the topic of how to build and keep your credibility. The main idea is that if people don't find you credible, they won't believe your findings. I also made the point that it takes a long time to build credibility, but it can be lost in a moment.
Well, little did I know that very evening Michael Richards (aka "Kramer") would validate that point by going on a racial tirade that lasted a few minutes but may have destroyed his career. (The video is at TMZ.com)
Richards doesn't have credibility at stake as much as he has reputation and marketablility. Both took a pretty big hit on Friday evening at the Laugh Factory.
There is also the issue of damage by association. This was really bad timing for Jerry Seinfeld since the 7th season DVD is soon to be released. Some think that sales will take a hit. We'll have to wait and see on that one.
The thing that amazes me is how long it takes to build a career and reputation and quickly it can be damaged or lost.
Want to view and listen to the presentation on credibility? Just go to the presentations page on my web site and register as a free member.
Well, little did I know that very evening Michael Richards (aka "Kramer") would validate that point by going on a racial tirade that lasted a few minutes but may have destroyed his career. (The video is at TMZ.com)
Richards doesn't have credibility at stake as much as he has reputation and marketablility. Both took a pretty big hit on Friday evening at the Laugh Factory.
There is also the issue of damage by association. This was really bad timing for Jerry Seinfeld since the 7th season DVD is soon to be released. Some think that sales will take a hit. We'll have to wait and see on that one.
The thing that amazes me is how long it takes to build a career and reputation and quickly it can be damaged or lost.
Want to view and listen to the presentation on credibility? Just go to the presentations page on my web site and register as a free member.
Thursday, November 16, 2006
Your Tax Dollars at Work
I'm here at QAI's testing conference where I'll present a keynote address on Friday about Credibility.
Surfing today's top stories, I came across this jewel at msnbc.com:
Pentagon money-saving travel site - doesn't
Half-billion dollar system hardly being used
http://www.msnbc.msn.com/id/15746788/
Synopsis: "The Pentagon that gave taxpayers a $434 hammer and a $600 toilet seat cover now has a half-billion-dollar travel booking system that is bypassed by more than eight in 10 users.
Surfing today's top stories, I came across this jewel at msnbc.com:
Pentagon money-saving travel site - doesn't
Half-billion dollar system hardly being used
http://www.msnbc.msn.com/id/15746788/
Synopsis: "The Pentagon that gave taxpayers a $434 hammer and a $600 toilet seat cover now has a half-billion-dollar travel booking system that is bypassed by more than eight in 10 users.
Senate investigators found the Pentagon's Web-based product - despite its high price tag - fails to find the cheapest airfares, offers an incomplete list of flights and hotels and won't recognize travel categories used by the National Guard and Reserves."
My view is that this kind of thing is all too common. After all, wasn't the whole point of SEI's CMM and other work supposed to help prevent these kinds of things?
After seeing a lot of these types of projects up-close, I'm convinced that the contracting processes are beyond broken. The contract was awarded in 1998 to a company that is now part of Northrop Grumman Mission Systems. So, this has been in process for about 8 years.
Has anyone there heard of Orbitz, Travelocity, etc? I'm sure there are "reasons" why a simple solution like that would not be feasible (special government rates and all), but I bet they go back to contracting rules and regulations - the same framework that spends half a million dollars on a system that people won't use. In fact, I have asked for government rates at hotels before only to learn that the rate I got on the Internet was actually cheaper!
My friends that work for the government are also very frustrated by the way these types of projects are initiated and performed. So, my beef is not with them, it's with the system that rewards the "beltway bandits."
This is just one more example of what I often tell my students that "The best defect you can find is the system that shouldn't be built." The average cost per defect on that one is in the millions of dollars range!
Just something to remember next April 15th!
Thursday, October 19, 2006
StarWest Post #2
Today (Wednesday, Oct. 18, 2006) we had three great keynote sessions.
First, Harry Robinson of Google spoke about "How to Build Your Own Robot Army". I thought this was one of the best presentations I have heard at a conference. The main thing I took away from Harry's talk was that test automation can move beyond just repeating carefully constructed scripts to test a variety of functions repeatedly and somewhat randomly.
I think this could find many more defects than the way we currently test and perform test automation. Also, the cost of testing using robots can be many orders of magnitude less than anything we are currently doing.
Do you know anyone who would test for $1.25/hour USD? Plus, you can share the robots with developers to advance testing in the development process, which reduces defects found in testing, and makes life better for everyone.
You can learn more about Harry's work at www.model-based-testing.org.
Gary McGraw of Cigital spoke on security testing. It was a great presentation as well. The main things I took away from the talk was that 1) the more code, the more bugs there are, 2) bad guys exploit bugs to gain access to systems, 3) to find these bugs, you must think like an attacker.
Finally, Lloyd Roden of Grove Consultants (UK) spoke on the Top Ten Myths and Illusions of Testing. Lloyd is a good friend and I greatly enjoyed his address. His talk was thought-provoking and entertaining. Just a few of the myths and illusions he covered were: anyone can test, senior managers are interested in bug counts, and quality can't be measured.
It was a good day with lots of great ideas and information!
First, Harry Robinson of Google spoke about "How to Build Your Own Robot Army". I thought this was one of the best presentations I have heard at a conference. The main thing I took away from Harry's talk was that test automation can move beyond just repeating carefully constructed scripts to test a variety of functions repeatedly and somewhat randomly.
I think this could find many more defects than the way we currently test and perform test automation. Also, the cost of testing using robots can be many orders of magnitude less than anything we are currently doing.
Do you know anyone who would test for $1.25/hour USD? Plus, you can share the robots with developers to advance testing in the development process, which reduces defects found in testing, and makes life better for everyone.
You can learn more about Harry's work at www.model-based-testing.org.
Gary McGraw of Cigital spoke on security testing. It was a great presentation as well. The main things I took away from the talk was that 1) the more code, the more bugs there are, 2) bad guys exploit bugs to gain access to systems, 3) to find these bugs, you must think like an attacker.
Finally, Lloyd Roden of Grove Consultants (UK) spoke on the Top Ten Myths and Illusions of Testing. Lloyd is a good friend and I greatly enjoyed his address. His talk was thought-provoking and entertaining. Just a few of the myths and illusions he covered were: anyone can test, senior managers are interested in bug counts, and quality can't be measured.
It was a good day with lots of great ideas and information!
Wednesday, October 18, 2006
StarWest Post #1
I'm at StarWest in Anaheim, CA this week. Thanks to those of you who attended my tutorial session on Monday on "Becoming an Influential Test Team Leader." We had a great time.
Some of you have asked for the list of testing challenges we made during the session, so here it is (not in any particular order):
1. Getting the right technology match (i.e., test tools) for the type of testing at hand
2. Not having enough time for testing
3. Lack of testing skills/training
4. Inability to reproduce defects
5. Insufficient documentation
6. Changing requirements
7. Knowing when to stop testing
8. Cultural resistance to testing
9. Lack of time for training
10. Holding back defect information to look good later in the project
11. Testers being seen as an obstacle to progress
12. No time reserves
13. Over-reliance on testing to find all the defects
14. Lack of human resources
15. Testing only along a narrow path (lack of rigor in testing)
16. Schedule-driven projects
17. The wrong people performing testing
18. Communication gaps
19. Resource planning
20. Non-tangible nature of QA/test
21. Transitioning to automation
22. Understanding how customers use a product
23. Managing offshoring of testing
Whew! What a list!
We determined that 18 are human in nature, 1 (#1) was purely technical and 4 were both. So, this validates the thesis of my book, Surviving the Top Ten Challenges of Software Testing, that most testing problems are people problems.
I'll check in later this week and give my thoughts on what I am hearing and seeing at the conference.
Randy Rice's Software Testing & Quality Blog
Some of you have asked for the list of testing challenges we made during the session, so here it is (not in any particular order):
1. Getting the right technology match (i.e., test tools) for the type of testing at hand
2. Not having enough time for testing
3. Lack of testing skills/training
4. Inability to reproduce defects
5. Insufficient documentation
6. Changing requirements
7. Knowing when to stop testing
8. Cultural resistance to testing
9. Lack of time for training
10. Holding back defect information to look good later in the project
11. Testers being seen as an obstacle to progress
12. No time reserves
13. Over-reliance on testing to find all the defects
14. Lack of human resources
15. Testing only along a narrow path (lack of rigor in testing)
16. Schedule-driven projects
17. The wrong people performing testing
18. Communication gaps
19. Resource planning
20. Non-tangible nature of QA/test
21. Transitioning to automation
22. Understanding how customers use a product
23. Managing offshoring of testing
Whew! What a list!
We determined that 18 are human in nature, 1 (#1) was purely technical and 4 were both. So, this validates the thesis of my book, Surviving the Top Ten Challenges of Software Testing, that most testing problems are people problems.
I'll check in later this week and give my thoughts on what I am hearing and seeing at the conference.
Randy Rice's Software Testing & Quality Blog
Monday, September 11, 2006
Remembering Steve Irwin
I was truly saddened to hear of the freak accident that killed Steve Irwin (The Crocodile Hunter) recently. It took me a while to realize what I will miss most about Steve. After all, it was so easy for me to drop a quick impersonation into a class – “Crikey, mate! That’s a mean defect!”
The thing about Steve that will stay in my memory is his passion for what he did. He died doing what he loved and there is no way he could have lived without being immersed in nature. Twenty feet away from a crocodile just wouldn’t do for Steve. He had to have his arms wrapped around the croc. I saw him once crawl right up to the opening of a den of rattlesnakes. I live in rattlesnake country and one mile away is a comfortable distance for me.
In my test team leadership courses and tutorials, I discuss the importance of finding where people are passionate and then letting them do things they really love to do. However, the first thing is that people must have a passion for something. I think most people have at least one thing they really love to do. I pity those that don’t.
Passionate people do what they love to do and perform with excellence. They go the extra step to make sure things are right because 1) they love getting it right and 2) they don’t want to appear to be a novice.
A passionate customer service representative spends the extra time with a customer to make sure things are right and gives friendly service, not treat a customer like they just interrupted Monday Night Football.
A passionate delivery person doesn’t leave perishable items on the doorstep in 100 plus degree heat without ringing the doorbell.
I think you get what I mean.
There's a great little book called "The Fred Factor" which I highly recommend. It's a true story about a postman named Fred that does an ordinary job in an exceptional way.A passionate software tester looks for ways to improve their craft. They mentor other testers and contribute to the profession. They take pride in what they do. They don’t blame others for mistakes. Instead, they learn and improve from them.
I love what I do. (A special shout out to American Airlines “That’s why I fly!”) It means a lot to me when others see that I have passion for what I do. Sometimes people will comment on a class evaluation that they can tell I am passionate about software testing. I know that may seem odd that something as detailed (and sometimes boring) as software testing would float my boat.
Software testing is just the vehicle. What I love is to help people be their personal best so they will have a better job and live. I love helping people that create software find, or better yet, avoid, the problems that may one day cause a user to experience problems, perhaps even injury or death.
I personally hate defective software and the ensuing frustration, but I really love being part of the solution instead of the problem. So, as an honor to Steve Irwin and his contribution to this world, I invite you to join me in praying for Steve’s family and reflecting on:
“What am I passionate about?”
“How can I do more of what I love?”
“Do others see my passion for what I do?”
I’m sure that honors Steve’s life and keep his memory going in our own lives.
At the end of the day, there is much more to life than work. However, as a wise person once said, "If you love what you do, you'll never work another day in your life." As I say, love what you do, but before that, love those around you.
By the way, remember the movie "City Slickers?" Passion is that "one thing" that you care about more than anything else.
Randy
Links of Interest
Here’s an interesting link. It’s the text of a commencement address given by Steve Jobs that echoes this theme:
http://news-service.stanford.edu/news/2005/june15/jobs-061505.html
Here’s a link about “How to Do What You Love by Paul Graham:
http://www.paulgraham.com/love.html
Randy Rice's Software Testing & Quality Blog
Friday, July 28, 2006
The Risks of Risk-Based Testing
I'm sorry about not posting sooner. Things have been busy lately.
I've been doing a lot of writing and training lately. I've been working on some cool new projects as well.
One thing I want to let you all know about is an article that will be published in the October 2006 issue of Better Software. It is titled, The Risks of Risk-based Testing. It occured to me while listening to a recent presentation about risk-based testing that although I use risk-based testing quite often, I have also been burned by risk. So, I wrote an article to detail the 12 ways I have been fooled by risk. In the meantime, you can read a rough version of the article at: http://www.riceconsulting.com/articles/risks_of_risk_based_testing.htm.
Bill Perry and I are also working hard to finish our next book, Testing Dirty Systems. I'm not making any predictions on when the book will be available, but we are working diligently on making final comments for the editors at Dorset House.
Thanks for your support and for reading my blog. I'll be back soon!
Randy
I've been doing a lot of writing and training lately. I've been working on some cool new projects as well.
One thing I want to let you all know about is an article that will be published in the October 2006 issue of Better Software. It is titled, The Risks of Risk-based Testing. It occured to me while listening to a recent presentation about risk-based testing that although I use risk-based testing quite often, I have also been burned by risk. So, I wrote an article to detail the 12 ways I have been fooled by risk. In the meantime, you can read a rough version of the article at: http://www.riceconsulting.com/articles/risks_of_risk_based_testing.htm.
Bill Perry and I are also working hard to finish our next book, Testing Dirty Systems. I'm not making any predictions on when the book will be available, but we are working diligently on making final comments for the editors at Dorset House.
Thanks for your support and for reading my blog. I'll be back soon!
Randy
Friday, June 02, 2006
Lessons Learned and Re-learned
This week I embarked on a search for one particular conference presentation I remember hearing at a testing conference a few years ago. This journey down memory lane took me through conference notebooks from the last 15 years.
I started seeing things that I had forgotten from software testing conferences since 1989. Of course, there's a lot of water under those bridges.
Just a couple of weeks ago I was talking with Rick Craig at StarEast about some of those conferences we were at a long time ago and he remarked about how interesting it is that many things are still the same in software testing. A test plan is still a test plan, management still doesn't "get it", we are still on the search for the "magic" test tool, etc.
There have also been some notable new things such as exploratory testing, pairwise testing, and agile methods that have added greatly to the software testing profession.
I could not help but wonder about how much of all of this collective testing knowledge has actually been put to use. I hope for the investment in presenting and receiving this information, it has been helpful to many people, but still I wonder...
I also saw presentation by many friends and remembered many fun times at the conferences with these people.
I've been an independent consultant for over 16 years now and last week I had to relearn a lesson forgotten. The exact lesson is not the important thing. The point is that we often take for granted what we have learned and we can forget even hard lessons over time if we don't revisit them occasionally.
Journaling is helpful for reviewing past lessons learned, but so is reflection. I may even embark on a project to write my own "lessons learned book" just for me.
The great thing is that after relearning this recent lesson, I feel it has burned in even deeper to my being. These are not trivial things. These can be life lessons as well as professional lessons.
How do you revisit your "lessons learned?"
I started seeing things that I had forgotten from software testing conferences since 1989. Of course, there's a lot of water under those bridges.
Just a couple of weeks ago I was talking with Rick Craig at StarEast about some of those conferences we were at a long time ago and he remarked about how interesting it is that many things are still the same in software testing. A test plan is still a test plan, management still doesn't "get it", we are still on the search for the "magic" test tool, etc.
There have also been some notable new things such as exploratory testing, pairwise testing, and agile methods that have added greatly to the software testing profession.
I could not help but wonder about how much of all of this collective testing knowledge has actually been put to use. I hope for the investment in presenting and receiving this information, it has been helpful to many people, but still I wonder...
I also saw presentation by many friends and remembered many fun times at the conferences with these people.
I've been an independent consultant for over 16 years now and last week I had to relearn a lesson forgotten. The exact lesson is not the important thing. The point is that we often take for granted what we have learned and we can forget even hard lessons over time if we don't revisit them occasionally.
Journaling is helpful for reviewing past lessons learned, but so is reflection. I may even embark on a project to write my own "lessons learned book" just for me.
The great thing is that after relearning this recent lesson, I feel it has burned in even deeper to my being. These are not trivial things. These can be life lessons as well as professional lessons.
How do you revisit your "lessons learned?"
Subscribe to:
Posts (Atom)