I had lunch with my friend Frank today and I asked him his perspective on the Linchpin idea of being an artist and how that fits or conflicts with the ideas taught by Dr. Deming. Frank and I both like Dr. Deming's ideas a lot, so I am trying to set a context that makes sense.
In Linchpin, Seth Godin writes about becoming indispensable at our jobs by becoming more unique. We become more unique by letting the artist in us shine forth in what we do. Godin admits there are times you would not want this, like for airline pilots, etc. However, that specific example caused me to think about Captain Sullenberger who skillfully guided the U.S. Airways jet to a safe landing in the Hudson River. That was artistry. My friend Frank pointed out this was not because of his training from the airline, but because he knew how to fly gliders. Interesting.
In a factory setting, you want people making the same things in the same way. Dr. Deming taught people to remove variations in the process. He taught that processes should be so well defined that anyone with the right training could perform them with identical results. We can apply that in some ways to software development. So, how does one let their artistry shine in that kind of process-oriented environment?
Frank observed that Quality Circles was a technique Dr. Deming taught to let the workers in a process have a voice in improving it. Those people who are good at seeing problems and suggesting changes to the process that save the company money are linchpins and artists. You would not want people to start changing the process whenever or however they want, but you do want to know how to improve the process at the right time, in the right way.
Certainly Dr. Deming valued the person and how they contribute to quality. However, he was not a proponent of surviving by heroic efforts. The problem of heroic efforts is that is rewards those who do sloppy work and then swoop into to fix it, while those who consistently do good work get little recognition.
Unfortunately, too many good people suggest good ideas to management and those ideas are ignored. These people often leave for companies that do value their ideas. They can do that and get more money in the process because they add value. They are linchpins. This applies to leaders as well. Leaders who listen to ideas will rise and succeed, while those who don't will continue to struggle.
Your thoughts?
Randy
Thursday, April 08, 2010
Friday, April 02, 2010
Book Review - Linchpin by Seth Godin
For a long time I have been telling software testers there is someone out there, either in their city or halfway around the world, that can test faster and cheaper than they can. Like it or not, software testing has become a commodity for many organizations. It doesn’t matter who is doing the testing, how they are doing it, only that testing is being done at a cost they are willing to pay.
These are the same companies who call me up to get “two days of training on testing” then have no idea what their needs are, what will happened after the class, or even who will be the instructor. They just want “a pound of training” as I call it. This type of attitude means you need a point of distinction. That’s what this book is all about – how to become indispensable by letting the artist in you emerge.
Think of the companies that lay off hundreds or thousands of people all at once. How were those people chosen? They didn’t lay off everyone, so who got to stay and why? It wasn’t the people who obediently played by the rules and didn’t make waves. The ones who stayed were difference makers – linchpins.
This book takes you on a journey. It starts with some background of how we got here. After all, for all of human history except the last 60 years or so, people lived without the idea of being taken care of by a company. Now, we find ourselves in a different ballgame with a whole new set of rules. Having a good job is no longer the definition of success. Lots of “good jobs” have gone away, never to return.
The journey continues to discuss how to become that person that the company values so highly, they will do anything to keep you – the linchpin upon which there success depends.
Of course, becoming and staying a linchpin isn’t easy. There is a lot of resistance to stay in your comfort zone. Godin goes into detail about the choice required to become a linchpin and why it’s the choice between being remarkable and being a cheap drone.
The brilliant thing about this book is that Seth goes into depth about “the resistance”, the thing that keeps us from being unique and taking the risk to let our special gifts shine. It is so easy to want to blend in and go with the flow, but Seth makes a compelling case that this is the path toward extinction.
After reading the book and thinking of my experiences in consulting in many companies, I realize that the only difference between many companies and a chicken slaughterhouse is the lack of chickens. Every day people dutifully report for duty, keep their heads down, do what they are told to do (or not to do), then go home and do it all again the next day. The work is mindless, requires no creativity and at the end of the day, people leave unfulfilled and unappreciated – and a bit bloody.
At times I felt conflicted as I read Linchpin. I identify with being the artist. I tend to procrastinate, so the idea of setting a ship date for something and then shipping no matter what has actually helped to get some things done. On the other hand, I have seen so many companies suffer from the deadline mentality I can’t totally embrace that idea.
I think there is balance in the decision to ship or not to ship. In some cases, shipping bad stuff on the deadline can be very bad. In other cases, it can be the first faltering steps toward a great eventual product. I think it all depends on how understanding people are. For things like cars, airplanes and pacemakers, it’s a bad idea to ship just based on the deadline being reached.
The other point I have difficulty with is the idea of not being attached to your worldview. I agree that we need to be able to see and understand other people’s worldviews. My point of departure comes in being so unattached that you have no stable set of beliefs. I think it’s important to know why you hold your worldview and even be willing to question it. I also think it’s fine to be passionate about your beliefs. The key is whether or not your beliefs are based in truth. I know, I know, this opens up a great philosophical discussion about “what is truth?” I just think you can be a linchpin and still be true to your beliefs.
Finally, perhaps the most troubling realization of all is the contradiction of on my closely held beliefs in the idea of systematizing of processes. I really think Dr. Deming had it right about defining a process so that anyone could perform it without error. This is a good thing for factories, hospitals and fast food places that rely on consistency of results. However, when it comes to intellectual work, we need the creativity of the artist.
This leads me to the application of this idea to software testing. On one hand, we need high levels of accuracy and repeatability for some types of testing. On the other hand, we need the creativity of the artist for discovering new defects and ways of performing testing.
This is a great book, an essential book, for anyone in today’s marketplace. Both young and not-so-young will be better prepared to deal with the world by reading Linchpin. This is an easy read and I especially like the way Seth fleshes out his ideas in a stream of coherent small sections of writing. This alone has changed how I plan to write my future books - many of which now have publication dates! Thanks, Seth, for another insightful and timely book.
I will be continuing these thoughts here on my blog in the coming days, so come on and join the discussion!
Dirty Little Secrets About Software Test Estimation
I've been doing a lot of test estimation lately and it causes me to recall things that I have taught in the past about project estimation and test estimation, in particular. I call these things “Dirty Little Secrets” because they are things that many people know, but few people admit.
The context of this article is about software test estimation, but some of these secrets can be seen in other types of estimating as well. This list is not intended to be complete, but rather the things I see most often in trying to estimate software testing efforts.
Secret 1 – Your Estimate is Probably Wrong
Take comfort in this. Too many people work and work to get “just right” estimates. The problems are:
1) As a tester, your estimates often depend on other estimates, such as the time needed for development, people available, etc. These numbers are often inaccurate, so that means yours will be also.
On one project, I was asked to come up with some quick estimates on about 15 projects for a given business. To help in this effort, I was sent a set of 15 documents, each of which contained estimates for one of the projects to be estimated. My approach was to apply a factor of 25% of the total development effort. Now this factor could be considered low, since the actual percentages can range between 20 and 50%.
However, there was one thing that made my test effort factor practically irrelevant. Many of the prior estimates had “TBD” on the design and code efforts. This gap in data rendered my assumptions to the level of sheer guesswork. I had a bigger problem, though. My client still wanted estimates. What's a consultant to do?
In this case, I made some assumptions with a warning that the estimates could be way off. I estimated the effort to design the project equal to that of gathering and documenting requirements. I also made the effort to code the projects the same as the effort to design the project. Yes, this gave the same number for person-weeks for requirements, design and coding. Keep in mind I had no resource numbers at this point, only estimated weeks of effort. I documented my assumptions and also the low confidence I had in the estimate. I assured my client the estimate would change once we had numbers for design and coding. Plus, we would need resource estimates before we could estimate costs.
About a week later, I got the missing data. Not surprisingly, the newly supplied estimates for design and coding were different from the ones I assumed. So, I used the new numbers and my estimates changed. I have yet to know how accurate any of the estimates are at this point.
(By the way, as things turned out, none of the projects were ever started!)
2) The Project Scope Will Probably Change.
There's not much you can do about this. Scope change happens for a variety of reasons, some foreseen and some unforeseen.
You never know when new requirements will emerge. New opportunities can appear as well.
Last year, I had a fence installed at my home. When we first measured the dimension of the area to be fenced, I used the area that I had assumed was my property. Since there is not a house on the other side of us, I could not use the adjoining property as a basis. After reading the plat map, I learned that our property is actually about ten feet narrower than I had believed. For years, I have been watering, fertilizing and mowing about 1,000 square feet of property that did not belong to me!
This new information changed the scope and therefore, the estimate and final costs of the project.
Software projects are more complex than home improvements, and this makes the challenge even greater. Our assumptions get challenged and often proven wrong. Whether it is the scope of requirements or the number of resources needed, scope can change either up or down.
3) You Don't Know What You Don't Know.
And...you won't find that out until it's too late. This is one of the biggest project risks and impacts much more than estimates. There's not much you can do about this one either. Just keep an open mind, keep questioning decisions and information throughout the project. Realize that you don't know everything and what you do know will change.
Here are a couple of prime examples of project “surprises” :
Secret 2 – Your Estimate Needs to be Wrong – In the Right Direction
Why do I say something so outlandish? You only know how close your estimate is when the work is done. When my focus is on the accuracy of the estimate, I am at risk of conforming the work to the estimate, not what is in the best interest of the project.
When you truly understand your estimate is just that – an estimate, you can be free to adjust it. At least, you can adjust it for your own purposes if your management is not accepting of reality.
So what is the “right” direction? It's high.
There's an interesting debate among project managers as to whether or not it is ethical to “pad” estimates for the purpose of dealing with future unknown needs. Some believe you must have pads and others believe it is unethical to give an estimate you know is higher than you think is accurate.
I fall into the camp of overestimating. However, I don't call this extra a “pad”. Instead, I call it a “reserve” that is the safety net should extra time, money and/or people be needed. Even Scotty never gave Captain Kirk the real estimate!
I don't see this as deception. I see it as contingency planning and a necessary part of any estimate. In my experience, it's better to come in “under” than “over.”
It's funny that the people I know to be the best estimators have been doing it a long time and their estimates seem very high at first. I think these people have learned the lesson of having reserves in the estimate.
Secret 3 – The Recipient of the Estimate Already Has a Number in Mind
This is why I say that estimation of anything is an inherently human activity. There's a lot of feeling involved and not much logic at times.
Understand that your customer has an expectation already in mind. If your estimate goes too far above or below the customer's early expectation, silent alarms go off in their head.
In the case of my fence project, I had a number in mind. It wasn't a low price and it wasn't too far off from the estimate I received. When I did get the estimate, at least I didn't have sticker shock. Had my expectation been a lot lower that the estimate, I would have probably looked for a cheaper option.
Once I had an experience in which I gave an estimate that was so much lower than a competitor's and I almost didn't get the work! The prospective client felt that because of the lower price I must have been leaving something out. Thankfully, they asked me to explain why my quote was so much lower and I explained it was because I had a faster and more effective way of doing the job.
Secret 4 - Your Customer Assumes Your Estimate is Too High
This is one of the biggest hindrances to good estimation. Let's say that you do your best job of estimation with no reserves included. You present these to your management or customer and they take one look and immediately reduce it by one-half because they believe you must have inflated it. After all, the last person they got an estimate from did so. Therefore, the assumption is that everyone who estimates has excess in the numbers.
What does this do? It forces people to pad their estimates because they know management will assume they have been inflated. Therefore, it is a self-fulfilling prophecy.
Secret 5 – Your Estimates are Incomplete
Most people estimate time and cost. How many people do you know that also estimate the quality of the product? Not many I would guess.
You have probably heard the old adage, “cost, schedule, quality – pick two.”
While it's true that it's very hard to deliver all three aspects, it's still possible. High quality will probably cost more and may take longer than lower quality – at least in the short term. In the long run, high quality costs less because of lower maintenance.
In software development and testing, we often fail to consider the quality levels in a given estimate. For example, how much would a test cost that found a few defects and resulted in a buggy product versus one that found many defects (or found the right ones) and resulted in a high-quality product? More often than not we estimate how long testing will take, how many people we need, and how much testing will cost. A lot fewer people estimate how many defects they find at the various levels of criticality.
Conclusion
As you go forth and estimate, keep these little secrets in mind and you will have less stress over your estimates. If you look at how people respond to your estimates, you will see many of the secrets in action. These are things you can't control. However, you can understand that the dynamics exist and be prepared to keep expectations reasonable.
The context of this article is about software test estimation, but some of these secrets can be seen in other types of estimating as well. This list is not intended to be complete, but rather the things I see most often in trying to estimate software testing efforts.
Secret 1 – Your Estimate is Probably Wrong
Take comfort in this. Too many people work and work to get “just right” estimates. The problems are:
1) As a tester, your estimates often depend on other estimates, such as the time needed for development, people available, etc. These numbers are often inaccurate, so that means yours will be also.
On one project, I was asked to come up with some quick estimates on about 15 projects for a given business. To help in this effort, I was sent a set of 15 documents, each of which contained estimates for one of the projects to be estimated. My approach was to apply a factor of 25% of the total development effort. Now this factor could be considered low, since the actual percentages can range between 20 and 50%.
However, there was one thing that made my test effort factor practically irrelevant. Many of the prior estimates had “TBD” on the design and code efforts. This gap in data rendered my assumptions to the level of sheer guesswork. I had a bigger problem, though. My client still wanted estimates. What's a consultant to do?
In this case, I made some assumptions with a warning that the estimates could be way off. I estimated the effort to design the project equal to that of gathering and documenting requirements. I also made the effort to code the projects the same as the effort to design the project. Yes, this gave the same number for person-weeks for requirements, design and coding. Keep in mind I had no resource numbers at this point, only estimated weeks of effort. I documented my assumptions and also the low confidence I had in the estimate. I assured my client the estimate would change once we had numbers for design and coding. Plus, we would need resource estimates before we could estimate costs.
About a week later, I got the missing data. Not surprisingly, the newly supplied estimates for design and coding were different from the ones I assumed. So, I used the new numbers and my estimates changed. I have yet to know how accurate any of the estimates are at this point.
(By the way, as things turned out, none of the projects were ever started!)
2) The Project Scope Will Probably Change.
There's not much you can do about this. Scope change happens for a variety of reasons, some foreseen and some unforeseen.
You never know when new requirements will emerge. New opportunities can appear as well.
Last year, I had a fence installed at my home. When we first measured the dimension of the area to be fenced, I used the area that I had assumed was my property. Since there is not a house on the other side of us, I could not use the adjoining property as a basis. After reading the plat map, I learned that our property is actually about ten feet narrower than I had believed. For years, I have been watering, fertilizing and mowing about 1,000 square feet of property that did not belong to me!
This new information changed the scope and therefore, the estimate and final costs of the project.
Software projects are more complex than home improvements, and this makes the challenge even greater. Our assumptions get challenged and often proven wrong. Whether it is the scope of requirements or the number of resources needed, scope can change either up or down.
3) You Don't Know What You Don't Know.
And...you won't find that out until it's too late. This is one of the biggest project risks and impacts much more than estimates. There's not much you can do about this one either. Just keep an open mind, keep questioning decisions and information throughout the project. Realize that you don't know everything and what you do know will change.
Here are a couple of prime examples of project “surprises” :
- People will fudge numbers to make themselves look better. Realize this happens and always question information, whether it be bug counts, estimates or the time spent on testing a feature.
- Deliverables will be late. In fact, they will be later than you think they will. Some things will be early, but more often than not, your work will be delayed by delays experienced by others.
Secret 2 – Your Estimate Needs to be Wrong – In the Right Direction
Why do I say something so outlandish? You only know how close your estimate is when the work is done. When my focus is on the accuracy of the estimate, I am at risk of conforming the work to the estimate, not what is in the best interest of the project.
When you truly understand your estimate is just that – an estimate, you can be free to adjust it. At least, you can adjust it for your own purposes if your management is not accepting of reality.
So what is the “right” direction? It's high.
There's an interesting debate among project managers as to whether or not it is ethical to “pad” estimates for the purpose of dealing with future unknown needs. Some believe you must have pads and others believe it is unethical to give an estimate you know is higher than you think is accurate.
I fall into the camp of overestimating. However, I don't call this extra a “pad”. Instead, I call it a “reserve” that is the safety net should extra time, money and/or people be needed. Even Scotty never gave Captain Kirk the real estimate!
I don't see this as deception. I see it as contingency planning and a necessary part of any estimate. In my experience, it's better to come in “under” than “over.”
It's funny that the people I know to be the best estimators have been doing it a long time and their estimates seem very high at first. I think these people have learned the lesson of having reserves in the estimate.
Secret 3 – The Recipient of the Estimate Already Has a Number in Mind
This is why I say that estimation of anything is an inherently human activity. There's a lot of feeling involved and not much logic at times.
Understand that your customer has an expectation already in mind. If your estimate goes too far above or below the customer's early expectation, silent alarms go off in their head.
In the case of my fence project, I had a number in mind. It wasn't a low price and it wasn't too far off from the estimate I received. When I did get the estimate, at least I didn't have sticker shock. Had my expectation been a lot lower that the estimate, I would have probably looked for a cheaper option.
Once I had an experience in which I gave an estimate that was so much lower than a competitor's and I almost didn't get the work! The prospective client felt that because of the lower price I must have been leaving something out. Thankfully, they asked me to explain why my quote was so much lower and I explained it was because I had a faster and more effective way of doing the job.
Secret 4 - Your Customer Assumes Your Estimate is Too High
This is one of the biggest hindrances to good estimation. Let's say that you do your best job of estimation with no reserves included. You present these to your management or customer and they take one look and immediately reduce it by one-half because they believe you must have inflated it. After all, the last person they got an estimate from did so. Therefore, the assumption is that everyone who estimates has excess in the numbers.
What does this do? It forces people to pad their estimates because they know management will assume they have been inflated. Therefore, it is a self-fulfilling prophecy.
Secret 5 – Your Estimates are Incomplete
Most people estimate time and cost. How many people do you know that also estimate the quality of the product? Not many I would guess.
You have probably heard the old adage, “cost, schedule, quality – pick two.”
While it's true that it's very hard to deliver all three aspects, it's still possible. High quality will probably cost more and may take longer than lower quality – at least in the short term. In the long run, high quality costs less because of lower maintenance.
In software development and testing, we often fail to consider the quality levels in a given estimate. For example, how much would a test cost that found a few defects and resulted in a buggy product versus one that found many defects (or found the right ones) and resulted in a high-quality product? More often than not we estimate how long testing will take, how many people we need, and how much testing will cost. A lot fewer people estimate how many defects they find at the various levels of criticality.
Conclusion
As you go forth and estimate, keep these little secrets in mind and you will have less stress over your estimates. If you look at how people respond to your estimates, you will see many of the secrets in action. These are things you can't control. However, you can understand that the dynamics exist and be prepared to keep expectations reasonable.
Wednesday, February 24, 2010
Toyota and Software Problems
A very interesting drama is unfolding with Toyota over quality and safety issues. If anyone knows the quality process, it is Toyota. The mistake was not following the process and being in denial about problems really being problems even in the face of reality. Others are guilty, too. Ford, GM and Chrysler have all had issues - remember the Ford Pinto?
Here's the deal. More than ever, software is an integral part of the electronics that control cars. All software has defects. When a software defect causes a car to accelerate to 100+ mph, that's not a bug. That is catastrophic system failure. A few years back, Volvos were coming to dead stop at highway speeds because of software defects.
A friend of mine last year spent months trying to convince multiple Ford dealers that her Ford Expedition was stalling in the highway. They all said the Electronic Control Unit was fine. Eventually they found the problem - the ECU was bad.
The facts are not all in, but I would not be surprised if many of the Toyota problems are software defects.
My prediction for many years is that one day a major software failure will cause such death and destruction, that congress will start to regulate any software development with safety impact, much like is currently done in the FDA and NRC. The next big area of regulation will likely be transportation. Not that this is the answer. Regulations have fallen short because people find ways to get around them. Ultimately, quality is an ethical business issue.
For many, many years, Toyota has had a halo in terms of quality. Now that halo is gone and may never be recovered.
Keep an eye on this story.
Here's the deal. More than ever, software is an integral part of the electronics that control cars. All software has defects. When a software defect causes a car to accelerate to 100+ mph, that's not a bug. That is catastrophic system failure. A few years back, Volvos were coming to dead stop at highway speeds because of software defects.
A friend of mine last year spent months trying to convince multiple Ford dealers that her Ford Expedition was stalling in the highway. They all said the Electronic Control Unit was fine. Eventually they found the problem - the ECU was bad.
The facts are not all in, but I would not be surprised if many of the Toyota problems are software defects.
My prediction for many years is that one day a major software failure will cause such death and destruction, that congress will start to regulate any software development with safety impact, much like is currently done in the FDA and NRC. The next big area of regulation will likely be transportation. Not that this is the answer. Regulations have fallen short because people find ways to get around them. Ultimately, quality is an ethical business issue.
For many, many years, Toyota has had a halo in terms of quality. Now that halo is gone and may never be recovered.
Keep an eye on this story.
Thursday, February 18, 2010
ISTQB Advanced Level Certification Public Courses
If you hold the ISTQB Foundation Level certification (CTFL) and are ready to move to the next level in ISTQB software testing certification, we are offering advanced level courses in Oklahoma City staring in May, 2010.The courses offered are ISTQB Advanced Core (2 days) and ISTQB Advanced Analyst (3 days). To sit for the ISTQB Advanced Analyst Exam on the last day of the course, both courses must be completed.
To see the complete schedule of all courses and pricing, click here.
If you would like to have advanced courses in your city in the USA and have 6 or more people that can attend, contact me and I would be happy to schedule a class close to you.
To learn more about ISTQB Advanced Level Certification and the pre-requisites, please click here.
Rice Consulting Services has teamed with Grove Consultants (http://www.grove.co.uk) to provide an outstanding training experience for advanced level certification.
I will be the trainer for these courses. I bring over 20 years software testing training experience in major organizations worldwide, as well as holding the full CTAL certification. The materials are licensed from Grove Consultants in the U.K. If you have seen any conference tutorials or presentations by Grove Consultants, you know the high quality and engaging nature of their presentations and materials.
ISTQB Advanced Level testers are an elite group in the USA right now, so now is the time to join that special minority of software testers and managers!
Friday, February 12, 2010
Foundation Exam and Book Now Included in ISTQB e-Learning
Our students have great success in passing the exam. Every student has direct access to Randy by phone and/or e-mail to answer any questions along the way.
Click here to read more about the course.
Click here to take a free demo.
Click here to buy a registration for the course.
Tuesday, February 09, 2010
Instant Software Testing Metrics
There aren't any instant software testing metrics, at least none that give much meaning. If you are looking for instant testing metrics, sorry, this article won't provide them. I confess this title is a “hook” to get your attention. However, if you are willing to consider that it takes time to grow and understand metrics, then keep reading.
It seems that so many people I consult and train want quick and easy measures from their software development or testing efforts. I wish I had that shiny silver bullet, but in my experience and observation it takes time to really get the metrics in place that works for you and your organization.
And, really, you sure don't want to make decisions based on faulty information.
Here's why good metrics take time:
You Need History
At any point in time, a measurement is like taking one frame from a movie. For it to make sense, you need to see what has happened prior to the frame. To know how things turn out, you need to see what happens after the frame.
In software, this history starts when you start taking measurements. It continues as you keep measuring and refining your measurements.
The longer the history, the more accurate your understanding of your metrics tend to be. The key word is “understanding”. Your measurements may not necessarily get more accurate over time unless you keep questioning and improving them.
Too many people want to substitute other organizations' history for their own. I discourage this practice because every situation is different. Just because one company has a certain level of success with a given level of people or type of test technique doesn't mean you will have that same level of success.
Just start measuring a few key things that are easily obtainable and that are meaningful. It's important to track measures over time with specific dates associated with them. For example, you can start measuring the number of defects found by project. While this measure alone doesn't make a metric, you can start to see trends concerning the rate of defect discovery.
You Need Context
Metrics give context to measurements. A measure is a single count or extent of something, such as the number of defects. A metric is a measure taken in context with other measures. So, the average number of defects per function tells us the defect density from the functional perspective.
It takes time to know the best way to get this context and understand what it really means to you. I was once on a project where the client wanted to know how many test cases passed during a test. Fine. That's a good thing to know, right?
Then, people started to observe that the measure of passed tests has different meaning depending on when it is measured and reported. For example, a very high percentage of passed tests in the first round of testing may indicate the tests are too weak. Just before deployment, you want a high percentage of passed tests to indicate the application is ready to release. So, you may want to have two metrics: “first time tests that pass” and “final test pass percentage.”
You Need Time for Refinement
After you measure things for awhile, you may learn you aren't measuring the right things, or you may be measuring the right things in the wrong way.
It's fine and even expected to make major re-adjustments in your measurements. Just make sure to indicate on charts and tables when the adjustments were made.
You Need Growth
Please don't start a big metrics program with dozens of measurements. These programs often fail under their own weight. They are so big and complex, people either ignore them or give up quickly. Instead, start small and grow over time.
Metrics is a discipline that takes time and attention to do right. It also takes time to gain people's trust about how the metrics will be used. Sometimes people are fearful that the measures will be used against them, such as in a performance review.
You Need Early Successes
Pilot projects or proofs of concept are great to show the value of ideas and approaches. They reduce the risk of failure and gives you a place to practice and perfect things before trying them in the larger arena where everything becomes much more visible. It's a lot better to build positive public image based on small successes that to overcome the negative image from a major public failure.
You Need Management Understanding and Buy-in
As you grow and publish your metrics, management needs to learn the great value in them for the management of projects. Management also needs to get used to the information you can provide. They may suggest or request additional metrics or changes to existing ones. That's a good thing because it shows their minds are into the effort. This only happens over time.
Summary
I hope this shows why it takes time to get reliable and meaningful metrics. There are no magic answers, tools or techniques for getting a good set of metrics in place. That's why so few organizations reach this level. It's hard work and takes time, but it's worth the effort to show the added value you bring to your company. When you are “the” person that understands the metrics, that makes you a key person not only for your team, but for your company...and that's a very good thing!
It seems that so many people I consult and train want quick and easy measures from their software development or testing efforts. I wish I had that shiny silver bullet, but in my experience and observation it takes time to really get the metrics in place that works for you and your organization.
And, really, you sure don't want to make decisions based on faulty information.
Here's why good metrics take time:
You Need History
At any point in time, a measurement is like taking one frame from a movie. For it to make sense, you need to see what has happened prior to the frame. To know how things turn out, you need to see what happens after the frame.
In software, this history starts when you start taking measurements. It continues as you keep measuring and refining your measurements.
The longer the history, the more accurate your understanding of your metrics tend to be. The key word is “understanding”. Your measurements may not necessarily get more accurate over time unless you keep questioning and improving them.
Too many people want to substitute other organizations' history for their own. I discourage this practice because every situation is different. Just because one company has a certain level of success with a given level of people or type of test technique doesn't mean you will have that same level of success.
Just start measuring a few key things that are easily obtainable and that are meaningful. It's important to track measures over time with specific dates associated with them. For example, you can start measuring the number of defects found by project. While this measure alone doesn't make a metric, you can start to see trends concerning the rate of defect discovery.
You Need Context
Metrics give context to measurements. A measure is a single count or extent of something, such as the number of defects. A metric is a measure taken in context with other measures. So, the average number of defects per function tells us the defect density from the functional perspective.
It takes time to know the best way to get this context and understand what it really means to you. I was once on a project where the client wanted to know how many test cases passed during a test. Fine. That's a good thing to know, right?
Then, people started to observe that the measure of passed tests has different meaning depending on when it is measured and reported. For example, a very high percentage of passed tests in the first round of testing may indicate the tests are too weak. Just before deployment, you want a high percentage of passed tests to indicate the application is ready to release. So, you may want to have two metrics: “first time tests that pass” and “final test pass percentage.”
You Need Time for Refinement
After you measure things for awhile, you may learn you aren't measuring the right things, or you may be measuring the right things in the wrong way.
It's fine and even expected to make major re-adjustments in your measurements. Just make sure to indicate on charts and tables when the adjustments were made.
You Need Growth
Please don't start a big metrics program with dozens of measurements. These programs often fail under their own weight. They are so big and complex, people either ignore them or give up quickly. Instead, start small and grow over time.
Metrics is a discipline that takes time and attention to do right. It also takes time to gain people's trust about how the metrics will be used. Sometimes people are fearful that the measures will be used against them, such as in a performance review.
You Need Early Successes
Pilot projects or proofs of concept are great to show the value of ideas and approaches. They reduce the risk of failure and gives you a place to practice and perfect things before trying them in the larger arena where everything becomes much more visible. It's a lot better to build positive public image based on small successes that to overcome the negative image from a major public failure.
You Need Management Understanding and Buy-in
As you grow and publish your metrics, management needs to learn the great value in them for the management of projects. Management also needs to get used to the information you can provide. They may suggest or request additional metrics or changes to existing ones. That's a good thing because it shows their minds are into the effort. This only happens over time.
Summary
I hope this shows why it takes time to get reliable and meaningful metrics. There are no magic answers, tools or techniques for getting a good set of metrics in place. That's why so few organizations reach this level. It's hard work and takes time, but it's worth the effort to show the added value you bring to your company. When you are “the” person that understands the metrics, that makes you a key person not only for your team, but for your company...and that's a very good thing!
Free Virtual Conference on Application Performance Management
I'll be speaking at a FREE virtual conference on application performance on Feb 24 sponsored by SearchSoftwareQuality.com. My topic will be "Finding, Diagnosing, and Fixing Performance Bugs: Choosing Tools, Refining Best Practices."
Here's the announcement from SearchSoftwareQuality.com:
We're just 2 weeks away from the complimentary virtual seminar
'Application Performance Management: Build, Bug and Lifecycle
Strategies.' Gain access to industry experts and real-world
practitioners who reveal new insights to boost app performance and
ensure it remains a key focus throughout your application development
lifecycle.
Don't miss this opportunity - register here and mark your calendar:
http://go.techtarget.com/r/10840914/7113473
===============================================================
TITLE: Application Performance Management: Build, Bug and
Lifecycle Strategies
WHEN: Wednesday, February 24, 2010
TIME: 9:30 am - 6:00 pm EST
WHERE: Your Desktop
COST: Free
REGISTER FOR THIS VIRTUAL SEMINAR TODAY:
http://go.techtarget.com/r/10840915/7113473
===============================================================
TOP 5 REASONS TO ATTEND THE APPLICATION PERFORMANCE MANAGEMENT
VIRTUAL SEMINAR:
1. GET PRACTICAL INFORMATION TO USE IMMEDIATELY
Hear relevant advice that you can put into action right away to help
your organization build the foundation for high performance. No
pie-in-the-sky theories, just practical, useful information from
today's top performance experts.
2. EXPAND YOUR NETWORK OF PEERS
Share insights and discuss relevant strategies in our unique virtual
environment with those facing the same challenges you're up against
when testing and setting the stage for monitoring and maintaining
application performance throughout its lifecycle. Stop by the
networking lounge to hear success stories and lessons learned.
3. INTERACT WITH EXPERT SPEAKERS DURING OUR PANEL DISCUSSION
Discuss performance implications and testing tools for running
application components in private and public clouds. Don't go it
alone when you can benefit from the experience of these true
performance and cloud experts.
4. PRIZES!
Sessions are an intensive, educational experience that will prove
incredibly valuable to your organization, but we've built in some
fun, interactive breaks during which we'll announce our prize
winners. Attend the day's seminar for a chance to win a Sony
Cyber-shot camera, an Amazon.com gift card, or a book on dependency
injection. You'll have multiple chances to win - by visiting a booth,
attending a session and just for coming to the event!
5. INTERACT WITH TOP VENDORS
Speak directly to leading performance vendors and test drive the
latest solutions with live product demos. They understand your pain
points, and strive to help you make the best IT investments for your
organization.
Ensure quality in your application performance management. Register
with one click here:
http://go.techtarget.com/r/10840916/7113473
Here's the announcement from SearchSoftwareQuality.com:
We're just 2 weeks away from the complimentary virtual seminar
'Application Performance Management: Build, Bug and Lifecycle
Strategies.' Gain access to industry experts and real-world
practitioners who reveal new insights to boost app performance and
ensure it remains a key focus throughout your application development
lifecycle.
Don't miss this opportunity - register here and mark your calendar:
http://go.techtarget.com/r/10840914/7113473
===============================================================
TITLE: Application Performance Management: Build, Bug and
Lifecycle Strategies
WHEN: Wednesday, February 24, 2010
TIME: 9:30 am - 6:00 pm EST
WHERE: Your Desktop
COST: Free
REGISTER FOR THIS VIRTUAL SEMINAR TODAY:
http://go.techtarget.com/r/10840915/7113473
===============================================================
TOP 5 REASONS TO ATTEND THE APPLICATION PERFORMANCE MANAGEMENT
VIRTUAL SEMINAR:
1. GET PRACTICAL INFORMATION TO USE IMMEDIATELY
Hear relevant advice that you can put into action right away to help
your organization build the foundation for high performance. No
pie-in-the-sky theories, just practical, useful information from
today's top performance experts.
2. EXPAND YOUR NETWORK OF PEERS
Share insights and discuss relevant strategies in our unique virtual
environment with those facing the same challenges you're up against
when testing and setting the stage for monitoring and maintaining
application performance throughout its lifecycle. Stop by the
networking lounge to hear success stories and lessons learned.
3. INTERACT WITH EXPERT SPEAKERS DURING OUR PANEL DISCUSSION
Discuss performance implications and testing tools for running
application components in private and public clouds. Don't go it
alone when you can benefit from the experience of these true
performance and cloud experts.
4. PRIZES!
Sessions are an intensive, educational experience that will prove
incredibly valuable to your organization, but we've built in some
fun, interactive breaks during which we'll announce our prize
winners. Attend the day's seminar for a chance to win a Sony
Cyber-shot camera, an Amazon.com gift card, or a book on dependency
injection. You'll have multiple chances to win - by visiting a booth,
attending a session and just for coming to the event!
5. INTERACT WITH TOP VENDORS
Speak directly to leading performance vendors and test drive the
latest solutions with live product demos. They understand your pain
points, and strive to help you make the best IT investments for your
organization.
Ensure quality in your application performance management. Register
with one click here:
http://go.techtarget.com/r/10840916/7113473
Friday, February 05, 2010
Book Review - Managing the Testing Process, 3rd Ed. – Rex Black
Managing the Testing Process, 3rd. Ed. by Rex Black
Published by Wiley, 2009, 638 pages
In the third edition, Rex extends a work he started in 1998 with the first edition. At that time, and still today, practical books on software test management are in a minority of the books on software testing. This book has become a commonly referenced work on software test management for a reason - it is practical.
Two things I really like about this book are that it is very readable and it has broad coverage of test management topics. As a trainer of thousands of test managers, I have learned that many test managers are thrust into the role with little knowledge or preparation. So, my perspective is that test managers need to know the mechanics of the software test profession as well as the managerial and leadership aspects of the job. This book delivers well on both counts.
By reading and applying the information in this book, you will learn the testing process from test planning and building the test architecture to building a test team, measuring test results, and conveying those results in a value-added way. Rex covers topics that are very relevant including test outsourcing and the context of projects and software lifecycles. I also very much appreciate the discussion of dealing with the people issues in testing.
Just a note on the use of spreadsheets and vendor non-specific tool examples is that once you understand the structure of organizing testware, you can apply that structure in a specific test tool. Plus, not everyone owns a commercial test management tool. I know many people who manage a lot of test items using Excel.
I can highly recommend this book to test managers and leaders, as well as people who aspire to be in those roles.
Randy Rice
Wednesday, February 03, 2010
Software QA and Testing Salaries
A common question I get is about salaries for software testers here in the USA. Here is a place you can find that for your location - http://bit.ly/99nJtY
Wednesday, January 20, 2010
Articles of Interest
Here are two things I just read and really liked.
1) Here's a great slide show. Those of us who are in the software quality field will recognize the "7 Deadly Sins of IT" - http://www.cioinsight.com/c/a/IT-Management/Deadly-Sins-of-IT-Operations-658137/?kc=CIOMINUTE01202010CIO1
I think it's great to see this kind of thing in CIO Insight!
2) In my Becoming an Influential Test Team Leader workshop we talk about how to influence management. Here is a great article from Michael Hyatt on making a pitch to your boss: http://www.stumbleupon.com/su/4ff3lg/michaelhyatt.com/2007/01/how-to-get-your-boss%E2%80%99s-approval-when-you-need-it.html/r:t
Enjoy!
1) Here's a great slide show. Those of us who are in the software quality field will recognize the "7 Deadly Sins of IT" - http://www.cioinsight.com/c/a/IT-Management/Deadly-Sins-of-IT-Operations-658137/?kc=CIOMINUTE01202010CIO1
I think it's great to see this kind of thing in CIO Insight!
2) In my Becoming an Influential Test Team Leader workshop we talk about how to influence management. Here is a great article from Michael Hyatt on making a pitch to your boss: http://www.stumbleupon.com/su/4ff3lg/michaelhyatt.com/2007/01/how-to-get-your-boss%E2%80%99s-approval-when-you-need-it.html/r:t
Enjoy!
Wednesday, January 06, 2010
Tester to Developer Ratio Initial Research Findings
Thanks to everyone who provided data for my latest research project on tester to developer ratios. This topic has been an interest of mine for over ten years, when I did my first surveys on tester to developer ratios. The results of that survey and my thoughts at the time are in an article called, The Elusive Tester to Developer Ratio.
This short article is to document early findings and I plan to continue surveys and data gathering, so if you did not get in on the first round of surveying, I would like to hear about your ratios.
The participants of the recent survey were subscribers to my newsletter, The Software Quality Advisor, and the audience at my StarWest tutorial on Becoming an Influential Test Team Leader. There were 53 respondents in all, mostly from North America, but six were from Europe and one was from Asia.
I asked four questions:
1) How many developers are in your organization?
2) How many testers are in your organization?
3) On a scale of 1 to 6, where 1 is poor and 6 is super, how would you rate the effectiveness of your current ratio?
4) Do you have any anecdotal information about how your current ratio effectiveness?
The leanest ratio was twenty developers to one tester (effectiveness rating of “two”), while the richest ratio was fifteen developers to eighteen testers (effectiveness rating of “four”). There was one anomalous response of four developers to zero testers (The effectiveness rating on that one was “three”). The average ratio was 4.52 developers to one tester. The most common response was three developer to one tester (six responses), the next most common was 2.5 developers per tester (five responses). There were twenty-six responses with developer to tester ratios of 3:1 or lower.
Here are some of my initial observations and comments:
1) The responses varied greatly.
For those looking for an “industry norm” of developer to tester ratios, this may show that the range of workable ratios is wide. Effective testing may be achieved by better practices, tools and leveraging developer-based testing instead of having more testers.
2) Over half of the responses were at the “richer” ratios.
The average effectiveness reported by this group (3:1 or less) was four – above average. Interestingly, the average effectiveness for the higher ratios was three – average, and not a huge difference from the lower ratio group.
3) In the higher ratio group, there were some with higher than average test effectiveness of four or five.
This tells me that you have a higher ratio and still be effective at software testing. Put another way, the magic of good testing may not be in the ratio of developers to testers.
I have always questioned the idea of using developer to tester ratio as a way to staff or estimate testing efforts. Sheer body count is just not enough information to base testing effort upon.
That said, I think developer to tester ratios may be a helpful metric to understand the workload in a test organization. For example, if I were presented with a situation where the developer to tester ratio is ten to one, I would ask:
I did this on my first job as a test manager. I had a team of three people testing the work of thirty developers. The ten to one ratio told me that we could not test all the work coming our way.
We had no tools, just our wits. So, we developed a strategy:
1) Get management to lead the way to make the message to developers that testing is part of their job
2) Train and mentor each developer to be a good tester
3) Test the high risk changes at the highest priority
4) Test anything a developer asked us to test (unless there was no documentation)
5) Do not test anything without a defined user requirement
6) Use cause/effect graphing and other test optimization techniques to get the most testing from the fewest tests
7) Build a robust and repeatable test data set for manual regression testing
The result was that 1) we kept up with the workload and 2) the error rate went from 50% of changes with defects to 2%. At this point, we still had a ten to one developer to tester ratio. This may work for you, too. If it does, please send your check made out to Rice Consulting Services at P.O. Box 892003, Oklahoma City, OK 73170. :-)
I hope this information helps you understand your own ratio a little better. If you would like to contribute your own ratio to my data, just reply to me here with the four items:
1) How many developers are in your organization?
2) How many testers are in your organization?
3) On a scale of 1 to 6, where 1 is poor and 6 is super, how would you rate the effectiveness of your current ratio?
4) Do you have any anecdotal information about how your current ratio effectiveness?
Thanks!
This short article is to document early findings and I plan to continue surveys and data gathering, so if you did not get in on the first round of surveying, I would like to hear about your ratios.
The participants of the recent survey were subscribers to my newsletter, The Software Quality Advisor, and the audience at my StarWest tutorial on Becoming an Influential Test Team Leader. There were 53 respondents in all, mostly from North America, but six were from Europe and one was from Asia.
I asked four questions:
1) How many developers are in your organization?
2) How many testers are in your organization?
3) On a scale of 1 to 6, where 1 is poor and 6 is super, how would you rate the effectiveness of your current ratio?
4) Do you have any anecdotal information about how your current ratio effectiveness?
The leanest ratio was twenty developers to one tester (effectiveness rating of “two”), while the richest ratio was fifteen developers to eighteen testers (effectiveness rating of “four”). There was one anomalous response of four developers to zero testers (The effectiveness rating on that one was “three”). The average ratio was 4.52 developers to one tester. The most common response was three developer to one tester (six responses), the next most common was 2.5 developers per tester (five responses). There were twenty-six responses with developer to tester ratios of 3:1 or lower.
Here are some of my initial observations and comments:
1) The responses varied greatly.
For those looking for an “industry norm” of developer to tester ratios, this may show that the range of workable ratios is wide. Effective testing may be achieved by better practices, tools and leveraging developer-based testing instead of having more testers.
2) Over half of the responses were at the “richer” ratios.
The average effectiveness reported by this group (3:1 or less) was four – above average. Interestingly, the average effectiveness for the higher ratios was three – average, and not a huge difference from the lower ratio group.
3) In the higher ratio group, there were some with higher than average test effectiveness of four or five.
This tells me that you have a higher ratio and still be effective at software testing. Put another way, the magic of good testing may not be in the ratio of developers to testers.
I have always questioned the idea of using developer to tester ratio as a way to staff or estimate testing efforts. Sheer body count is just not enough information to base testing effort upon.
That said, I think developer to tester ratios may be a helpful metric to understand the workload in a test organization. For example, if I were presented with a situation where the developer to tester ratio is ten to one, I would ask:
- Are any test automation tools being used? If so, how effective are they?
- How much responsibility do developers have in the testing process?
- Is testing based on risk?
- Are test optimization techniques used in test design?
- What is the defect detection percentage (DDP)?
- Are defect trends tracked and studied?
- Have the developers and testers been trained in software testing?
- Is there a defined testing process in place and being used?
I did this on my first job as a test manager. I had a team of three people testing the work of thirty developers. The ten to one ratio told me that we could not test all the work coming our way.
We had no tools, just our wits. So, we developed a strategy:
1) Get management to lead the way to make the message to developers that testing is part of their job
2) Train and mentor each developer to be a good tester
3) Test the high risk changes at the highest priority
4) Test anything a developer asked us to test (unless there was no documentation)
5) Do not test anything without a defined user requirement
6) Use cause/effect graphing and other test optimization techniques to get the most testing from the fewest tests
7) Build a robust and repeatable test data set for manual regression testing
The result was that 1) we kept up with the workload and 2) the error rate went from 50% of changes with defects to 2%. At this point, we still had a ten to one developer to tester ratio. This may work for you, too. If it does, please send your check made out to Rice Consulting Services at P.O. Box 892003, Oklahoma City, OK 73170. :-)
I hope this information helps you understand your own ratio a little better. If you would like to contribute your own ratio to my data, just reply to me here with the four items:
1) How many developers are in your organization?
2) How many testers are in your organization?
3) On a scale of 1 to 6, where 1 is poor and 6 is super, how would you rate the effectiveness of your current ratio?
4) Do you have any anecdotal information about how your current ratio effectiveness?
Thanks!
Tuesday, December 08, 2009
Jim Rohn Has Left the Building
It was with sadness I learned of the passing this past weekend of a man that had a great influence on my life, Jim Rohn. Most technical people have never heard of Mr. Rohn, but he was a giant in the field of personal development. Jim was the picture of heath until a couple of years ago when he was diagnosed with pulmonary fibrosis. He was 79.
As not only a software tester, but a business owner, I learned early on that I had to learn about what it means to be successful in business. Not in a greedy way, but in a way that helps others. Mr. Rohn taught me how to do that.
I'm not a believer in "The Secret" - the idea that you attract the things that come into your life - good and bad. (I do believe we can attract certain things by what we do, but that's different.) Anyway, I did have an experience that was amazing in the realm of goals.
I started Rice Consulting back in 1990 with no idea of where it would lead or even if it would be successful. I just knew that very few consultants and trainers specialized in testing at that time.
Before long, I realized my business lacked direction and control, so I started looking for how to get that positive direction. One resource I found was a tape set called "The Art of Exceptional Living" by Jim Rohn. I listened to those tapes at least a dozen times while I would be on walks, driving, etc. In fact, I still listen to them on occasion.
I thought, "I would sure like to meet Mr. Rohn in person one day." Then, amazingly about six months later he came to Oklahoma City to present a half-day session on The Seasons of Life. I bought the VIP ticket so I could attend a pre-event reception. I remember like yesterday seeing Mr. Rohn standing at the side of the room with no one else around, so I introduced myself and asked if it was OK to ask a question. He graciously said, "Of course."
I asked Mr. Rohn a question I would not have asked anyone else because I knew he came from the same spiritual perspective as me. "Do you think it is possible to be too rich?" I asked.
He paused, pursed his lips and said, "Well...let me see...Is it possible to be too happy? Or too healthy? Or have too many good relationships? No...I don't think you can be too rich."
Now, context is important here. I had heard Jim's teaching on "enlighted wealth" where it's not the accumulation of prosperity for the sake of ourselves, so I knew he was not advocating wealth at any cost. I was just curious because of my lower middle class background and past spiritual teachings.
Since then, I have heard him say that humans are the only creatures that place limits on their own growth. So, it would be like asking, "Can a tree grow too tall?"
Jim was the person that taught me the importance of communication and how ideas are conveyed. He also taught me that it's possible to create something tangible from something intangible, like an idea.
Jim touched millions of people around the world. If you would like to see the tributes, there are many at http://tribute.jimrohn.com/. There are also some video clips there of his teaching. If you are inspired and want to go deeper, I highly recommend "The Art of Exceptional Living (abridged version)" or full version as a starting point.
Jim Rohn will be missed, but he left a legacy of teaching that will endure for a long, long time. I know he is in a better place.
As not only a software tester, but a business owner, I learned early on that I had to learn about what it means to be successful in business. Not in a greedy way, but in a way that helps others. Mr. Rohn taught me how to do that.
I'm not a believer in "The Secret" - the idea that you attract the things that come into your life - good and bad. (I do believe we can attract certain things by what we do, but that's different.) Anyway, I did have an experience that was amazing in the realm of goals.
I started Rice Consulting back in 1990 with no idea of where it would lead or even if it would be successful. I just knew that very few consultants and trainers specialized in testing at that time.
Before long, I realized my business lacked direction and control, so I started looking for how to get that positive direction. One resource I found was a tape set called "The Art of Exceptional Living" by Jim Rohn. I listened to those tapes at least a dozen times while I would be on walks, driving, etc. In fact, I still listen to them on occasion.
I thought, "I would sure like to meet Mr. Rohn in person one day." Then, amazingly about six months later he came to Oklahoma City to present a half-day session on The Seasons of Life. I bought the VIP ticket so I could attend a pre-event reception. I remember like yesterday seeing Mr. Rohn standing at the side of the room with no one else around, so I introduced myself and asked if it was OK to ask a question. He graciously said, "Of course."
I asked Mr. Rohn a question I would not have asked anyone else because I knew he came from the same spiritual perspective as me. "Do you think it is possible to be too rich?" I asked.
He paused, pursed his lips and said, "Well...let me see...Is it possible to be too happy? Or too healthy? Or have too many good relationships? No...I don't think you can be too rich."
Now, context is important here. I had heard Jim's teaching on "enlighted wealth" where it's not the accumulation of prosperity for the sake of ourselves, so I knew he was not advocating wealth at any cost. I was just curious because of my lower middle class background and past spiritual teachings.
Since then, I have heard him say that humans are the only creatures that place limits on their own growth. So, it would be like asking, "Can a tree grow too tall?"
Jim was the person that taught me the importance of communication and how ideas are conveyed. He also taught me that it's possible to create something tangible from something intangible, like an idea.
Jim touched millions of people around the world. If you would like to see the tributes, there are many at http://tribute.jimrohn.com/. There are also some video clips there of his teaching. If you are inspired and want to go deeper, I highly recommend "The Art of Exceptional Living (abridged version)" or full version as a starting point.
Jim Rohn will be missed, but he left a legacy of teaching that will endure for a long, long time. I know he is in a better place.
Tuesday, November 24, 2009
Back in the USA, Flu and all
Hi Folks,
It's good to be back in the USA. The courses in Rome went very well. It's always fun and the people are super, but also a challenging adjustment to be teaching from 2 a.m. to 10 a.m. body time. It's also nice to do things without converting time, money, language or electricity.
Janet went with me on the trip and we saw some sights both in London and Rome. I was able for the fifth or sixth straight year to get my annual journal at Harrods. It winds up costing me about $50, but that's a motivator to actually use it. That has become a tradition for me.
I promised Janet that the first thing I would do is buy a cup of Starbucks coffee in NYC, since we arrived at JFK, took a taxi to LaGuardia and then after spending the night at a really nice Hampton Inn (I'm serious, it was great), on to DFW and OKC. All went well until DFW, then the flu hit me and the last thing I wanted was coffee. Those who know me know coffee is a very, very important thing to me, so Janet knew I was sick. That and wearing a coat while shivering.
I went to the doctor yesterday and he confirmed flu, but not sure of "regular" or "swine". He percribed Tamiflu and I'm feeling much better today, so I'm thinking "regular".
Back to the coffee...The gentle bagage handlers managed to break my French press on the way back home. Also, I took several packets of the new Starbucks VIA instant coffee on the trip and it helped. I give the Starbucks people credit for a good instant coffee. It's not that I hate Italian coffee, it just that the intensity is pretty strong - basically expresso.
I plan to return there in June to teach Innovative Software Testing Approaches, one I've taught there before, and Practical Software Test Automation, a new class for the spring I am very excited about.
Well, back to resting some. By the way, I'll be posting soon the prelimiary research on the tester to developer ratios.
Until then, I wish all in the USA a blessed Thanksgiving!
It's good to be back in the USA. The courses in Rome went very well. It's always fun and the people are super, but also a challenging adjustment to be teaching from 2 a.m. to 10 a.m. body time. It's also nice to do things without converting time, money, language or electricity.
Janet went with me on the trip and we saw some sights both in London and Rome. I was able for the fifth or sixth straight year to get my annual journal at Harrods. It winds up costing me about $50, but that's a motivator to actually use it. That has become a tradition for me.
I promised Janet that the first thing I would do is buy a cup of Starbucks coffee in NYC, since we arrived at JFK, took a taxi to LaGuardia and then after spending the night at a really nice Hampton Inn (I'm serious, it was great), on to DFW and OKC. All went well until DFW, then the flu hit me and the last thing I wanted was coffee. Those who know me know coffee is a very, very important thing to me, so Janet knew I was sick. That and wearing a coat while shivering.
I went to the doctor yesterday and he confirmed flu, but not sure of "regular" or "swine". He percribed Tamiflu and I'm feeling much better today, so I'm thinking "regular".
Back to the coffee...The gentle bagage handlers managed to break my French press on the way back home. Also, I took several packets of the new Starbucks VIA instant coffee on the trip and it helped. I give the Starbucks people credit for a good instant coffee. It's not that I hate Italian coffee, it just that the intensity is pretty strong - basically expresso.
I plan to return there in June to teach Innovative Software Testing Approaches, one I've taught there before, and Practical Software Test Automation, a new class for the spring I am very excited about.
Well, back to resting some. By the way, I'll be posting soon the prelimiary research on the tester to developer ratios.
Until then, I wish all in the USA a blessed Thanksgiving!
Sunday, October 25, 2009
Join Me in Rome for Software Testing Courses in November
Hi everyone,
For those of you in Europe, or anyone interested in visiting Rome and attending a testing class, here's your chance. On November 16 - 20, I'll be presenting two popular courses:
Testing SOA (Nov. 16 - 17, 2009)
Advanced Software Testing (Nov. 18 - 20, 2009)
Just click on the links above for more information and to register go to www.technologytransfer.eu.
I hope to see you there!Randy
Tuesday, October 20, 2009
EuroStar 2009 Software Testing Conference Ticket on eBay!
Hi everyone,
Here's a great deal, especially for those of you reading this in Europe. Last year, I won a conference pass to this year's EuroStar Testing Conference to be held in Stockholm, Sweden.
I can't use the pass this year, so I have placed it up for auction on eBay. The starting price is $500 and the auction lasts for 10 days. So, if you are looking for a great deal on a great conference, here's your chance!
http://global.ebay.com/EuroStar_2009_Testing_Conference_-_Stockholm_Sweden/190346246440/item
Thanks,
Randy
Here's a great deal, especially for those of you reading this in Europe. Last year, I won a conference pass to this year's EuroStar Testing Conference to be held in Stockholm, Sweden.
I can't use the pass this year, so I have placed it up for auction on eBay. The starting price is $500 and the auction lasts for 10 days. So, if you are looking for a great deal on a great conference, here's your chance!
http://global.ebay.com/EuroStar_2009_Testing_Conference_-_Stockholm_Sweden/190346246440/item
Thanks,
Randy
Tuesday, October 13, 2009
Major Apple Snow Leopard Defect...Warning
Hi all,
I'm not one of those Mac users who downplay the problems just to make the Mac look better than a PC! There is a major problem with Snow Leopard that everyone should be aware of. Under Snow Leopard when you log into a guest account, you lose all your data. I think this may have happened to my son. All I know is he lost everything, too. Here is a full account of the problem from Computerworld:
http://www.computerworld.com/s/article/9139250/Snow_Leopard_bug_deletes_all_user_data?source=CTWNLE_nlt_pm_2009-10-12
So...if you have upgraded to Snow Leopard, keep making those backups and don't log in to a guest account! Oh, and to Apple...fix it!!! I can see the new Mac vs. PC commercials now (of course, it would need to be a parody since Apple won't make an ad where their guy just disappears!).
I'm not one of those Mac users who downplay the problems just to make the Mac look better than a PC! There is a major problem with Snow Leopard that everyone should be aware of. Under Snow Leopard when you log into a guest account, you lose all your data. I think this may have happened to my son. All I know is he lost everything, too. Here is a full account of the problem from Computerworld:
http://www.computerworld.com/s/article/9139250/Snow_Leopard_bug_deletes_all_user_data?source=CTWNLE_nlt_pm_2009-10-12
So...if you have upgraded to Snow Leopard, keep making those backups and don't log in to a guest account! Oh, and to Apple...fix it!!! I can see the new Mac vs. PC commercials now (of course, it would need to be a parody since Apple won't make an ad where their guy just disappears!).
Thursday, October 08, 2009
StarWest 2009
Hi Friends,
I'm returning home from StarWest 2009 and found some time to blog as we are delayed out of Orange Country airport by about 3 hours.
It was a good conference. I was glad to see a higher attendance than at StarEast this year. In fact, the conference had a good feel for the week attendance-wise. It makes me hopeful that the economy is coming back.
There also seemed to be quite a few international attendees and people from the central and eastern parts of the U.S.
My Monday tutorial on Becoming an Influential Test Team leader went well and the two track sessions (one on Cheap and Free Test Tools and the other on Making Your Defects Pay) seemed to go well also. It's always great to meet new people and hopefully provide some helpful information.
It was also great to connect with friends. I really enjoyed Lloyd Roden's keynote on Top Testing Challenges. He and I approach the challenges from different perspectives, mine from a survey basis and Lloyd's from an observation perspective, but I really have a lot to think about from his session. I have been working a lot with test metrics lately and Lloyd's thoughts on making metrics meaningful and accurate is one that we should all take to heart. Everyone talks about test metrics, but few understand the work it takes to define them for a particular organization. I'll blog more about that later.
I also enjoyed Julie Gardner's session on test environments. Very few people tackle that topic in a conference setting and she did a good job on striking a balance of covering the topic without getting too specific.
I heard several people say they had a hard time deciding which sessions to attend. To me, that's the sign of a good program. It seemed that people were picking up lots of good testing tips and techniques.
The vendor expo was pretty well attended by vendors and attendees. Once again, another hopeful sign of an economic recovery.
So, I give the conference high marks. Kudos to SQE for a great conference.
On my free day, Tuesday, Janet and I went to a taping of the Jay Leno Show, but got there a little late. So, instead being part of the studio audience, we got to watch the outdoor segment where Tim Allen raced a Ford electric car. That was fun. We were just a few feet away from Tim and Jay and we were on camera, too. Last year, Jay waved at us at the stop light as he was one his way home driving his Arial Atom hot-rod.
http://www.thejaylenoshow.com/video/episodes/#vid=1164214/?__source=recent-eps-module
Later,
Randy
I'm returning home from StarWest 2009 and found some time to blog as we are delayed out of Orange Country airport by about 3 hours.
It was a good conference. I was glad to see a higher attendance than at StarEast this year. In fact, the conference had a good feel for the week attendance-wise. It makes me hopeful that the economy is coming back.
There also seemed to be quite a few international attendees and people from the central and eastern parts of the U.S.
My Monday tutorial on Becoming an Influential Test Team leader went well and the two track sessions (one on Cheap and Free Test Tools and the other on Making Your Defects Pay) seemed to go well also. It's always great to meet new people and hopefully provide some helpful information.
It was also great to connect with friends. I really enjoyed Lloyd Roden's keynote on Top Testing Challenges. He and I approach the challenges from different perspectives, mine from a survey basis and Lloyd's from an observation perspective, but I really have a lot to think about from his session. I have been working a lot with test metrics lately and Lloyd's thoughts on making metrics meaningful and accurate is one that we should all take to heart. Everyone talks about test metrics, but few understand the work it takes to define them for a particular organization. I'll blog more about that later.
I also enjoyed Julie Gardner's session on test environments. Very few people tackle that topic in a conference setting and she did a good job on striking a balance of covering the topic without getting too specific.
I heard several people say they had a hard time deciding which sessions to attend. To me, that's the sign of a good program. It seemed that people were picking up lots of good testing tips and techniques.
The vendor expo was pretty well attended by vendors and attendees. Once again, another hopeful sign of an economic recovery.
So, I give the conference high marks. Kudos to SQE for a great conference.
On my free day, Tuesday, Janet and I went to a taping of the Jay Leno Show, but got there a little late. So, instead being part of the studio audience, we got to watch the outdoor segment where Tim Allen raced a Ford electric car. That was fun. We were just a few feet away from Tim and Jay and we were on camera, too. Last year, Jay waved at us at the stop light as he was one his way home driving his Arial Atom hot-rod.
http://www.thejaylenoshow.com/video/episodes/#vid=1164214/?__source=recent-eps-module
Later,
Randy
Monday, August 31, 2009
Mac Snow Leopard and Parallels 3.0
Hi Folks,
Sorry for the long delay in posting. I've been busy...really, busy.
This past weekend I installed Snow Leopard on my Mac Book and overall, have been happy with it. One problem that I want to warn people about is an incompatibility with Parallels 3.0.
Apple lists incompatibility with Parallels 2.5 and earlier, but when I upgraded and then tried to access Parallels, I got an incompatibility message. Postings at Parallels forum have been ignored on this issue, so before you upgrade to Snow Leopard, you would be wise to upgrade to Parallels 4.0 first.
The good news for me is that I basically abandoned Parallels several months ago due to instability and bugs. I have found VM Ware to be much more stable. That one works just fine under Snow Leopard.
You will likely find other incompatibilities, especially with open source software. So, take those backups.
More to come very soon...
Randy
Sorry for the long delay in posting. I've been busy...really, busy.
This past weekend I installed Snow Leopard on my Mac Book and overall, have been happy with it. One problem that I want to warn people about is an incompatibility with Parallels 3.0.
Apple lists incompatibility with Parallels 2.5 and earlier, but when I upgraded and then tried to access Parallels, I got an incompatibility message. Postings at Parallels forum have been ignored on this issue, so before you upgrade to Snow Leopard, you would be wise to upgrade to Parallels 4.0 first.
The good news for me is that I basically abandoned Parallels several months ago due to instability and bugs. I have found VM Ware to be much more stable. That one works just fine under Snow Leopard.
You will likely find other incompatibilities, especially with open source software. So, take those backups.
More to come very soon...
Randy
Wednesday, May 27, 2009
Where's My Gate?
Hi Folks,
I travel a lot. I have almost 2 million program miles just on American.
A couple of weeks ago, I experienced a new one. My wife and I were returning from Orlando and StarEast, connecting through DFW on American. (By the way, we had a great week at StarEast. It was good to see everyone.)
We were stranded in DFW on Friday evening due to the flight being delayed from Orlando so we stayed at the Hyatt in Terminal D. On Saturday morning we cleared security in Terminal D and saw that our gate to OKC was A22. So, we hopped on the SkyTrain and went to Terminal A. As we were walking to the gate, I looked at the monitors and saw to my dismay that the flight to OKC was leaving from gate D28. "Crap", I thought (and said, I think). I looked again just to make sure I wasn't looking at arrivals. Nope, it was D28.
So, we went back to Terminal D. As a sanity check, I looked again at the monitors and the flight was listed at gate A22. The information man must have seem my stunned look and asked if he could help. When I asked "Yes, which gate is the flight to Oklahoma City really leaving from?" He said, "Gate A22, just like it says there." I tried explaining that in Terminal A, the monitors said something different. By then, my wife was threatening to file for divorce.
We verified there was no plane at gate D28 heading to OKC, so BACK we went to A22. Finally, at gate A22 (my critical mistake was not actually going to gate A22 the first time), I told the gate agent that the monitor was showing the wrong gate. Her response? "Oh, those are wrong all the time."
Here's my question. Shouldn't the monitors be getting the data from the same source? Second question. If these are wrong "all the time" should someone be looking in to that? Oh well...at least we made it home. I just won't be quite as trusting in the future.
Now for something completely different....
I keep finding these great videos I intend to share and never get around to it. You really need to check these out.
The "Retroincabulator" - This must have been filmed for the Rockwell Christmas party!
http://www.youtube.com/watch?v=pb7OWlVYYRw
If you liked that, check this one out as well: http://www.youtube.com/watch?v=rLDgQg6bq7o
Watch your grammar. Otherwise, you may be visited by the grammar police!
http://www.youtube.com/watch?v=u9_kahA_wQo
Here is amazing one. Three guys playing one guitar!
http://www.youtube.com/watch?v=lrpwDvuNWro
Finally...Do you have ping pong ball skills? These guys do!
http://www.youtube.com/watch?v=LLByTnNwico
OK...now back to work! Have a great week!
Randy
I travel a lot. I have almost 2 million program miles just on American.
A couple of weeks ago, I experienced a new one. My wife and I were returning from Orlando and StarEast, connecting through DFW on American. (By the way, we had a great week at StarEast. It was good to see everyone.)
We were stranded in DFW on Friday evening due to the flight being delayed from Orlando so we stayed at the Hyatt in Terminal D. On Saturday morning we cleared security in Terminal D and saw that our gate to OKC was A22. So, we hopped on the SkyTrain and went to Terminal A. As we were walking to the gate, I looked at the monitors and saw to my dismay that the flight to OKC was leaving from gate D28. "Crap", I thought (and said, I think). I looked again just to make sure I wasn't looking at arrivals. Nope, it was D28.
So, we went back to Terminal D. As a sanity check, I looked again at the monitors and the flight was listed at gate A22. The information man must have seem my stunned look and asked if he could help. When I asked "Yes, which gate is the flight to Oklahoma City really leaving from?" He said, "Gate A22, just like it says there." I tried explaining that in Terminal A, the monitors said something different. By then, my wife was threatening to file for divorce.
We verified there was no plane at gate D28 heading to OKC, so BACK we went to A22. Finally, at gate A22 (my critical mistake was not actually going to gate A22 the first time), I told the gate agent that the monitor was showing the wrong gate. Her response? "Oh, those are wrong all the time."
Here's my question. Shouldn't the monitors be getting the data from the same source? Second question. If these are wrong "all the time" should someone be looking in to that? Oh well...at least we made it home. I just won't be quite as trusting in the future.
Now for something completely different....
I keep finding these great videos I intend to share and never get around to it. You really need to check these out.
The "Retroincabulator" - This must have been filmed for the Rockwell Christmas party!
http://www.youtube.com/watch?v=pb7OWlVYYRw
If you liked that, check this one out as well: http://www.youtube.com/watch?v=rLDgQg6bq7o
Watch your grammar. Otherwise, you may be visited by the grammar police!
http://www.youtube.com/watch?v=u9_kahA_wQo
Here is amazing one. Three guys playing one guitar!
http://www.youtube.com/watch?v=lrpwDvuNWro
Finally...Do you have ping pong ball skills? These guys do!
http://www.youtube.com/watch?v=LLByTnNwico
OK...now back to work! Have a great week!
Randy
Subscribe to:
Posts (Atom)