I got this question recently, so I thought it would be good to answer here as well. Basically, the question is, "With all the threats out there, which of them should SOA architects be concerned with?"
What I see most are the threats that are related to messaging in terms of access to the XML payload. In traditional applications, we have gotten pretty good at authentication (even though that is still hackable sometimes). However, in SOA with web massaging across HTTP/HTTPS, it is easier to find a point in the messaging process where the payload can be accessed. This can lead to a variety of attacks: malware, large payloads, XPath injection, etc.
In my SOA testing course (which is soon to be in an online format - stay tuned!), I describe the nature of these attacks. Most are similar to traditional attacks, except oriented to SOA. Take for example XPath injection. It is similar to SQL injection attacks, except is uses the XPath to gain access to data that is thought to be protected.
Keep in mind that SSL secures the message in transit only, while WS-Security maintains encryption until the message is processed. There are some other advantages of WS-Security over SSL, such as being able to specify securing only part of a message if you like. This can help reduce the performance cost of security.
What have you seen as the "big threats" in SOA security?
Monday, September 08, 2008
Sunday, August 24, 2008
A Lesson Learned in Really Bad Customer Service from Bob Howard Toyota
It's been an interesting weekend. I like to try to see the lessons even in bad situations in life. I also like to use real-life business situations to learn and apply lessons about customer service. For example, if you want to experience really great customer service, just visit any In-n-Out Burger. I'm always amazed.
On the other end of the spectrum, just visit most MacDonalds. They seem to have mastered the ability to forget that the customer is the one that keeps them employed. I experienced that this weekend, but here's the one that really got me.
I spent Saturday morning with my adult son trying to get some help on a car deal gone bad. It's a long story, but the short version is that we went to a supposedly reputable dealer here in the Oklahoma City area (Bob Howard Toyota) looking for a used 4Runner. We were shown and sold a Land Runner which belonged (but not exactly - we found out later he had just registered the vehicle but didn't have the title yet) to one of the salesmen. Therefore, it was a private sale which took place on the lot. About a week later, the vehicle started overheating and eventually (after $600 of repairs) learned that it is a blown head gasket. (About another $1,300 in repairs)They told us if we had any problems, just to come back in and they would help us get anything fixed. OK. That didn't happen.
You can read the longer version here: http://ryanrice.blogspot.com/.
So, we went back in yesterday and asked to speak with the general manager. I was expecting at least a somewhat friendly attitude. Instead, we got a jerk who acted like we were wasting his time. He took no ownership of any issue. When I asked him how he felt about salesment flipping cars on his business lot (essentially taking away his business), he agreed he didn't like that.
OK, so here's the point of this story. 1) I want the local community to know through Google, and 2) it amazes me that the manager could not even treat like a potential customer, which we were.
I would point you to a great book called "Customers for Life" by Carl Sewell, who owns one of the premier car dealerships in the U.S. From Sewell's experience, a satisfied customer who returns to your business for life will spend hundreds of thousands of dollars. Plus, they will tell their friends. I know many people who have used the lessons in that book to transform their businesses into customer-friendly businesses.
I wonder how much money Bob Howard Toyota spends on television ads. (In Oklahoma City, it seems that all you see are car and furniture ads!) I'll tell everyone I know about how badly my son and I were treated there. I've later learned, there have been others. This story makes ours look tame: http://www.ripoffreport.com/reports/0/155/RipOff0155248.htm
This experience has burned in my memory the value in treating my customers right. My current and past clients will tell you that I will bend over backwards to serve you well. That's why I offer a no-risk, no-hassle guarantee on all my e-learning offerings. If you aren't happy, neither am I.
It's not just about the money, either. It's about doing the right thing, about being treated like I would like to be treated. I learned my lessons in customer service from my father who owned and ran a service station when I was a child. I saw first hand how well he treated people and how they kept coming to his station for gas. Those were the full service days - I washed my share of windwhields!
As testers and QA professionals, we all have customers. Yes, internal developers and users are our customers. One of the best ways a QA or test team can earn respect and show value in a company is to treat our customers well. Like at any business, it is the customer that keeps you in business. That is true for both you and me!
Thanks for listening. It was cheaper than therapy!
Have a great week!
On the other end of the spectrum, just visit most MacDonalds. They seem to have mastered the ability to forget that the customer is the one that keeps them employed. I experienced that this weekend, but here's the one that really got me.
I spent Saturday morning with my adult son trying to get some help on a car deal gone bad. It's a long story, but the short version is that we went to a supposedly reputable dealer here in the Oklahoma City area (Bob Howard Toyota) looking for a used 4Runner. We were shown and sold a Land Runner which belonged (but not exactly - we found out later he had just registered the vehicle but didn't have the title yet) to one of the salesmen. Therefore, it was a private sale which took place on the lot. About a week later, the vehicle started overheating and eventually (after $600 of repairs) learned that it is a blown head gasket. (About another $1,300 in repairs)They told us if we had any problems, just to come back in and they would help us get anything fixed. OK. That didn't happen.
You can read the longer version here: http://ryanrice.blogspot.com/.
So, we went back in yesterday and asked to speak with the general manager. I was expecting at least a somewhat friendly attitude. Instead, we got a jerk who acted like we were wasting his time. He took no ownership of any issue. When I asked him how he felt about salesment flipping cars on his business lot (essentially taking away his business), he agreed he didn't like that.
OK, so here's the point of this story. 1) I want the local community to know through Google, and 2) it amazes me that the manager could not even treat like a potential customer, which we were.
I would point you to a great book called "Customers for Life" by Carl Sewell, who owns one of the premier car dealerships in the U.S. From Sewell's experience, a satisfied customer who returns to your business for life will spend hundreds of thousands of dollars. Plus, they will tell their friends. I know many people who have used the lessons in that book to transform their businesses into customer-friendly businesses.
I wonder how much money Bob Howard Toyota spends on television ads. (In Oklahoma City, it seems that all you see are car and furniture ads!) I'll tell everyone I know about how badly my son and I were treated there. I've later learned, there have been others. This story makes ours look tame: http://www.ripoffreport.com/reports/0/155/RipOff0155248.htm
This experience has burned in my memory the value in treating my customers right. My current and past clients will tell you that I will bend over backwards to serve you well. That's why I offer a no-risk, no-hassle guarantee on all my e-learning offerings. If you aren't happy, neither am I.
It's not just about the money, either. It's about doing the right thing, about being treated like I would like to be treated. I learned my lessons in customer service from my father who owned and ran a service station when I was a child. I saw first hand how well he treated people and how they kept coming to his station for gas. Those were the full service days - I washed my share of windwhields!
As testers and QA professionals, we all have customers. Yes, internal developers and users are our customers. One of the best ways a QA or test team can earn respect and show value in a company is to treat our customers well. Like at any business, it is the customer that keeps you in business. That is true for both you and me!
Thanks for listening. It was cheaper than therapy!
Have a great week!
Wednesday, August 06, 2008
Integration and Interoperability Testing of Software
My last post about the American Airlines baggage system failure mentioned interoperability testing and it got me thinking about this important type of testing that is often minimized or overlooked in systems testing.
First, I just need to make a distinction realizing that software testing terminology is often applied in a variety of ways depending on how you were exposed to it. For example, a test case can mean many things to different people. Although standard definitions exist, they are often unknown to professional testers.
So, here are my working definitions:
Integration testing is the verification or validation that data and control can be passed correctly between two or more related systems or system components. In other words, "Can each component or system talk to each other correctly?"
Interoperability testing is the verification or validation that data and control, once passed correctly between two or more related systems or system components, can be applied correctly to achieve the expected results or behavior. In other words, "Can the passed data or control be used correctly to get the right outcome."
The idea is that it's one thing to have integration between items, but another for that integration to be applied correctly. By the way, the definitions I used are the same or similar to that used in defense applications where integration and interoperability testing is paramount.
I consider integration testing a phase or level of testing performed once the related items or systems are available. I consider interoperability testing a type of testing, which can be performed at any phase of testing, from unit to user acceptance testing.
Here's a fictitious (but realistic) example of the two tests in action based on some of my previous rants (er.., comments). Let's say that I am passing some data to another system for sending a passenger's bag to the right destination - either the conveyor belt to be picked up, or on to their next flight. The integration test would tell me if the data made it correctly to the sorting system. The interoperability test would tell me if the sorting system processed that data correctly, made the right determination, and then sent the bags to the correct destination. It is possible that a logic error could send bags that were meant to be on a connecting flight to the conveyor belt for pickup. (NOTE: I must emphasize this is just an example and not what happened with the American problems. It may have been something similar, but the information is not available yet to know what happened.)
The lesson we can all learn is that this type of end-to-end interoperability testing is hugely important but not necessarily easy. Many times it requires validation in the actual operational environment to get a true assessment of correctness.
By the way, I offer a course in Integration and Interoperability Testing.
One more realted note - I found this link to one of my favorite articles from Scientific American on software defects. It's called "Software's Chronic Crisis". Although it's from 1994, don't let the date keep you from reading this very informative article. I'm really glad I found it!
Do you have any experiences with performing (or not performing) interoperability testing? If so, I would love to read your comments.
First, I just need to make a distinction realizing that software testing terminology is often applied in a variety of ways depending on how you were exposed to it. For example, a test case can mean many things to different people. Although standard definitions exist, they are often unknown to professional testers.
So, here are my working definitions:
Integration testing is the verification or validation that data and control can be passed correctly between two or more related systems or system components. In other words, "Can each component or system talk to each other correctly?"
Interoperability testing is the verification or validation that data and control, once passed correctly between two or more related systems or system components, can be applied correctly to achieve the expected results or behavior. In other words, "Can the passed data or control be used correctly to get the right outcome."
The idea is that it's one thing to have integration between items, but another for that integration to be applied correctly. By the way, the definitions I used are the same or similar to that used in defense applications where integration and interoperability testing is paramount.
I consider integration testing a phase or level of testing performed once the related items or systems are available. I consider interoperability testing a type of testing, which can be performed at any phase of testing, from unit to user acceptance testing.
Here's a fictitious (but realistic) example of the two tests in action based on some of my previous rants (er.., comments). Let's say that I am passing some data to another system for sending a passenger's bag to the right destination - either the conveyor belt to be picked up, or on to their next flight. The integration test would tell me if the data made it correctly to the sorting system. The interoperability test would tell me if the sorting system processed that data correctly, made the right determination, and then sent the bags to the correct destination. It is possible that a logic error could send bags that were meant to be on a connecting flight to the conveyor belt for pickup. (NOTE: I must emphasize this is just an example and not what happened with the American problems. It may have been something similar, but the information is not available yet to know what happened.)
The lesson we can all learn is that this type of end-to-end interoperability testing is hugely important but not necessarily easy. Many times it requires validation in the actual operational environment to get a true assessment of correctness.
By the way, I offer a course in Integration and Interoperability Testing.
One more realted note - I found this link to one of my favorite articles from Scientific American on software defects. It's called "Software's Chronic Crisis". Although it's from 1994, don't let the date keep you from reading this very informative article. I'm really glad I found it!
Do you have any experiences with performing (or not performing) interoperability testing? If so, I would love to read your comments.
Monday, August 04, 2008
American Airlines Baggage Failure Gets Personal to Me
I have posted previously about my disdain for the term "glitch", especially when it is misused to describe a major computing problem or failure. "Glitch" just sounds too casual and minor. Such was the case last week when a software defect caused the separation of thousands of bags from their owners and the delay of flights at New York's JFK airport on Wednesday and Thursday.
My wife and I got caught up in the mess. It all began when we missed our connection in Miami. It was close, but the plane left EARLY. Our only recourse was to change routing through JFK. I asked the lady at American, "But isn't that where they're having all the problems with baggage?" She assured me everything was in order. But...we had to spend the night by JFK without our bags, hoping they followed us to our final destination. Guess what? They didn't.
So, we had to buy all the things we needed, plus clothes to wear at the event we were attending, which had a dress code. The "I heart NY" t-shirts just wouldn't cut it. So, the glitch cost an extra $500. I wonder how many other people had similar experiences.
Some people think delays aren't a big deal. Well, with tight connections, cancelled flights and full flights, they can make life miserable is a hurry. Some of my friends had their flight cancelled in this debacle and missed the first day of a vacation they had really looked forward to.
I know, I know....I normally carry on everything. This time I was with my wife who must check a bag, so I thought, "what the heck?" I broke my own rules!
So now I've had a little taste of what the people at London Heathrow's new terminal 5 experienced.
When we think about the cost of computing defects, these are the costs we often forget - loss of time, loss of opportunity, loss of credibility (I trust an airline to get my bags from point A to point C only at my risk. Actually, anymore when I arrive on time at my destination, I'm ahead of the game. I'm so used to being delayed, I've come to expect it.).
OK, now I'm just whining.
In this case, the suspected problem was the interface with the baggage sorter's communication network, which is only less than one year old. Those darn interoperability problems! I wonder...if the system was ever tested end-to-end in the actual operational environment (also known as validation). If anyone knows the answer to that, please let me know.
I am on my way home and I sure hope our bags make it with us. Oh, and yes, we are flying through JFK again!
My wife and I got caught up in the mess. It all began when we missed our connection in Miami. It was close, but the plane left EARLY. Our only recourse was to change routing through JFK. I asked the lady at American, "But isn't that where they're having all the problems with baggage?" She assured me everything was in order. But...we had to spend the night by JFK without our bags, hoping they followed us to our final destination. Guess what? They didn't.
So, we had to buy all the things we needed, plus clothes to wear at the event we were attending, which had a dress code. The "I heart NY" t-shirts just wouldn't cut it. So, the glitch cost an extra $500. I wonder how many other people had similar experiences.
Some people think delays aren't a big deal. Well, with tight connections, cancelled flights and full flights, they can make life miserable is a hurry. Some of my friends had their flight cancelled in this debacle and missed the first day of a vacation they had really looked forward to.
I know, I know....I normally carry on everything. This time I was with my wife who must check a bag, so I thought, "what the heck?" I broke my own rules!
So now I've had a little taste of what the people at London Heathrow's new terminal 5 experienced.
When we think about the cost of computing defects, these are the costs we often forget - loss of time, loss of opportunity, loss of credibility (I trust an airline to get my bags from point A to point C only at my risk. Actually, anymore when I arrive on time at my destination, I'm ahead of the game. I'm so used to being delayed, I've come to expect it.).
OK, now I'm just whining.
In this case, the suspected problem was the interface with the baggage sorter's communication network, which is only less than one year old. Those darn interoperability problems! I wonder...if the system was ever tested end-to-end in the actual operational environment (also known as validation). If anyone knows the answer to that, please let me know.
I am on my way home and I sure hope our bags make it with us. Oh, and yes, we are flying through JFK again!
Monday, July 28, 2008
COTS Feature Bloat and Software Quality
I'm celebrating today. I finally finished making the changes for the 2nd edition of Surviving the Top Ten Challenges of Software Testing! It's been a long time coming, but I'm excited.
We have practically re-written the chapter on tools and automation and have added a new challenge on requirements.
Bill Perry wrote the new chapter on requirements and makes an interesting point that 10% or more of the features in software are never requested as a need by a user. They just "appear".
I was having lunch with week with my friend Frank Rowland who asked the searching question, "Why do software and systems change so much?" Now keep in mind that Frank only upgrades hardware every 5 or 6 years or so, so he struggles a lot with version conflicts. But his question is still valid.
Even people who buy new hardware every 2 years have major issues with version conflicts.
My answer to Frank boiled down to three major things that drive change in the applications and systems we use:
1) Hardware factors, which would include things like processor obsolescence, memory limits, etc. It seems like the developers always have the latest and greatest hardware. So, the new version of your favorite package will likely require an upgrade to use it. It's interesting that every Microsoft Operating System released requires a new machine to work well (and even then, there are often conflicts with other apps that may not be ready for the new OS).
2) Customer demands, which I actually think are the lesser of the reasons, but still a factor. With COTS (commercial off-the-shelf software), it may take years to get that helpful feature to be a reality. The vendors have a tough decision on which features will help the most customers.
3) Profit motives, which are perhaps the greatest drivers. Let's face it, any business depends on repeat business (except perhaps funeral homes). Anyway, software developers and publishers really depend on new versions being sold. Now the issue is getting people to see the value in the new features.
I still use MS Office 2000 because I've tried the demos of Office 2003 and 2007 and I really can't see the value in upgrading. Even when I bought my MacBook, I just downloaded Open Office and have been very happy with it. I have other applications that plug into PowerPoint that work best with PowerPoint 2000.
It's almost comical (if it wasn't so sad) how complex just using a PC has become. Just read the support forums for any application - web based, PC-based or otherwise. Whenever anyone asks, "Why am I having a problem with..." there will be a variety of suggestions, most of which are relating to configuration and compatibility issues. You almost have to be a developer or professional troubleshooter just to survive.
So change happens and most of the time, it's a pain in terms of time and frustration. I don't look for things to get better. Ever.
I see it like having to learn a new language and culture. I'm bi-lingual. I can speak English and computer. It's interesting to me that the PC was supposed to put the power back into the hands of the user, which it did. However, it's now like owning a car. About all I can do is change the oil and brake pads and keep the tires properly inflated. Everything else requires special tools and computers, which I don't own.
To sum all this up, when you're thinking about bringing in a new or updated COTS product, be prepared for lots of breakage. When testing COTS, your main concerns are 1) will it work for me in my environment and 2) what will it break?
The vendor can't test for these things. To neglect testing these things is inviting some pain, perhaps disaster (data loss, long downtimes, etc.). You can test COTS, but it takes a different mindset from the user point of view.
And, yes, change still happens!
We have practically re-written the chapter on tools and automation and have added a new challenge on requirements.
Bill Perry wrote the new chapter on requirements and makes an interesting point that 10% or more of the features in software are never requested as a need by a user. They just "appear".
I was having lunch with week with my friend Frank Rowland who asked the searching question, "Why do software and systems change so much?" Now keep in mind that Frank only upgrades hardware every 5 or 6 years or so, so he struggles a lot with version conflicts. But his question is still valid.
Even people who buy new hardware every 2 years have major issues with version conflicts.
My answer to Frank boiled down to three major things that drive change in the applications and systems we use:
1) Hardware factors, which would include things like processor obsolescence, memory limits, etc. It seems like the developers always have the latest and greatest hardware. So, the new version of your favorite package will likely require an upgrade to use it. It's interesting that every Microsoft Operating System released requires a new machine to work well (and even then, there are often conflicts with other apps that may not be ready for the new OS).
2) Customer demands, which I actually think are the lesser of the reasons, but still a factor. With COTS (commercial off-the-shelf software), it may take years to get that helpful feature to be a reality. The vendors have a tough decision on which features will help the most customers.
3) Profit motives, which are perhaps the greatest drivers. Let's face it, any business depends on repeat business (except perhaps funeral homes). Anyway, software developers and publishers really depend on new versions being sold. Now the issue is getting people to see the value in the new features.
I still use MS Office 2000 because I've tried the demos of Office 2003 and 2007 and I really can't see the value in upgrading. Even when I bought my MacBook, I just downloaded Open Office and have been very happy with it. I have other applications that plug into PowerPoint that work best with PowerPoint 2000.
It's almost comical (if it wasn't so sad) how complex just using a PC has become. Just read the support forums for any application - web based, PC-based or otherwise. Whenever anyone asks, "Why am I having a problem with..." there will be a variety of suggestions, most of which are relating to configuration and compatibility issues. You almost have to be a developer or professional troubleshooter just to survive.
So change happens and most of the time, it's a pain in terms of time and frustration. I don't look for things to get better. Ever.
I see it like having to learn a new language and culture. I'm bi-lingual. I can speak English and computer. It's interesting to me that the PC was supposed to put the power back into the hands of the user, which it did. However, it's now like owning a car. About all I can do is change the oil and brake pads and keep the tires properly inflated. Everything else requires special tools and computers, which I don't own.
To sum all this up, when you're thinking about bringing in a new or updated COTS product, be prepared for lots of breakage. When testing COTS, your main concerns are 1) will it work for me in my environment and 2) what will it break?
The vendor can't test for these things. To neglect testing these things is inviting some pain, perhaps disaster (data loss, long downtimes, etc.). You can test COTS, but it takes a different mindset from the user point of view.
And, yes, change still happens!
Tuesday, June 24, 2008
Tuesday at the Oklahoma City Moodle Moot
Today we heard from Martin Dougiamas, the original developer of Moodle and still the leader, who explained where Moodle came from and where it is going. He said something I found interesting that we as testers already know. He admitted that version 1.7 was a bad release and that his lesson learned was not to release a version just to meet a deadline. Amen, brother!
Martin asked “What is the single most powerful technique for online learning?” In the audience we had several good answers, such as collaboration, communication, etc. His answer was “Asking questions.” He said that's when the learning activity increases. I think that's a good thing to remember for either live training or e-learning. In fact, I offer an optional teleconference session for my corporate e-learning clients and may soon expand that to all of my e-learning students.
The idea is to offer people the opportunity to ask questions about what they have learned in the e-learning sessions. If people don't ask me question, then I ask them questions. Sometimes I say outrageous things just to get a debate going!
This has been a very valuable conference. I have learned more in two days of intense questioning and exposure than I have learned in three years of using Moodle! It's the best $99 I've ever spent on training!
I'm excited to say that I am committed to:
1) Getting to the most recent version of Moodle, which will add great value to all of my students,
2) Being more active in the local and international Moodle community,
3) Being a help to others who want to implement Moodle to enhance their students' learning success.
Stay tuned, folks. This is going to be great!
Martin asked “What is the single most powerful technique for online learning?” In the audience we had several good answers, such as collaboration, communication, etc. His answer was “Asking questions.” He said that's when the learning activity increases. I think that's a good thing to remember for either live training or e-learning. In fact, I offer an optional teleconference session for my corporate e-learning clients and may soon expand that to all of my e-learning students.
The idea is to offer people the opportunity to ask questions about what they have learned in the e-learning sessions. If people don't ask me question, then I ask them questions. Sometimes I say outrageous things just to get a debate going!
This has been a very valuable conference. I have learned more in two days of intense questioning and exposure than I have learned in three years of using Moodle! It's the best $99 I've ever spent on training!
I'm excited to say that I am committed to:
1) Getting to the most recent version of Moodle, which will add great value to all of my students,
2) Being more active in the local and international Moodle community,
3) Being a help to others who want to implement Moodle to enhance their students' learning success.
Stay tuned, folks. This is going to be great!
Monday, June 23, 2008
MoodleMoot in Oklahoma City
Today and tomorrow I'm at the Oklahoma City MoodleMoot. "What's a MoodleMoot?", you ask. Well, it's a conference for people who use the Moodle open-source learning management system (LMS) for e-Learning.
I've been a Moodle user/administrator now for over 3 years as this is the LMS we use for all of the e-learning courses at Rice Consulting Services.
Why is it called Moodle? The idea is that you learn by exploring. So, instead of a forced order of learning, you can experience a variety of topics.
So, why am I here instead of doing something billable? There are many reasons:
1) I am practicing what I preach about building personal skills.
2) This is not a software testing conference, so I get to meet all kinds of new people.
3) It's local to me. What a great opportunity!
4) I have a goal for my e-learning offerings to be the very best available in the field of software testing.This is a place I can learn new ideas to incorporate in my e-learning courses for software testing and software quality.
5) My wife likes me to get out of the house once in a awhile! :-)
A few observations from today:
Now, the BIG chalenge will be to implement all the great ideas!
Have you tried e-learning for software testing? If so, what did you like or not like about it?
If you haven't done so already, drop by my e-learning site and experience a demo. (Just login as a guest.)
I've been a Moodle user/administrator now for over 3 years as this is the LMS we use for all of the e-learning courses at Rice Consulting Services.
Why is it called Moodle? The idea is that you learn by exploring. So, instead of a forced order of learning, you can experience a variety of topics.
So, why am I here instead of doing something billable? There are many reasons:
1) I am practicing what I preach about building personal skills.
2) This is not a software testing conference, so I get to meet all kinds of new people.
3) It's local to me. What a great opportunity!
4) I have a goal for my e-learning offerings to be the very best available in the field of software testing.This is a place I can learn new ideas to incorporate in my e-learning courses for software testing and software quality.
5) My wife likes me to get out of the house once in a awhile! :-)
A few observations from today:
- A great majority of the people here are educators from the academic community - colleges, high schools, technical schools, etc.I'm one of the minority using Moodle in the corporate world. Some have never used Moodle before and some are experienced Moodle administrators.
- I'm learning that I've been doing a lot of things right in the design and delivery of my e-learning courses.By the way, the average evaluation overall score is over 8 on a scale of 10 for RCS e-learning courses. (We get rave reviews from people worldwide who have found my e-learning courses to be an effective way to balance work time and training time.) My courses are designed in a modular way to start with, so when I developed the online versions, the flow was easy for students to understand and follow. In my courses, people aren't over whelmed with choices, assignments and other distractions.
- There is a very robust and deep community around Moodle. That helps a lot when dealing with open source software.In fact, I wish some of the commercial products I use had the level of support that Moodle does.
- I've picked up all kinds on cool ideas to enhance what we are currently doing with e-learning at RCS. Things, such as closed captioning for videos, building online communities, etc.
- There are security risks in e-learning, just like in any other application. I knew that already, but sometimes you need to see the uniqueness of the threats.
Now, the BIG chalenge will be to implement all the great ideas!
Have you tried e-learning for software testing? If so, what did you like or not like about it?
If you haven't done so already, drop by my e-learning site and experience a demo. (Just login as a guest.)
Wednesday, June 18, 2008
One Way to Show the Value of Software Testing Training
I'm in London, ON this week presenting my Agile and Exploratory Testing class. London is a cool place. Today, it was literally cool! One of the things I enjoy doing here is browsing through the used bookstores. For some reason, there are several close to each other in the downtown area.
I forgot to mention in my last post that I had a great Father's day. I visited my dad and my sons and family were with me. All was good. What a blessing.
I was having lunch with a friend and client recently. He told me an interesting story that I want to share. Last August I designed and held a special public course that about 30 people from this one organization attended. There were developers, testers, subject matter experts, plus (most importantly) their managers all in one class for two days.
My friend said that the release they were working on at that time had to go through two cycles of beta testing, each costing about $20,000. The second cycle was due to the extra rework of excessive defects.
Their most recent release had significantly higher quality, which allowed the release to be issued with only one cycle of beta testing - roughly a savings of $20,000 over the last release.
So, I asked my friend, "Do you think the training was part of that improvement." He answered, "I really do. Mainly because the developers and their manager saw the need for better unit testing and learned ways to perform it."
As you look for ways to measure the value of training in software testing, this is an example of one way to do that. Of course, there were other factors. However, I also think the training was a platform to allow the team to do a better job.
I assure you that the savings exceeded the cost of the event!
If you would like to see similar results, contact me. I would love to discuss the possibilities with you.
I forgot to mention in my last post that I had a great Father's day. I visited my dad and my sons and family were with me. All was good. What a blessing.
I was having lunch with a friend and client recently. He told me an interesting story that I want to share. Last August I designed and held a special public course that about 30 people from this one organization attended. There were developers, testers, subject matter experts, plus (most importantly) their managers all in one class for two days.
My friend said that the release they were working on at that time had to go through two cycles of beta testing, each costing about $20,000. The second cycle was due to the extra rework of excessive defects.
Their most recent release had significantly higher quality, which allowed the release to be issued with only one cycle of beta testing - roughly a savings of $20,000 over the last release.
So, I asked my friend, "Do you think the training was part of that improvement." He answered, "I really do. Mainly because the developers and their manager saw the need for better unit testing and learned ways to perform it."
As you look for ways to measure the value of training in software testing, this is an example of one way to do that. Of course, there were other factors. However, I also think the training was a platform to allow the team to do a better job.
I assure you that the savings exceeded the cost of the event!
If you would like to see similar results, contact me. I would love to discuss the possibilities with you.
Monday, June 16, 2008
Catching Up
I've been back from Rome over a week now and I am still trying to catch up with things.
I didn't have a problem with the jet lag. My trick is to get as much sleep as possible going over and not sleep at all until nighttime. Then, coming home, I try to stay awake as long as possible and not sleep until my normal bed time. It worked fine this time.
I've been busy:
1) Preparing for presenting my Agile and Exploratory Testing course this week in London, ON.
2) Getting my ISTQB online course, Foundation Level Course in Software Testing, narration updated. (We were accredited officially last week!)
3) Finishing the writing for the 2nd edition of Surviving the Top Ten Challenges of Software Testing.
4) Conducting a webinar for the EuroStar conference. It was a real pleasure to be on the call with James Whittaker! I'll have the link for you this week to hear the replay.
5) Tons of misc things - e-mail, etc.
I went to my high school reunion Saturday night. I was in the class of 74 at Chickasha High School, but it was a multi-class reunion, which is a great idea (73 - 78). It was great to see many people from my past, including some of the faculty. It reminded me once again how much these teachers contributed to who I am today. I learned how to communicate and got into radio and video production because of John Foster. I learned about the art and craft of writing by being a slacker in Betty Glasscock's English class. I programmed one of my first computers in Mrs. Wallace's Math Analysis class. It was interesting that when I told people what I do today, many said they weren't surprised.
I didn't have a problem with the jet lag. My trick is to get as much sleep as possible going over and not sleep at all until nighttime. Then, coming home, I try to stay awake as long as possible and not sleep until my normal bed time. It worked fine this time.
I've been busy:
1) Preparing for presenting my Agile and Exploratory Testing course this week in London, ON.
2) Getting my ISTQB online course, Foundation Level Course in Software Testing, narration updated. (We were accredited officially last week!)
3) Finishing the writing for the 2nd edition of Surviving the Top Ten Challenges of Software Testing.
4) Conducting a webinar for the EuroStar conference. It was a real pleasure to be on the call with James Whittaker! I'll have the link for you this week to hear the replay.
5) Tons of misc things - e-mail, etc.
I went to my high school reunion Saturday night. I was in the class of 74 at Chickasha High School, but it was a multi-class reunion, which is a great idea (73 - 78). It was great to see many people from my past, including some of the faculty. It reminded me once again how much these teachers contributed to who I am today. I learned how to communicate and got into radio and video production because of John Foster. I learned about the art and craft of writing by being a slacker in Betty Glasscock's English class. I programmed one of my first computers in Mrs. Wallace's Math Analysis class. It was interesting that when I told people what I do today, many said they weren't surprised.
To complete the journey back in time, I also checked out the open house for the old Washita Theatre in Chickasha where I worked one summer between radio jobs. I also saw many movies there, such as Blazing Saddles, many 007 flicks and Deliverance (about 30 times when I was a doorman). Funny thing - everything looked smaller! It was cool to see it again.By the way, this is an older picture of the theatre, before renovation.
I hope to have a series of posts this week that are more testing oriented!
Have a great week!
Randy
Monday, June 02, 2008
Greetings from Rome!
Greetings from Rome where I am preparing to teach two courses this week: Structured User Acceptance Testing and SOA Testing.
I always like to arrive 2 or 3 days in advance of training overseas just to get adjusted to the time before I start teaching. Plus, in Rome there's always a lot to see and do.
Today (Monday) is a bank holiday here so I'll be exploring around one more day. The past two days I have been walking quite a bit. My plan was to get a 48-hour ticket on one of the open busses that travel around the city. I figured that I could stay awake and yet not get too tired.
Saturday was great. I arrived Rome about 8 a.m., got into the hotel by about 10 a.m. and hopped on the bus at 2:00 p.m. The great thing about these busses is that you can hop on and hop off at key stops and you have access for 48 hours. There's also a recorded narration that is about 30 seconds behind the thing you just passed.
Sunday was not great in terms of the bus service, or lack thereof. It was a classic load issue. Too many people, too few busses. One might think that a useful strategy would be once you get a seat - keep it. However, at various stops they made everyone get off the bus. Then, to get back on the bus was nearly impossible. Unless, of course, they made everyone get off the bus. Mama mia!
So, I took a leisurely stroll from the Termini station to the Circus Maximus (complete with Roman soldiers. I'm not sure what that was all about, but I felt like I was in a time warp.). That took about an hour.
Along the way I saw all kinds of cool things, like the Colosseum and the Forum. It's warm and humid here - a lot like Oklahoma except without the tornadoes. So, I was ready for ANY ride to get me close to the hotel.
I finally got on a bus, but not on the open part. I didn't care. You might say I enjoyed as much as I could stand!
There actually is a point to this story. In teaching about test scripts, I often say they are like bus tours. You go where the bus goes, whether you want to or not. I thought about this analogy a few times the past couple of days. However, one thing that caused me to think about test scripts in a new way is what happens when you have to get back on the bus (script) and can't get back on.
That happens in testing using scripts sometimes. Unless your scripting is well constructed and organized, you may have trouble getting back to the point of getting a reliable test. In other words, it may be hard to test what you have intended to test.
And, sometimes you test so much using scripts you just want to get out and walk. That's what I did on this trip to see the Trevi Fountain. Also, that's where my trouble started, but I'm still glad I took the option to hop off the bus.
When testing software, you may also see the need to hop off the bus to explore things. That's fine as long as hopping off the script doesn't mess up other related tests. I often note the things I want to explore and come back a little later to test them.
When testing software, you may also see the need to hop off the bus to explore things. That's fine as long as hopping off the script doesn't mess up other related tests. I often note the things I want to explore and come back a little later to test them.
Well, it's off for another day of exploring Rome!
Thursday, May 08, 2008
StarEast - Update for Wed/Thursday
OK, so I didn't get the Wednesday post written on Wednesday. I forgot how the evenings get busy here, too.
So, here goes. I liked James Whittaker's opening keynote session on Wednesday. It was a different topic than in the brochure, but that's cool.
He made a very important point that our future will involve a lot more code than it does today - and it's going to control even more critical functions than today. Therefore, it needs to work right all the time. I thought the session had some major implications:
1) He's talking about defect-free computing (not just software, but hardware, data and everything else involved in getting correct results.). History has shown this has been an elusive, if not impossible, effort to achieve - largely due to the complexity of the code. Does that mean we should give up? By no means. But, zero defects requires some very rigorous methods and ways to build-in quality, not test it in, which was one of James' points.
2) He said testers need to be less like Lewis and Clark in terms of their test approach. OK, I buy that. Lewis and Clark were explorers. I take that to mean that exploratory testing has some limitations and we need a better way to test. It's interesting, though, that exploratory testing is a very popular test approach and has gained a notable following. Is this a blow to exploratory testing - or simply an admonition that other methods are needed? I think it's the latter, but I find the remark very, very, interesting.
3) James said that testers need more insight into the code. Black box testing is inherently inefficient because you do a lot of poking around. I agree. So, the question is how do we get the development tools to the point that they also contain great diagnostics?
4) Software should be so good that testing is no longer needed. I only wish. I doubt that will ever happen due to the human aspect of software development and usage. About 20 years ago, the folks at SEI didn't include testing in the CMM because they felt if you had a good enough process, the software should be defect-free (or close to it). That never happened and I doubt it will in the future, either. So if you are a tester I wouldn't worry about your job security, at least as a profession. By the way, 20 years ago, people were predicting that coders would not be writing code in the future. While a great deal of code is generated by tools such as Microsoft's Visual Studio, there is still a whole lot of manual coding going on!
I don't know if we'll see the digital future James portrayed in his talk, but I do agree more and more things will be software-driven and the criticality of the applications will also be higher. Think of the cars that will be driving themselves. Heck, there have been cases already where Volvos have quit at highway speeds due to software failures. Along with the cool technology comes problems that aren't so cool.
I liked his session a lot and hope it resonates as a call to testers and developers to take software quality to a higher level.
The second keynote address was by Elizabeth Hendrickson, who spoke about her experiences as a tester on an Extreme Programming team. It was a great talk as well and gave people a good perspective of what an agile tester's work day is like. She addressed issues like requirements in agile, which I thought was great.
Throughout the day, there were a wide variety of track sessions which were well attended. Not every session had a great speaker, but sometimes the content is great so you stay. Sometimes the session as a whole just doesn't do it for you, so you can move to another one.
I spoke at 3:00 on the topic "Testing Disasters and Turnarounds". Thanks to everyone one who attended. I have posted my updated slides here:
http://www.riceconsulting.com/public_pdf/testing-disasters-and-turnarounds-v2.pdf
The products and services expo was good - very well attended. However, it seems like the numbers of tool vendors was smaller this year.
To top the day off, there was a casino night with several really cool prizes, none of which I won.
Thursday
Bahrat Mediratta and Antoine Picard of Google gave an encore presentation of their keynote from StarWest called, Testing in the Toilets. It's a neat story about how a simple act of posting articles they write about testing in the one place everyone goes - the restroom. The results were interesting and it's a great story about how they changed the culture at Google in terms of test awareness.
I had a book signing and other duties today, so I only got to attend two track sessions. I thought the one by Gerard Meszaros (author of "X Unit Patterns) was very interesting on building record/playback automation into your applications. It's an interesting alternative to commercial tools and opens some doors on some creative test automation that solves many of the problems seen in traditional test automation.
So, here goes. I liked James Whittaker's opening keynote session on Wednesday. It was a different topic than in the brochure, but that's cool.
He made a very important point that our future will involve a lot more code than it does today - and it's going to control even more critical functions than today. Therefore, it needs to work right all the time. I thought the session had some major implications:
1) He's talking about defect-free computing (not just software, but hardware, data and everything else involved in getting correct results.). History has shown this has been an elusive, if not impossible, effort to achieve - largely due to the complexity of the code. Does that mean we should give up? By no means. But, zero defects requires some very rigorous methods and ways to build-in quality, not test it in, which was one of James' points.
2) He said testers need to be less like Lewis and Clark in terms of their test approach. OK, I buy that. Lewis and Clark were explorers. I take that to mean that exploratory testing has some limitations and we need a better way to test. It's interesting, though, that exploratory testing is a very popular test approach and has gained a notable following. Is this a blow to exploratory testing - or simply an admonition that other methods are needed? I think it's the latter, but I find the remark very, very, interesting.
3) James said that testers need more insight into the code. Black box testing is inherently inefficient because you do a lot of poking around. I agree. So, the question is how do we get the development tools to the point that they also contain great diagnostics?
4) Software should be so good that testing is no longer needed. I only wish. I doubt that will ever happen due to the human aspect of software development and usage. About 20 years ago, the folks at SEI didn't include testing in the CMM because they felt if you had a good enough process, the software should be defect-free (or close to it). That never happened and I doubt it will in the future, either. So if you are a tester I wouldn't worry about your job security, at least as a profession. By the way, 20 years ago, people were predicting that coders would not be writing code in the future. While a great deal of code is generated by tools such as Microsoft's Visual Studio, there is still a whole lot of manual coding going on!
I don't know if we'll see the digital future James portrayed in his talk, but I do agree more and more things will be software-driven and the criticality of the applications will also be higher. Think of the cars that will be driving themselves. Heck, there have been cases already where Volvos have quit at highway speeds due to software failures. Along with the cool technology comes problems that aren't so cool.
I liked his session a lot and hope it resonates as a call to testers and developers to take software quality to a higher level.
The second keynote address was by Elizabeth Hendrickson, who spoke about her experiences as a tester on an Extreme Programming team. It was a great talk as well and gave people a good perspective of what an agile tester's work day is like. She addressed issues like requirements in agile, which I thought was great.
Throughout the day, there were a wide variety of track sessions which were well attended. Not every session had a great speaker, but sometimes the content is great so you stay. Sometimes the session as a whole just doesn't do it for you, so you can move to another one.
I spoke at 3:00 on the topic "Testing Disasters and Turnarounds". Thanks to everyone one who attended. I have posted my updated slides here:
http://www.riceconsulting.com/public_pdf/testing-disasters-and-turnarounds-v2.pdf
The products and services expo was good - very well attended. However, it seems like the numbers of tool vendors was smaller this year.
To top the day off, there was a casino night with several really cool prizes, none of which I won.
Thursday
Bahrat Mediratta and Antoine Picard of Google gave an encore presentation of their keynote from StarWest called, Testing in the Toilets. It's a neat story about how a simple act of posting articles they write about testing in the one place everyone goes - the restroom. The results were interesting and it's a great story about how they changed the culture at Google in terms of test awareness.
I had a book signing and other duties today, so I only got to attend two track sessions. I thought the one by Gerard Meszaros (author of "X Unit Patterns) was very interesting on building record/playback automation into your applications. It's an interesting alternative to commercial tools and opens some doors on some creative test automation that solves many of the problems seen in traditional test automation.
Finally, I went to John Fodeh's keynote session, "Are We Ready to Ship?", which was a nice treatment of the topic of release metrics for software. I came away with a lot of good ideas.
So, that's it. I'm heading back home early in the morning, so this is my last StarEast post this trip. I felt it was a good conference. I got to see many good friends from all over the world and that always is a good thing!
Tuesday, May 06, 2008
StarEast 2008 - Tuesday Update
Hi from Orlando!
The weather is great and the StarEast software testing conference is going well.
So far, all I can speak to are my own sessions. However, tomorrow I'll be in other sessions and giving some reports to those not able to attend.
In my "Becoming an Influential Test Team Leader" tutorial, we had a great time. Our biggest problem was that during the experiences, we got rather loud. I thought we might get in trouble!
However, I also had people tell me they were not bored at all and totally engaged because of the experiences.
This tutorial is one of my favorite parts of Star for one simple reason. It's an opportunity to engage with test team leaders and managers who want to make a positive difference in their organizations. The great majority of the people that attend this tutorial are savvy people looking for solutions. I hope I am able to provide hope and few solution strategies.
One of the interesting things I've started doing lately is having people submit cards that contain something they have achieved recently. We recognize the person as the larger group and although it sounds a little cheezy, it's a warm experience. Unfortunately, we don't do enough of that kind of thing in the trenches back home, but I hope people carry this idea back with them.
Everyone needs recognition and it is one way to add value to your team. That's because a person that feels appreciated will rise to the occasion at other times as well.
Today I spoke on pairwise testing applied to use cases. I like combining techniques to get a synergistic effect, and this is one of those times when two great techniques make a third more powerful one. I have some new things I plan to add the next time I present this session.
I had a good group and it's always cool to explain this concept to people. I remember the first time I saw the value of pairwise. It's a cool thing. Not the only technique by any means, but a powerful one when used intelligently.
I proctor one of the ASTQB exams this afternoon, and that will be today's work.
I think the format of more tutorials, with many of them being half-day tutorials is great. It "feels" good. I think it opens up more options for people to learn in some in-depth ways.
It's also been great to catch up with good friends like Lloyd Roden and Julie Gardiner from Grove Consultants in the U.K. Friends like this make the conference circuit an enjoyable experience!
See you tomorrow!
Randy
The weather is great and the StarEast software testing conference is going well.
So far, all I can speak to are my own sessions. However, tomorrow I'll be in other sessions and giving some reports to those not able to attend.
In my "Becoming an Influential Test Team Leader" tutorial, we had a great time. Our biggest problem was that during the experiences, we got rather loud. I thought we might get in trouble!
However, I also had people tell me they were not bored at all and totally engaged because of the experiences.
This tutorial is one of my favorite parts of Star for one simple reason. It's an opportunity to engage with test team leaders and managers who want to make a positive difference in their organizations. The great majority of the people that attend this tutorial are savvy people looking for solutions. I hope I am able to provide hope and few solution strategies.
One of the interesting things I've started doing lately is having people submit cards that contain something they have achieved recently. We recognize the person as the larger group and although it sounds a little cheezy, it's a warm experience. Unfortunately, we don't do enough of that kind of thing in the trenches back home, but I hope people carry this idea back with them.
Everyone needs recognition and it is one way to add value to your team. That's because a person that feels appreciated will rise to the occasion at other times as well.
Today I spoke on pairwise testing applied to use cases. I like combining techniques to get a synergistic effect, and this is one of those times when two great techniques make a third more powerful one. I have some new things I plan to add the next time I present this session.
I had a good group and it's always cool to explain this concept to people. I remember the first time I saw the value of pairwise. It's a cool thing. Not the only technique by any means, but a powerful one when used intelligently.
I proctor one of the ASTQB exams this afternoon, and that will be today's work.
I think the format of more tutorials, with many of them being half-day tutorials is great. It "feels" good. I think it opens up more options for people to learn in some in-depth ways.
It's also been great to catch up with good friends like Lloyd Roden and Julie Gardiner from Grove Consultants in the U.K. Friends like this make the conference circuit an enjoyable experience!
See you tomorrow!
Randy
Sunday, May 04, 2008
Why Your SOA Effort May Fail
I'm getting ready for my StarEast trip, but want to mention an interesting article I read this week titled, "SOA failures traced to people, process issues" on Networkworld.com (http://www.networkworld.com/news/2008/043008-interop-soa.html).
The article quotes Anne Thomas Manes of the Burton Group in response to a question about what overriding message IT executives need to hear about Service-oriented Architecture (SOA).
"The problem's not technology, Howard said. People and processes are at the heart of what's wrong with SOA as it currently exists in enterprises."
I found it interesting that in an audience of around 300 people, only 6 indicated that their SOA efforts were proceeding well.
I can add my own observation that adds support to Manes' comments, that is, people in my course on testing SOA seem to be much more interested in the technology aspects than they do the people and process aspects. This has been bothering me for some time now.
I agree that the technology seems to be progressing more than the human aspects. For example, getting the business folks to work better with the technology people is a big challenge in some companies. In fact, I think this is the big challenge of getting people to adopt agile methods as well.
The acticle goes on to state, "IT departments implement a SOA program that may be technically proficient but doesn't meet the needs of business users, Chris Howard said, noting that Burton Group is researching SOA successes and failures through interviews with IT pros and business executives at dozens of clients. Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said."
Interesting stuff, and it lines up with what I see as well.
Take a read and see what you think.
On a different note, yesterday (May 3) was the 9th anniversary of the F5 tornado which ripped across Oklahoma. It was a record-setting event, with sustained winds of over 318 mph and 40 deaths. There were 675 reported injuries. The damage estimate was 1.2 billion dollars. The outbreak spawned 66 tornadoes. The main tornado passed about 1 mile south of our home and was the closest I've ever been to a tornado. It was an awesome display of the fury of a tornado.
So today when the sirens sounded at noon, as they always do here on Saturdays, it brought back the feelings of taking cover and praying. (By the way, I learned that prayers get real short when an F5 tornado is bearing down on you!) That was quite a day for sure. I still use this as an example in my talk, "The Risks of Risk-Based Testing" as the kind of risk that is so far outside of the bounds that you don't even know how to plan for it.
I'll be posting all this coming week from StarEast, so stay tuned for updates!
The article quotes Anne Thomas Manes of the Burton Group in response to a question about what overriding message IT executives need to hear about Service-oriented Architecture (SOA).
"The problem's not technology, Howard said. People and processes are at the heart of what's wrong with SOA as it currently exists in enterprises."
I found it interesting that in an audience of around 300 people, only 6 indicated that their SOA efforts were proceeding well.
I can add my own observation that adds support to Manes' comments, that is, people in my course on testing SOA seem to be much more interested in the technology aspects than they do the people and process aspects. This has been bothering me for some time now.
I agree that the technology seems to be progressing more than the human aspects. For example, getting the business folks to work better with the technology people is a big challenge in some companies. In fact, I think this is the big challenge of getting people to adopt agile methods as well.
The acticle goes on to state, "IT departments implement a SOA program that may be technically proficient but doesn't meet the needs of business users, Chris Howard said, noting that Burton Group is researching SOA successes and failures through interviews with IT pros and business executives at dozens of clients. Business executives often conclude that IT pros exaggerate predictions of reusability or underestimate project cost, Howard said. IT professionals are generally bad at presenting the business case for SOA, and need to get better at explaining the long-term benefits in cost and flexibility to CEOs, he said."
Interesting stuff, and it lines up with what I see as well.
Take a read and see what you think.
On a different note, yesterday (May 3) was the 9th anniversary of the F5 tornado which ripped across Oklahoma. It was a record-setting event, with sustained winds of over 318 mph and 40 deaths. There were 675 reported injuries. The damage estimate was 1.2 billion dollars. The outbreak spawned 66 tornadoes. The main tornado passed about 1 mile south of our home and was the closest I've ever been to a tornado. It was an awesome display of the fury of a tornado.
So today when the sirens sounded at noon, as they always do here on Saturdays, it brought back the feelings of taking cover and praying. (By the way, I learned that prayers get real short when an F5 tornado is bearing down on you!) That was quite a day for sure. I still use this as an example in my talk, "The Risks of Risk-Based Testing" as the kind of risk that is so far outside of the bounds that you don't even know how to plan for it.
I'll be posting all this coming week from StarEast, so stay tuned for updates!
Monday, April 21, 2008
A Really Great Afternoon
This past weekend was tough. Saturday, I attended the memorial service for a long-time friend, Lowell Burch of Tulsa.
Lowell and I met in college over 30 years ago, and were "band buddies". Not the marching band kind, but the rock/bluegrass/Christian kind. Although, Lowell did play the trumpet, coronet and many other instruments very well. In fact, he taught band in schools.
We were both Beatles fans. We played a lot of their music and really liked talking Beatles trivia.
We also both liked cars. He was restoring his 1969 AMX (The same one he drove my wife and I in from our wedding to get to my car) and I'm restoring a 1949 Plymouth. We talked a lot about that, and sent pictures back and forth.
So, where's the "Great afternoon"? It was one month ago, almost to the day.
When I found out Lowell had stage 4 cancer, I knew I had to get there to spend some time with him. It was such a great blessing to spend the better part of the afternoon reminiscing about the past, laughing about past gigs and people we know, and even talking about the future. I'm glad that he was feeling well, looking good and was in high spirits.
The first thing I told his wife Susan last Saturday was how blessed I felt that we all had the time together. (Susan was part of the band, too.) She had such a great testimony when she asked me, "Isn't God good? We had that great time together!"
Lowell left a great legacy in his wife, his sons, his extended family and so many friends. As they said at the service, "Lowell made friends and he kept friends."
Fred Smith, one of my favorite authors on the topic of sucess, wrote that his definition of success if the ratio of gifts received to gifts used. I like that definition. Applied to Lowell, he was a huge success in many areas of life.
The reason I share all of this is because I learned some very important things over the years from Lowell, that I didn't realize until now. And this is just a partial list.
1) He taught me how to think outside of my own limits. Lowell was the ultimate "outside the box" kind of guy. When we needed a certain instrument in the band, Lowell encouraged me to try playing it, even if I mainly just played the guitar and banjo. He was very creative and always doing something different.
2) He taught me how to make friends unconditionally. Lowell knew no strangers.
3) He was a "contagious Christian". He was always sharing his faith with someone.
4) He held on to me a lot more than I held on to him. He would call me more than I would call him, but he was never resentful about being the one who had to call first. He would tell others about what I was doing, where I was travelling, etc.
5) He taught me that I need to stay in contact with my friends.
6) He taught me to be positive, because God is in control. Whatever happens, it will work together for our good and God's glory. This was his last lesson to me because I saw him live it out in his final days here on Earth.
All of this lessons will be a major part of my life. I don't believe you can separate "professional life" and "personal or spiritual life." They are too intertwined. Your professional actions reflect your personal spiritual values.
I hope you have someone in your life like this. If you do, call them this week or go visit, if possible.
If you knew Lowell, feel free to post your story.
He's in the best place, now. The land of an unclouded day. Man, I'm going to miss him!
Lowell and I met in college over 30 years ago, and were "band buddies". Not the marching band kind, but the rock/bluegrass/Christian kind. Although, Lowell did play the trumpet, coronet and many other instruments very well. In fact, he taught band in schools.
We were both Beatles fans. We played a lot of their music and really liked talking Beatles trivia.
We also both liked cars. He was restoring his 1969 AMX (The same one he drove my wife and I in from our wedding to get to my car) and I'm restoring a 1949 Plymouth. We talked a lot about that, and sent pictures back and forth.
So, where's the "Great afternoon"? It was one month ago, almost to the day.
When I found out Lowell had stage 4 cancer, I knew I had to get there to spend some time with him. It was such a great blessing to spend the better part of the afternoon reminiscing about the past, laughing about past gigs and people we know, and even talking about the future. I'm glad that he was feeling well, looking good and was in high spirits.
The first thing I told his wife Susan last Saturday was how blessed I felt that we all had the time together. (Susan was part of the band, too.) She had such a great testimony when she asked me, "Isn't God good? We had that great time together!"
Lowell left a great legacy in his wife, his sons, his extended family and so many friends. As they said at the service, "Lowell made friends and he kept friends."
Fred Smith, one of my favorite authors on the topic of sucess, wrote that his definition of success if the ratio of gifts received to gifts used. I like that definition. Applied to Lowell, he was a huge success in many areas of life.
The reason I share all of this is because I learned some very important things over the years from Lowell, that I didn't realize until now. And this is just a partial list.
1) He taught me how to think outside of my own limits. Lowell was the ultimate "outside the box" kind of guy. When we needed a certain instrument in the band, Lowell encouraged me to try playing it, even if I mainly just played the guitar and banjo. He was very creative and always doing something different.
2) He taught me how to make friends unconditionally. Lowell knew no strangers.
3) He was a "contagious Christian". He was always sharing his faith with someone.
4) He held on to me a lot more than I held on to him. He would call me more than I would call him, but he was never resentful about being the one who had to call first. He would tell others about what I was doing, where I was travelling, etc.
5) He taught me that I need to stay in contact with my friends.
6) He taught me to be positive, because God is in control. Whatever happens, it will work together for our good and God's glory. This was his last lesson to me because I saw him live it out in his final days here on Earth.
All of this lessons will be a major part of my life. I don't believe you can separate "professional life" and "personal or spiritual life." They are too intertwined. Your professional actions reflect your personal spiritual values.
I hope you have someone in your life like this. If you do, call them this week or go visit, if possible.
If you knew Lowell, feel free to post your story.
He's in the best place, now. The land of an unclouded day. Man, I'm going to miss him!
Thursday, April 17, 2008
Software Testing Disasters
Thanks to everyone who turned out at the Red Earth QA meeting today in Oklahoma City!
Here are the slides for my presentation, Testing Disasters and Turnarounds in PDF. I hope to have the audio available soon!
I'll be presenting this as a track session next month at StarEast, unless American Airlines grounds their fleet again.
Here are the slides for my presentation, Testing Disasters and Turnarounds in PDF. I hope to have the audio available soon!
I'll be presenting this as a track session next month at StarEast, unless American Airlines grounds their fleet again.
Monday, April 14, 2008
What Makes a Good Leader?
There's this ongoing debate/discussion that asks, "Are good leaders made or born?" I say "yes". What I mean is that some leaders have the gift, while others need to develop it. And then there are some people that should just never try to lead people, no matter what!
This past weekend I was talking with my friend Clint, who I have watched over the past 10 years grow into a great leader. He told me this amazing story and I think you'll also get something from it.
A few days ago, Clint's 10 year old daughter, Keegan, asked him if he could get her into see our pastor. You may be thinking "big deal, just talk to him after church." Well, we have a rather large church (30,000 people in 13 campus locations around the country), but Clint does have access. So, he asked her why. She said that she wanted to ask him what makes a good leader. Keep in mind that Keegan is ten years old. When I was 10, I was thinking about a new bike or something as trivial.
So, they worked it out. Actually, to be able to make the meeting, she had to get up at 6 a.m., but that was no problem at all for her.
Our pastor handled this as only he can. "Does anybody know where I can get a hug from a 10-year old?" She eagerly responded, "Hey, I'm 10!"
After the hug, she asked him the question, "What makes a good leader". His response was something like this:
"It takes three key things: 1) Integrity, so like when you have a test at school and somebody has the answers, you don't look at them, even if you know you won't get caught; 2) The ability to cast a vision clearly so others can see and follow it, and 3) Being a servant to the people you lead. They are not there for you, you are there for them."
Then he signed to her a copy of one of his books on finding God's purpose for life, and got another hug.
This story really impacted me in several ways.
First, what motivates a ten-year old to be bold enough to ask a question few adults ask?
Second, there are many books on leadership, but these three things boil it down nicely.
Third, a true leader always makes time for people.
I have a feeling that Keegan is already a leader, and if she keeps seeking and learning, she'll be a great one.
Now, what are you going to do today to be a leader?
This past weekend I was talking with my friend Clint, who I have watched over the past 10 years grow into a great leader. He told me this amazing story and I think you'll also get something from it.
A few days ago, Clint's 10 year old daughter, Keegan, asked him if he could get her into see our pastor. You may be thinking "big deal, just talk to him after church." Well, we have a rather large church (30,000 people in 13 campus locations around the country), but Clint does have access. So, he asked her why. She said that she wanted to ask him what makes a good leader. Keep in mind that Keegan is ten years old. When I was 10, I was thinking about a new bike or something as trivial.
So, they worked it out. Actually, to be able to make the meeting, she had to get up at 6 a.m., but that was no problem at all for her.
Our pastor handled this as only he can. "Does anybody know where I can get a hug from a 10-year old?" She eagerly responded, "Hey, I'm 10!"
After the hug, she asked him the question, "What makes a good leader". His response was something like this:
"It takes three key things: 1) Integrity, so like when you have a test at school and somebody has the answers, you don't look at them, even if you know you won't get caught; 2) The ability to cast a vision clearly so others can see and follow it, and 3) Being a servant to the people you lead. They are not there for you, you are there for them."
Then he signed to her a copy of one of his books on finding God's purpose for life, and got another hug.
This story really impacted me in several ways.
First, what motivates a ten-year old to be bold enough to ask a question few adults ask?
Second, there are many books on leadership, but these three things boil it down nicely.
Third, a true leader always makes time for people.
I have a feeling that Keegan is already a leader, and if she keeps seeking and learning, she'll be a great one.
Now, what are you going to do today to be a leader?
Thursday, April 10, 2008
Interesting Software Testing Survey from EuroStar 2007
I ran across an interesting survey that my friends Dorothy Graham and Mark Fewster conducted last December at EuroStar 2007, held in Stockholm. 620 attendees participated in the surveys.
You can download the survey results at:
http://www.qualtechconferences.com/content.asp?ID=263
It's interesting reading. Plus, I think it's great that Dorothy and Mark were able to conduct the survey and report the findings at the same conference. That's cool.
Here's what I found interesting:
59% of the respondents used to write code
43% held the ISEB/ISTQB Foundation Level certification
34% of those with certifications felt that they now know more about testing, and 25% have a better job
11% of the respondents saw the ISTQB certification as a money-making scheme, 49% felt that is shows a basic level of knowledge.
36% of the people have read at least half of 1 - 2 testing books, 20% have read none and 36% have read 3 - 10 books.
50% of the people do not measure the value of testing in their organizations
Well, those are just a few of the findings. I encourage you to download the report and read it yourself. We need to do something like this survey here in the U.S.
You can download the survey results at:
http://www.qualtechconferences.com/content.asp?ID=263
It's interesting reading. Plus, I think it's great that Dorothy and Mark were able to conduct the survey and report the findings at the same conference. That's cool.
Here's what I found interesting:
59% of the respondents used to write code
43% held the ISEB/ISTQB Foundation Level certification
34% of those with certifications felt that they now know more about testing, and 25% have a better job
11% of the respondents saw the ISTQB certification as a money-making scheme, 49% felt that is shows a basic level of knowledge.
36% of the people have read at least half of 1 - 2 testing books, 20% have read none and 36% have read 3 - 10 books.
50% of the people do not measure the value of testing in their organizations
Well, those are just a few of the findings. I encourage you to download the report and read it yourself. We need to do something like this survey here in the U.S.
Wednesday, April 09, 2008
ISTQB Software Testing Certification Training
I'm in Dallas this week working on a project that I can't talk about. Well, I could but then...OK, you know the line.
Funny thing. I was here last week and my car got pummelled with quarter-sized hail. About $1,500 in damage. Just got it estimated for repair on Monday. I hadn't been here two hours last night when another hail storm was heading my way. So...I dragged myself out into the rain and moved by already hail damaged car under the hotel entrance. Guess what? Nothing happened. Yea! All you people at the Hampton Inn owe me thanks for keeping the hail away.
I'm happy to announce that I have submitted my Foundation Level Course in Software Testing for accreditation. You can read the press release here.
Hopefully before long, I'll be able to display the ISTQB logo and really get out there promoting the course. My goal is to get as many people certified as possible.
Why?
I think everyone in the field of software testing has an opinion about certifications. I don't believe there is a single "right" perspective. What appeals to one person may not appeal to someone else.
I am CSTE #2, which means I was there at the start. I was a designer of the certification. I am now an officer of the ASTQB, which means I now support wholly the ISTQB program. A big reason I am behind the ISTQB program is because it is vendor-neutral. It's true that people (including me) will make money conducting training courses. But if I wasn't presenting this course, I would be presenting something else. However, no one company "owns" the certification. No vendor can just change the program. In fact, there are many training providers which gives you more options.
Training is not required to sit for the exam. However, I really believes it helps because you get immersion in the terminology and philosophy of the ISTQB syllabus.
Do test certifications help your career? It depends on your situation and your goals.
I know some test managers that could care less about people who are certified and I know others that are certain that having a certification increases their test team's image in the organization. Some people find great value in using test certification as setting a baseline of software testing terminology and practice in an organization. My belief is that having a certification is one way to stand out in your career.
I have personally had clients tell me the deciding factor in using my services was because I held a certification.
There have been debates on this topic, so there are views on all sides.
I have some really cool things in the works that I can't reveal just yet regarding ISTQB test certification training. I'll just say that I'm very excited about doing some things that no one else is doing in software testing!
If you want to get training in ISTQB Foundation Level Software Testing, call me at 405-691-8075, or contact me through my web site to discuss.
Have a great one!
Randy
Funny thing. I was here last week and my car got pummelled with quarter-sized hail. About $1,500 in damage. Just got it estimated for repair on Monday. I hadn't been here two hours last night when another hail storm was heading my way. So...I dragged myself out into the rain and moved by already hail damaged car under the hotel entrance. Guess what? Nothing happened. Yea! All you people at the Hampton Inn owe me thanks for keeping the hail away.
I'm happy to announce that I have submitted my Foundation Level Course in Software Testing for accreditation. You can read the press release here.
Hopefully before long, I'll be able to display the ISTQB logo and really get out there promoting the course. My goal is to get as many people certified as possible.
Why?
I think everyone in the field of software testing has an opinion about certifications. I don't believe there is a single "right" perspective. What appeals to one person may not appeal to someone else.
I am CSTE #2, which means I was there at the start. I was a designer of the certification. I am now an officer of the ASTQB, which means I now support wholly the ISTQB program. A big reason I am behind the ISTQB program is because it is vendor-neutral. It's true that people (including me) will make money conducting training courses. But if I wasn't presenting this course, I would be presenting something else. However, no one company "owns" the certification. No vendor can just change the program. In fact, there are many training providers which gives you more options.
Training is not required to sit for the exam. However, I really believes it helps because you get immersion in the terminology and philosophy of the ISTQB syllabus.
Do test certifications help your career? It depends on your situation and your goals.
I know some test managers that could care less about people who are certified and I know others that are certain that having a certification increases their test team's image in the organization. Some people find great value in using test certification as setting a baseline of software testing terminology and practice in an organization. My belief is that having a certification is one way to stand out in your career.
I have personally had clients tell me the deciding factor in using my services was because I held a certification.
There have been debates on this topic, so there are views on all sides.
I have some really cool things in the works that I can't reveal just yet regarding ISTQB test certification training. I'll just say that I'm very excited about doing some things that no one else is doing in software testing!
If you want to get training in ISTQB Foundation Level Software Testing, call me at 405-691-8075, or contact me through my web site to discuss.
Have a great one!
Randy
Monday, April 07, 2008
Making Software Testing Training Green
It's tough sometimes to break out of a mold. That's where we seem to be where training is concerned. Traditional classroom testing has the opportunity to be engaging, but too often it isn't. You have to work at it.
So when I start talking about e-learning, people get concerned about the interaction aspects. And interaction is important! It can be achieved with e-learning.
So when I start talking about e-learning, people get concerned about the interaction aspects. And interaction is important! It can be achieved with e-learning.
There are other considerations, such as environmental concerns. With e-learning:
- You eliminate travel, therefore reducing fuel used in airplanes and cars
- You eliminate the big books, therefore reducing the amount of trees used for paper
- You reduce or eliminate the need for a physical facility to heat or cool for a class of 15 or more peopleBut even above the environmental impact, you can save big money and get training that is just as effective as live training!
Then, there are time and cost concerns. E-learning can be scaled up much faster and broader that live on-site training. For example, with my e-learning courses, it is possible to train you entire worldwide test organization in one week for a small fraction of live in-person training.
I like the time-shifted approach. In fact, I believe on-demand content is essential to make e-learning effective. It's just too difficult to co-ordinate everyone's schedule to be connected at the same time. Plus, you eliminate many of the concurreny and performance issues of having many people accessing the same content at the same time. (On the launch of Oprah's new online training event with author Eckhart Tolle, author of "The New Earth", 500,000 people tried to access the event. "Tried" is the key word.)
While you won't have this type of load, you can still have problems with load.
My entire attitude toward training changed after 9/11. It was tough for anyone in the training business for some time because so many people were on travel restrictions. Many conferences were cancelled.
If fuel costs continue to soar, travel costs will also rise. E-learning just makes sense on a variety of levels.
If you want to learn more, check out my e-learning offerings in software testing, IEEE standards and user requiremnts here.
Speaking of green, here is my favorite fishing spot. 
It is Bear Lake, close to Cuchara, Colorado.
Wednesday, April 02, 2008
What Makes Software Testing Training Effective - Part 2
Today I did something that many of my friends have advised me to do for many years. I had my head examined. Really.
I had a brain MRI performed because I have tinnitus in my left ear and in order to rule out a tumor, I had to get this done to get life insurance.
The funny thing is that there was power surge about 10 minutes into the process and they had to "re-boot" the MRI machine. I told them not to worry. "It's not you, it's me! I'm a tester."
To add on to my last post about software test training effectiveness, I was thinking about something I've been intending to post for some time.
That is, to learn in small doses is more effective than trying to train in large chunks. Now, this is just the opposite to how many people think. They want to cram as much information as possible into a training day. The problem is that people start to suffer from information overload.
One of my mentors, Fred Smith, said that, "The best mentoring is intensity in a narrow field...learn, practice and assimilate." He used the example of how he used to dramatically improve the performance of salespeople by teaching just few simple techniques repetitively. Then, the people would go out and try them. When they came back, they all had glowing success stories.
It also reminds me of a friend who is a great guitarist who told me the secret to playing fast is to play slow.
So, for software testers, I suggest in really drilling down into one technique. In one of my intermediate testing courses, I spend two days just teaching and practicing pairwise testing. We spend about three hours on learning how to find the right size orthogonal array. We spend a hour on how to use some of the pairwise tools that are free. I guarantee you one thing. When the workshop is over (it's really not fair to call it a class), people know all about pairwise testing.
By the way, if you would like a taste of this class, attend my Tuesday half-day tutorial at StarEast in about a month.
You will find that some people want to just breeze through the material quickly. These people just want to cut to the chase. They are likely to get impatient when the class wants to discuss questions and observations - you know, where learning actually occurs! I like to set expectations by letting the class know that the goal is not to get through all the slides. It's to internalize the information. So, I encourage people to enjoy the journey!
Remember, another way to make training stick is to take it in sips instead of gulps!
I had a brain MRI performed because I have tinnitus in my left ear and in order to rule out a tumor, I had to get this done to get life insurance.
The funny thing is that there was power surge about 10 minutes into the process and they had to "re-boot" the MRI machine. I told them not to worry. "It's not you, it's me! I'm a tester."
To add on to my last post about software test training effectiveness, I was thinking about something I've been intending to post for some time.
That is, to learn in small doses is more effective than trying to train in large chunks. Now, this is just the opposite to how many people think. They want to cram as much information as possible into a training day. The problem is that people start to suffer from information overload.
One of my mentors, Fred Smith, said that, "The best mentoring is intensity in a narrow field...learn, practice and assimilate." He used the example of how he used to dramatically improve the performance of salespeople by teaching just few simple techniques repetitively. Then, the people would go out and try them. When they came back, they all had glowing success stories.
It also reminds me of a friend who is a great guitarist who told me the secret to playing fast is to play slow.
So, for software testers, I suggest in really drilling down into one technique. In one of my intermediate testing courses, I spend two days just teaching and practicing pairwise testing. We spend about three hours on learning how to find the right size orthogonal array. We spend a hour on how to use some of the pairwise tools that are free. I guarantee you one thing. When the workshop is over (it's really not fair to call it a class), people know all about pairwise testing.
By the way, if you would like a taste of this class, attend my Tuesday half-day tutorial at StarEast in about a month.
You will find that some people want to just breeze through the material quickly. These people just want to cut to the chase. They are likely to get impatient when the class wants to discuss questions and observations - you know, where learning actually occurs! I like to set expectations by letting the class know that the goal is not to get through all the slides. It's to internalize the information. So, I encourage people to enjoy the journey!
Remember, another way to make training stick is to take it in sips instead of gulps!
Subscribe to:
Posts (Atom)