THIS FINISHED PRODUCT IS NOT TESTED ON ANIMALS.
What does that mean? Talk about ambiguous. I have several questions for the maker of the body wash this statement, in all caps, was written on:
1. Was the unfinished product tested on animals?
2. What does "on animals" mean? A microscope on an animals back? Was an animal washed in the "unfinished" product?
3. Will my dog be allergic to the "finished" product?
4. If I cannot wash my "animal" with the product, is it safe for me to wash myself with it?
5. What type of "testing" are you talking about?
6. Does "is not" mean "never was"?
7. Who or what did you test the "finished product" on? And, did they or it live?
Now, wasn't that a fun two-minute examination of documentation? Find something that is "simply accepted" to ask questions about today. Question everything... and smile while you do it because you know how much it irks others ;-)
Followers
Thursday, May 28, 2009
Monday, May 25, 2009
Consider the Ordinary
For as far back as I can remember I have hated dandelions. An obnoxious weed that fought hard with me for my lawn. I would stop at nothing to win this summer long game. When my older children were younger I would pay them a penny for each dandelion they uprooted and gave to me. I used every possible method I could find to combat these foes of meticulously manicured lawns.
Two weeks ago when I went to mow my lawn, my youngest child began running around the yard picking as many dandelions as she could carry. Because this behavior was odd in a funny way, I asked her what she was doing. She told me she was saving the flowers. (Adults know that picking flowers does not do anything to enhance or promote their life.)
I have thought about this display of childhood on and off for days now. Try as I might, I was unable to recall when I began to despise dandelions, nor was I able to understand why I had feelings at all towards a simple plant. I thought about how people love grass on their lawn, but hate it in their gardens. How we plant flower beds and uproot dandelions and clover in our lawn. I tried to grasp how we attempt to control things in our little parcel of life, and how futile this is. The lawn will never be "weed" free, the garden will never be free of grass.
I remembered an exercise Michael Bolton mentioned when he presented the Rapid Software Testing course to our team. Though I cannot recall the exact wording, he asked us to think about what shoe we put on first when we dress. And then, to deliberately switch it up. Think about it, we do/feel/think things everyday that we give no consideration to. Do yourself a favor and actually "consider" something "ordinary" today. It is like taking a vitamin for your mind.
And as for my dandelions, I won't fight them today. I will teach my child how to make a necklace and a tiara out of them so that she can be a Dandelion Princess for a day.
Two weeks ago when I went to mow my lawn, my youngest child began running around the yard picking as many dandelions as she could carry. Because this behavior was odd in a funny way, I asked her what she was doing. She told me she was saving the flowers. (Adults know that picking flowers does not do anything to enhance or promote their life.)
I have thought about this display of childhood on and off for days now. Try as I might, I was unable to recall when I began to despise dandelions, nor was I able to understand why I had feelings at all towards a simple plant. I thought about how people love grass on their lawn, but hate it in their gardens. How we plant flower beds and uproot dandelions and clover in our lawn. I tried to grasp how we attempt to control things in our little parcel of life, and how futile this is. The lawn will never be "weed" free, the garden will never be free of grass.
I remembered an exercise Michael Bolton mentioned when he presented the Rapid Software Testing course to our team. Though I cannot recall the exact wording, he asked us to think about what shoe we put on first when we dress. And then, to deliberately switch it up. Think about it, we do/feel/think things everyday that we give no consideration to. Do yourself a favor and actually "consider" something "ordinary" today. It is like taking a vitamin for your mind.
And as for my dandelions, I won't fight them today. I will teach my child how to make a necklace and a tiara out of them so that she can be a Dandelion Princess for a day.
Thursday, May 21, 2009
The Why and How - Guidelines I Use
Recently the subject of documentation has come several times around me... Questions about what I provide, to whom, and when. (Notice the why and how is missing?)
This got me to thinking….
First of all, I do not like to waste time on peripheral activities that take away from actual testing time. However, I do know that stakeholders on different levels need different information from me at any given time. So, what documentation do I provide to whom, when, how do I provide it, and why?
A broad stroke answer is, it totally depends upon what project I am working on. Let me explain.
When a stakeholder needs information from me in the form of documentation, I do not want to assume I know what they need. I ask questions. An attitude of service is necessary for this (perhaps waiting tables helped me to understand that an order for a steak can vary significantly from “it still says moo” to “it could re-sole your shoe”). I want to get the stakeholder to be as specific as possible by asking clarifying questions and submitting samples for them to view. This helps with two things: stakeholder satisfaction and less “paper work” for me in the long run. If the stakeholder gets the information that they want, there is also then a certain level of respect and trust that enters the relationship. This is the “how” I go about determining what documentation to provide.
The “why” guideline I use helps me to continuously evaluate the documentation that I process to determine if it still holds more value that it costs to provide. If it does not appear to do so, I will question myself (to see if I can come up with an alternative) and then the stakeholder (to see if we can come up with a solution to the cost versus value problem). Sometimes it is not possible to alter what is needed by the stakeholder (usually when they have a stakeholder they provide information to). But, more often than not, I find that when saving time and money is involved, which adds value, people are willing to negotiate.
I have very rarely felt compelled to create meaningless documentation (for the sake of documentation itself) by keeping these two aspects in mind when approaching the question of the what, to whom, and when of my aside-from-testing activities.
This got me to thinking….
First of all, I do not like to waste time on peripheral activities that take away from actual testing time. However, I do know that stakeholders on different levels need different information from me at any given time. So, what documentation do I provide to whom, when, how do I provide it, and why?
A broad stroke answer is, it totally depends upon what project I am working on. Let me explain.
When a stakeholder needs information from me in the form of documentation, I do not want to assume I know what they need. I ask questions. An attitude of service is necessary for this (perhaps waiting tables helped me to understand that an order for a steak can vary significantly from “it still says moo” to “it could re-sole your shoe”). I want to get the stakeholder to be as specific as possible by asking clarifying questions and submitting samples for them to view. This helps with two things: stakeholder satisfaction and less “paper work” for me in the long run. If the stakeholder gets the information that they want, there is also then a certain level of respect and trust that enters the relationship. This is the “how” I go about determining what documentation to provide.
The “why” guideline I use helps me to continuously evaluate the documentation that I process to determine if it still holds more value that it costs to provide. If it does not appear to do so, I will question myself (to see if I can come up with an alternative) and then the stakeholder (to see if we can come up with a solution to the cost versus value problem). Sometimes it is not possible to alter what is needed by the stakeholder (usually when they have a stakeholder they provide information to). But, more often than not, I find that when saving time and money is involved, which adds value, people are willing to negotiate.
I have very rarely felt compelled to create meaningless documentation (for the sake of documentation itself) by keeping these two aspects in mind when approaching the question of the what, to whom, and when of my aside-from-testing activities.
Saturday, May 16, 2009
Juggling...
On a couple of occasions this week I was able to be a part of conversations that made me think about my philosophies on life as well as on testing software.
Why is it that people feel the need to be perfect in what they do? I learned many years ago that people have control over a very limited segment of their lives. What I do, what I say… in this very moment… is what I have control over. Because of the unknown, and sometimes known, variables that come into play in every circumstance of every life on this planet, it is impossible to really have any control over anything else.
This got me to thinking about a juggling analogy. So, I did a bit of research on juggling. I came across a great article called Life is a Juggling Act.
The article makes the following points:
Master the Basics
Get Comfortable with Failure
Break the Task Down
Learn What to Watch
Balance = Stillness
Accept the Unexpected
Bad Habits Have Big Consequences
Juggle a Bit of Everything
I did not find it too difficult to draw a line between my everyday testing activities and juggling. The points themselves say a multitude without intervention.
One of my favorite points in the article was under the Learn What to Watch topic. “The death knell in juggling is to watch any individual object. Our instinct is to look at each ball or task separately, because we want to have control. It's a very insecure feeling: you influence something, and then you can't influence it, and then you're expected to catch it. But if you're tied to each little specific, you'll lose sight of the big picture.” (emphasis added)
Why is it that people feel the need to be perfect in what they do? I learned many years ago that people have control over a very limited segment of their lives. What I do, what I say… in this very moment… is what I have control over. Because of the unknown, and sometimes known, variables that come into play in every circumstance of every life on this planet, it is impossible to really have any control over anything else.
This got me to thinking about a juggling analogy. So, I did a bit of research on juggling. I came across a great article called Life is a Juggling Act.
The article makes the following points:
Master the Basics
Get Comfortable with Failure
Break the Task Down
Learn What to Watch
Balance = Stillness
Accept the Unexpected
Bad Habits Have Big Consequences
Juggle a Bit of Everything
I did not find it too difficult to draw a line between my everyday testing activities and juggling. The points themselves say a multitude without intervention.
One of my favorite points in the article was under the Learn What to Watch topic. “The death knell in juggling is to watch any individual object. Our instinct is to look at each ball or task separately, because we want to have control. It's a very insecure feeling: you influence something, and then you can't influence it, and then you're expected to catch it. But if you're tied to each little specific, you'll lose sight of the big picture.” (emphasis added)
Monday, May 11, 2009
Assembly Required
I was waiting for my daughter to get ready to go out with me on some errands. I started to flip through some of her magazines when I came across the following subtitle in an article: *Life. Assembly Required.
I was struck by that phrase and it stayed with me for a few days. How true it is. You are given life, but it is not put together at all. Every path you take, every decision you make builds the life, or “assembles” the life you have. Each aspect of the life you have revolves around assembly. Once you reach a certain age, the decisions you make are your own. How innovative you are with what you are given and what you pursue, determines the product of yourself.
I stumbled upon an interesting blog with 13 entries on Innovation. Metacool by Diego Rodriguez, has these 13 blog titles available out of the 21 planned:
1. Experiencing the world instead of talking about experiencing the world.
2. See and hear with the mind of a child
3. Always ask: “How do we want people to feel after they experience this?”
4. Prototype as if you are right. Listen as if you are wrong.
5. Anything can be prototyped. You can prototype with anything.
6. Live life at the intersection
7. Develop a taste for the many flavors of innovation
8. Most new ideas aren’t
9. Killing good ideas is a good idea
10. Baby steps often lead to big leaps
11. Everyone needs time to innovate
12. Instead of managing, try cultivating
13. Do everything right, and you’ll still fail
Each one of these principles of innovation can be applied to all levels of life if the desire is to assemble something that goes beyond simply meeting the acceptance criteria. I look forward to the remaining blog entries…
*I would cite the magazine, but it has disappeared... somewhere... in the less-than-organized place my daughter calls her own…
I was struck by that phrase and it stayed with me for a few days. How true it is. You are given life, but it is not put together at all. Every path you take, every decision you make builds the life, or “assembles” the life you have. Each aspect of the life you have revolves around assembly. Once you reach a certain age, the decisions you make are your own. How innovative you are with what you are given and what you pursue, determines the product of yourself.
I stumbled upon an interesting blog with 13 entries on Innovation. Metacool by Diego Rodriguez, has these 13 blog titles available out of the 21 planned:
1. Experiencing the world instead of talking about experiencing the world.
2. See and hear with the mind of a child
3. Always ask: “How do we want people to feel after they experience this?”
4. Prototype as if you are right. Listen as if you are wrong.
5. Anything can be prototyped. You can prototype with anything.
6. Live life at the intersection
7. Develop a taste for the many flavors of innovation
8. Most new ideas aren’t
9. Killing good ideas is a good idea
10. Baby steps often lead to big leaps
11. Everyone needs time to innovate
12. Instead of managing, try cultivating
13. Do everything right, and you’ll still fail
Each one of these principles of innovation can be applied to all levels of life if the desire is to assemble something that goes beyond simply meeting the acceptance criteria. I look forward to the remaining blog entries…
*I would cite the magazine, but it has disappeared... somewhere... in the less-than-organized place my daughter calls her own…
Sunday, May 3, 2009
Seeing Beyond the Mission
My sister came by for a visit the other day and brought her little girl. When it got to be time for me and Henry (my pup) to go for our daily walk, I asked them if they cared to join us. They agreed to go and, including my little girl, the five of us went on our way down the trails behind my home. It was a nice day out and we were all playing catch up on what we have been up to in the past few weeks.
After we came to a fairly steep hill, the girls ran down ahead and stopped at the bottom to wait for us – they were checking out the rocks on the path and talking quietly (probably planning some mischief). When we arrived at the same spot as them, the ground next to us exploded! The four of us humans screamed like girls (imagine that), and the dog looked at us like we had lost our minds, as up flew a female pheasant.
Right in the grass beside the trail, she had been sitting, yet not a one of us had seen her. Not even the dog. We all had a great laugh at ourselves.
However, being a software tester….
A couple of things crossed my mind over the next few hours. First of all, even though she was camouflaged, I could not help to think one of us could have noticed her, if we had been observing what we were walking past. This feeling is well known among testers. Who doesn’t hate when the customer finds a bug that was missed in testing.
I also wondered how many things I fail to observe when I take the same trails with Henry on my own. And why do I fail to observe them? I am focusing too narrowly on the mission. My mission varies day to day. Sometimes the walks are purely for exercise, or they might be for conversing with others, (people seem less rigid and uptight in natural surroundings - even teenagers) or just bonding time with the pup. What is wrong with the mission? Not a thing. Do I fulfill the mission? Yes, I do. But there is something that I believe I have been missing. My focus has been too narrow and this has limited me. To me, this is a potential problem, seeing as the woods where I walk contain wildlife inhabitants much bigger than the pheasant.
So, the narrow focus on my missions when walking through the woods - even though I am on marked trails - is that I have been failing to take note visually of the surroundings. Just because the trail is marked, and I cannot hear or smell anything that makes me take notice, that does not mean I should trust that everything will go as planned. Should a black bear be down-wind from me and the dog and not be making noise, we could be in for a bit of trouble.
This failure is based on my previous experiences, my biases collected through years of living in urban areas. However, when walking the trails in the urban areas, I was generally attentive to the other people on the paths and was trained to be this way by mom when I was young, and then by the news as I grew older. So, out of habit I paid attention to the other humans around me, but I had no habit when walking the trails in the woods. I need to develop the good habit of observing the panorama around the trails.
This habit is one that I try to use when I approach my testing. It is not a good idea to focus narrowly on a mission; in fact, I find it impossible to do so and still have any level of success. A panoramic view is necessary in testing software. Aside from the fact that testing software involves a systems approach, there are customer needs, business needs, developer needs, test lead needs, team member needs, and manager needs. Each of these requires some observation from the tester outside of the mission of actually testing. As much as is possible, it is important to keep the big-picture view in sight for the entire mission.
Of course, as in all things, this too requires balance. Too much observation on the tree line, and I could end up stepping in a hole that is on the trail and twist my ankle or some such thing. The same is true in a testing mission. In order to actually meet the requirements of the different groups of stakeholders, it is important to balance the big picture with the mission.
And on that note, I think I will go work on developing my habit of observation…
After we came to a fairly steep hill, the girls ran down ahead and stopped at the bottom to wait for us – they were checking out the rocks on the path and talking quietly (probably planning some mischief). When we arrived at the same spot as them, the ground next to us exploded! The four of us humans screamed like girls (imagine that), and the dog looked at us like we had lost our minds, as up flew a female pheasant.
Right in the grass beside the trail, she had been sitting, yet not a one of us had seen her. Not even the dog. We all had a great laugh at ourselves.
However, being a software tester….
A couple of things crossed my mind over the next few hours. First of all, even though she was camouflaged, I could not help to think one of us could have noticed her, if we had been observing what we were walking past. This feeling is well known among testers. Who doesn’t hate when the customer finds a bug that was missed in testing.
I also wondered how many things I fail to observe when I take the same trails with Henry on my own. And why do I fail to observe them? I am focusing too narrowly on the mission. My mission varies day to day. Sometimes the walks are purely for exercise, or they might be for conversing with others, (people seem less rigid and uptight in natural surroundings - even teenagers) or just bonding time with the pup. What is wrong with the mission? Not a thing. Do I fulfill the mission? Yes, I do. But there is something that I believe I have been missing. My focus has been too narrow and this has limited me. To me, this is a potential problem, seeing as the woods where I walk contain wildlife inhabitants much bigger than the pheasant.
So, the narrow focus on my missions when walking through the woods - even though I am on marked trails - is that I have been failing to take note visually of the surroundings. Just because the trail is marked, and I cannot hear or smell anything that makes me take notice, that does not mean I should trust that everything will go as planned. Should a black bear be down-wind from me and the dog and not be making noise, we could be in for a bit of trouble.
This failure is based on my previous experiences, my biases collected through years of living in urban areas. However, when walking the trails in the urban areas, I was generally attentive to the other people on the paths and was trained to be this way by mom when I was young, and then by the news as I grew older. So, out of habit I paid attention to the other humans around me, but I had no habit when walking the trails in the woods. I need to develop the good habit of observing the panorama around the trails.
This habit is one that I try to use when I approach my testing. It is not a good idea to focus narrowly on a mission; in fact, I find it impossible to do so and still have any level of success. A panoramic view is necessary in testing software. Aside from the fact that testing software involves a systems approach, there are customer needs, business needs, developer needs, test lead needs, team member needs, and manager needs. Each of these requires some observation from the tester outside of the mission of actually testing. As much as is possible, it is important to keep the big-picture view in sight for the entire mission.
Of course, as in all things, this too requires balance. Too much observation on the tree line, and I could end up stepping in a hole that is on the trail and twist my ankle or some such thing. The same is true in a testing mission. In order to actually meet the requirements of the different groups of stakeholders, it is important to balance the big picture with the mission.
And on that note, I think I will go work on developing my habit of observation…
Subscribe to:
Posts (Atom)