UE: TesterLost_Focus

Products are Relationships… A Rant... Appeal...

2012-01-25T17:43:00.000-08:00

I read an article today that stated some things I have been thinking about for quite some time, but haven’t had the opportunity to actually sum up for myself. Google Is Facebook Is AOL: What Happens When a Good Google Goes Bad.

It is not strange to anyone who converses with me about Google that I have a love/hate relationship with “them”.

I first came to love Google because of their amazing and pure search engine. What research/information addict would not fall in love with Google? They gave me results from all over the planet in seconds. They gave me the opportunity to find new things/ideas/thoughts/puzzles/places/information/etc. They expanded my horizons, broadened my views, heck… let’s go with it, they were helping me to do what Star Trek inspired me to do….

Then... they developed, and gave me without consent, the +1… For quite some time, due to my schedule and my ignorance, this “feature” has been in place and it is making my search queries deliver the same information over and over again… This is what I would call search purgatory… bordering on the theme of the movie Groundhog Day .

As a research enthusiast, and an information junkie, I do not want to search for things I already have information on… I want what is new, what is cutting edge, what is taking a front seat… I want pure search. This +1 thing is making it all about me.

Maybe Google thinks that the success of “social networking” is based solely on people who are so into themselves that they take pics of themselves and try to make it look like someone else took them. I would understand that "snap judgement" , I make those myself - sometimes - until I get to know the person in the photo.

I bring up the “social networking” segment because I considered Google Plus, but reconsidered very quickly when I saw what I did on the page to sign up… another +1 thing… I don’t want to share my searches, they are random, they are sometimes silly, they are sometimes my personal thoughts, they belong to “me”.

I signed the SOPA petition through Google’s home page, only to realize they want to take away my privacy… again.

My point of this blog is to say to Google... that I love what you did; when you did it to me right… but now you seem to be seeking to take from me what I hold dearest to my heart… my privacy. I want a way to not have to give any more of that away without my permission. I want you to go back a bit to your roots… don’t pull the plug on where you are going… just remember your own mission statements. Put me first, my rights, my privacy, my research, my searches, me…

As in any relationship, it takes 2. And each one needs to hold the other one above itself to be successful.

I want out of +1, and I don’t want to have to ask for it.

I don’t need to “search” for things I already know… unless I desire to do so… and/or I need/want a reminder.

I want to keep my privacy… decide who can “see” any part of me… decide what I “share” with anyone… In real life, I share “real” things with so few people I can count them on one hand or less, don’t try to force me to do that with others, don’t try to give others info that will make them think things about me, make snap judgments about me, when they don’t even know me…

Work with me, work for me… I know who I am… do you still really know who you are?

When YOU Get Tested…

2012-01-19T18:20:00.000-08:00

· Do you “crash”
· Do you “fail”
· Do you “hide” or “omit” data
· Do you “expose a symptom” of a bigger issue

There is a part of my brain that understands that I get tested as often, if not more, than the things/products/applications/ideas/people I test. Or, maybe it is just a suspicious/non-trusting trait that I have, which makes me “think” I understand this…

I have four daughters – current ages: 24, 22, 19, and 8… I understand being “tested” to a certain point…

The first three daughters had regimen in their lives. Their mother was like a feminine drill sergeant. There were rules and they were strictly enforced. Child number four, not so much… which ultimately led me to this testing that I am going through now…

I shall call this chapter of my life “The Problem with Vegetables”. And I am learning a lot about Agile Child Development throughout this chapter…

I have not actively participated in any New Year’s celebrations or traditions forever… or at least for so long that I cannot recall a single resolution I may have ever made… until this year…

I made a resolution to make my 8 year old daughter eat more veggies every day…

It is only the 19^th day of January, which means this is the 19^th day of the resolution, and I have seen and learned so much… If you think you are mentally strong… engage your brain with that of a child… you will soon see you have much to think about…

The first thing I learned so far, was that this resolution really wasn’t to get “her to eat more veggies every day”, it was for ME to encourage and enforce it… so the specs were off… and please note, they usually are off a bit in software testing as well…

The second thing I learned was that I totally have a new respect for developers… I will use a simple IF THEN to show what I mean:

IF child eats said veggies in front of me, THEN she will continue to do so when I don’t look

ARE YOU KIDDING ME????

I left out the error handling when I made this resolution…

· What IF child hides veggies
· What IF child flushes veggies
· What IF child throws up
· What IF child attempts to make deals
· What IF child is stubborn

I have a whole new respect for developers who are just trying to “code” what is “expected”… and forget what is not expected…

The third thing I have learned is using humor as a tool… You cannot get too frustrated when the plan does not go your way, or when roadblocks appear…

One of the persons I am super fond of when it comes to raising children is Bill Cosby. To me, he really gets parenting… and he really helped me feel so “not alone” so many times in my life as a parent.

If you have the time, and you are a parent, please watch this video:

The fourth thing I have learned is that I don’t have to have all the answers to begin to do what I should do. I don’t have to “know” everything about the situation. I just have to commit to it. And sometimes that has to be enough to move forth with the journey…

There is much to learn and know out there in our little worlds, and we can use that to teach us how to be the best we can be in the bigger world…

Each time I am tested I have an opportunity to learn and grow… and fix my own “code”… it’s really all an adventure of thinking…

**Note: I quoted Wikipedia quite a bit tonight… on purpose… kudos to them on what they did about http://en.wikipedia.org/wiki/Stop_Online_Piracy_Act.

Testing - Tip Up…

2012-01-11T15:27:00.000-08:00

As I have established in my last post, I really don’t have the opportunity to “eat my own dog food”, I don’t really use the software that is developed by the team I work with…

However, there are plenty of things I do use. So there is always plenty of testing going on in my life. Some of it is on purpose, and some of it is out of necessity.

I live in an area of the United States that has 3 seasons: Summer, Winter, and Mud. It is essential that you find things to do during Winter up here, since it is pretty much the longest season we have. You can find many different options to choose from if you look hard enough, or, as in my case, someone introduces you to something….

My introduction, a few years ago, was to Ice Fishing. I never went fishing until I was an adult, and I never would have know about ice fishing if it weren’t for The Fisherman.

To date, my Teacher has bought all my tip ups/traps. He bought me these based on his experience with the same models… and because they had pink ones available J

Recently The Fisherman bought a new trap to “test”, so I got to thinking perhaps I should do the same…

Here is a picture of the tip up I purchased:

Now, let’s say YOU are given this to test and YOU don’t ice fish, which means you do not “eat your own dog food”… What are you going to do?

Never fear… documentation is here:

So… now what? Where do you begin? How are you going to test something you may never even be able to use? Unless you live somewhere that you can walk on the water in winter, how can you successfully test this? Can you? Will you "take the bait"?

I really AM going to test this new tip up… and I have some knowledge of what that means…

I challenge you to willfully test something this week… as if it were software. If you think about it, it won't be that hard to come up with something. Do you generally use a certain cleaning solution to get a job done at home? Shake it up, try something else that claims to be better/easier/as good as the product you use. Actually approach it as if it is the product/application you have to test.

If nothing else, the exercise will de-focus you from your own testing and may even give you some ideas on testing that you have not thought of…

Testing Misconceptions…

2012-01-10T15:45:00.000-08:00

“You work with computers, right?” Friend/Family… insert any name here…

“No, I work with people… who use computers…” Me.

“I have this problem with my laptop, it keeps doing such-and-such, what do you think is wrong? Can you take a look at it?” Again… Friend/Family… insert any name here…

“I really don’t know anything about fixing laptops, sorry,” Me.

“Is that because you work with desktops only?” Person above…

“No, I work with people…”, Me again.

“Hey, do you think you can take a look at my investment portfolio,” Friend/Family… insert any name here….

“uhhh”, Me.

“Oh, come on now, isn’t that what you guys do?”

“You mean the software we develop and test?” Me

“Yeah!”

“Just because we develop and test the software, doesn’t mean we are investment brokers…”, Me.

“Is that a no?”

Conception…

Understanding…

Questions…

Sometimes I wonder why some in management do not understand what I do when I test. Then I remember those who “know” me and still don’t understand “me” or “what I do”…

It reminds me that I cannot actually get angry at those who do not understand what I do when I test… because those I love don’t understand it either…

Over the years I have come in contact with management who doesn’t understand what testing “is”, or what “service” it provides… but how can I not continue to investigate ways to explain this to them when those I hold dear have no clue…

Answer is… I cannot… I must always remember that unless you actually do/actively participate in something… you cannot understand… and I must temper my explanations… with knowing this…

How do you explain your career to others? Do you get mad/angry… try to convince? Do you treat them like children? Draw pictures? Tell a story?

It is not easy to explain “yourself” or “what you do” to anyone… I challenge you to take pause and think of how you handle this as a tester… sometimes it can take down walls… sometimes it matters only to you…

May not be easy… but it certainly does make you think about your approach to explaining what you do… and that… is not a bad thing. Investigating this, at the very least, may remind YOU what YOU do and why YOU do it…

When not questioning your application/product under test… DO question yourself... It helps YOU learn... It is a teacher without a student loan...

2012-01-03T17:50:00.000-08:00

My youngest daughter has begun to learn about systems and critical thinking… She is 8-years-old, going on 13, and in third grade….

It is an interesting learning experience for me. I think something different happens as you get older, something makes you realize you have as much to learn as you already have learned in life.

The child was having some struggles in Biology/Science. I spoke with her teacher, read her text book, and came to the conclusion that this type of thinking is “not” necessarily an easy thing to grasp.

I have had to begin to take some time to learn how to teach some things to my daughter, to help her understand things that she does not, by nature or by genetics, understand.

The system they have begun with is the ecosystem. Wow… I really missed some fundamental learning when I was in school… or it just slipped by me because I did not understand it at the time. What a great way to introduce systems thinking to children! I think I must have understood something about systems, but did not grasp the vast meaning it had for “other” systems I would come in contact with, but watching a child struggle with such things… it makes you want to teach… to show… to pass on knowledge…

And critical thinking… the text book actually has passages dedicated to this, but does not show the “how to” on doing such… this has been an amazing thing to observe, likely because I have gathered enough information over the years to make me “see” things differently… to “look” at things with questions.

I have learned that some things that I understand may not be so easy to put into words or tutorials for others to understand. Thinking is not an easy thing to pass on. It is especially not easy if the thinking styles are different among those in conversation. (Google “thinking styles” and take a look at a few different sites to see what I mean.)

I have an innate ability to understand some things, and I understand bias enough to know I sometimes think others should/could/do understand the same things… but I also know enough to know this may not be true… hard to balance this at times, but it is life. Because I know the difference between thinking, I recently bought a book to help me teach my child how to “see” systems…. How to “understand” a bit more about discerning them in the things she is learning.

I found Thinking in Systems... a Primer to be a good teaching/learning book. I have only just begun to read/digest chapter 1, but I already like the direction it is heading in. This book has given me several examples to easily compress for my daughter a bit of enlightenment on thinking in systems… I already recommend reading this book, especially if you do not really understand systems thinking, but want to learn how to digest it… before you read An Introduction to General Systems Thinking .by Gerald M. Weinberg.... which will definitely lead you to the next level...

Are you testing?

2011-10-13T03:33:00.000-07:00

I have had the cause to think again on Michael Bolton's Testing vs. Checking series...

I live in northern Maine, where the potential for severe winter weather is pretty high. While thinking about “Testing vs. Checking”, I pondered winter tires…

I don’t want "Grandma" to drive carefully through the downtown streets, after the storm has passed and the plow truck went through, to “check” that the tires perform in the winter. I don’t need to know that the tires perform correctly when the circumstances are ideal, when the user is friendly.

I want someone to drive in the middle of the sleet/snow storm, on the 55 MPH highways AND the downtown streets. I want them to have a reason to stop abruptly and dodge some obstacle. I need to know that the tires will perform correctly in adverse circumstances. I want the tires “tested”.

I also don’t need someone to try to abuse the tires for me to have faith enough in them to buy them. It’s not about driving through giant snow drifts or over nails. It’s not about proving that they can break. It’s about ensuring there is enough information for the stakeholders to put a rating on the tires. It’s about ensuring the end user will have a satisfactory experience with the product. A satisfactory experience usually entails not actually thinking about the product, but about whatever the product is used for.

Are you testing?

On History...

2011-09-05T18:12:00.000-07:00

I find that I do not take the time too often anymore, to read something just for the enjoyment of reading. I have found that I have been reading only for information…

A couple of weeks ago, I brought my 7-year-old to the local bookstore. I wanted her to find something to read that would keep her interest in learning at its peak. While I was there with her, I realized I needed to do the same. So I started browsing…

I came across a book that piqued my interest… “My Life in the Maine Woods” by Annette Jackson.

This book was written by a woman, not unlike myself, who was born in Massachusetts, then ended up living in Northern Maine. She had a real love for the woods... again - like me… I wanted to read what she had to say, I wanted to try to “see” where she had been, what she had experienced.

It only took me a couple of days to read through her life “in the Maine woods”. I really enjoyed reading about another woman’s experiences, and her love for nature, for fishing, walking, seeing, loving, the woods up here in Northern Maine.

I realized something else when I read this. Too often we are seeking information today that is fresh and new, we forget that there is a history for everything… a time of learning, of discovery.

I believe there is as much to be learned from yesterday as there is from today… whether that is poring over old text books or blogs, don’t just settle for today’s information when it comes to learning about anything… go back in time and discover the processes of learning… the thoughts of ‘that’ day… you may be surprised at how much is the same, how much is different, something may spark a new thought for you today…

James Bach's blog goes back to 2003... Michael Bolton's to 2004...

These are a couple of my favorites, but, whoever you read, whatever site you look to for information, don't just rely on today's information... take a look back in time and see what you might be able to learn from "a-ways back"... you might be surprised...

I came out with a couple of good, simple recipes… along with some lovely stories… from my trek back in time with Annette… recorded history is a great place to sit and think… a great place to learn...

Dear Time Warner...

2011-09-05T17:34:00.000-07:00

I just spent over an hour trying to reach you on my cordless phone, while the battery was beeping that it was low (my teenage daughter doesn’t believe in putting the phone back in the cradle when she uses the phone). Most of the times when I called, I received a message - a recorded message that said - “We’re sorry all circuits are busy now, would you please try your call again later.”

When I finally did get through to your lines, your second recording, when I selected tech support help for my Internet, you hung up on me….

I realize you are a big corporate super star in the Internet World, but you have a long way to go in Customer Service. I have some suggestions for you…

1. If there is an outage that affects a large area, instead of the “we’re sorry…” message, how about just a message that says, “we are currently experiencing outages “here”, we apologize for the inconvenience and are working as hard as we can to rectify the situation”

2. Hire some software testers for your phone system… there is a reason I got through to a certain point and was then “hung up on”. There is evidently a certain threshold of calls that your system has where it begins to not be able to handle it, this should be handled more gracefully

3. Remember that the customers pay YOUR bills, not just their own... without us, you cease to exist... eventually...

Been over an hour now… the phone just keeps ringing, I have decided when I get to the menu again, I am going to push the number that says I want to order more service from you… I bet you answer that one because it could mean more money for you…

Let’s see if you answer… nope… “Our offices are currently closed…”, then you hang up with no way for me to go back to the previous options… Sounds like another bug in your phone system… I should have a way to get back to the main menu - if the only other alternative is you hanging up on me…

Notice how I equate the word “you” to an organization and all its associated “pieces” - ranging from the software on your phones to the hang ups I experience? I believe that is because we made an agreement… service for money… that is a very “human” thing. Folks don’t part with money without expecting something in return for it… unless, of course, they are at the end of a revolver… then again; it could be their life in exchange for it…

I strongly suggest you, as in those who run your company, begin to do some research involving how you treat your customers… maybe start by actually asking the customers what you can do to improve their experience and your service…

Note: I wrote this close to a week ago... but wanted to make sure I was not just plain angry before I posted it. I realized I am not just angry, but confused... why is it that companies try so hard to solicit customers, then... when they reach the pinnacle of success... they forget about the people behind the numbers they have acquired? Customers are people. They have faces. They are more than just money-makers for organizations... they are the blood flow of it. In this day-and-age, it seems that a "thank you for doing business with us" is nearly non-existent. I don't think this is okay. I don't think this is reasonable. I think organizations need to recall the relationships that they forge between themselves and customers. They need to remember their roots...

Second Note: There had been an outage... it seems it may have even been state-wide... imagine the amount of calls and annoyances that could have been avoided... if the original phone message said something different...

Anchoring and Attentional Bias...

2011-08-16T17:56:00.000-07:00

I thought I might take a bit of a deeper look into cognitive biases... I decided to start going through the list that I mentioned in my previous blog... and "begin at the beginning" to quote Lewis Carrol... on the list that is...

Anchoring - "the human tendency to rely too heavily, or "anchor," on one trait or peice of information when making decisions."

Real World Example: My oldest daughter was looking for a new "used" car. Her last vehicle went to, let's say, about 145,000 miles before it was in need of a new engine. While assisting her in looking for another vehicle, she focused solely on the number of miles that were listed for the vehicle. She was not concerned with the make/model/year/expectancy/maintainence it recieved/etc. Based on her limited experience with vehicles, and the fact that that particular vehicle may have needed the new engine at 145,000 miles due to excessive wear and subsequent neglect of other parts, she was "anchored" into believing that mileage was the goal of the purchase.

Possible Testing Example: A new tester works for Project A for a year or so. Project A consists of one large customer. The tester's job is XYZ, the customer does all of the Acceptance Testing and provides the bugs to the team that they want fixed when it comes to usability. That tester now transfers over to Project D. Project D distributes their product/application/system to a wide variety of customers. The tester is now faced with the "anchor" of how things were done on Project A. If not careful to find out the differences in what is expected of them in Project D, the project will indeed suffer for quite some time. If they wish to "sail" through this project and give the stakeholders the necessary feedback they need on usability, they need to pull up the "anchor" of their belief that the "customer is always right". They will need to now look at usability testing in a new light, based on general standards, using heuristics and oracles. (Here is a great post by Michael Bolton concerning oracles.)

Attentional Bias - "the tendency of emotionally dominant stimuli in one's environment to preferentially draw and hold attention."

I did a little research into this particular cognitive bias and it appears to be emotional in a largely negative way. I would almost want to group this in with cultural differences between groups or individuals as well as taking into account their own personal backgrounds. I would think this is a tough one to even acknowledge and analyze if you don't think about it "on purpose".

"Maybe" a Real World Example: I worked under the management of my father for six years. During this time, it was quite evident to me that he was a male chauvenist. There were four of us working under his management: two females, two males. The males did less work and got more money. After the business was no longer in existence, I confronted him on this and was told, "so and so should get more money, he is the provider of his family". He always believed... and showed his beliefs... that males were the "providers" and thus they should earn more money. (Note: It never crossed his mind that I am provide for my family, it only crossed his mind that I am female.) This burned into my brain a bias - an "emotional" bias - towards "hearing" when anyone mentions gender in the workplace and in general.

"Maybe" a Possible Testing Example: A female tester works on a team that includes only male developers. They offer to give her help on testing. She sees it as they are thinking she is "less smart" than a male tester would be and she shuts down her listening skills.

This was a hard one for me to really wrap myself into. Either I am totally ignoring this bias or I don't really have it. My "emotional"/attentional biases are easy for me to spot. I know who I am and where I have come from. They rarely, if ever, surface in my career. It is too "emotional" for me to think about anyway... I rely too much on logic...

Because this particular bias was related to "emotion", I recalled a presentation from Michael Bolton on Emotions and Oracles. I think, that if you find yourself wanting to take this bias and investigate it further with your testing career, and even if you don't... that you read this. Even though I am thought of by most, that think they know me, to be really the daughter of Spock, even I learned much from reading it.

Thinking About Thinking... again...

2011-08-15T19:02:00.000-07:00

I was thinking about thinking... again... I wanted to check out anything new on the subject out in the vast world of cyberspace (is that word still used? Cyberspace?)...

I checked out some topics on some of the websites and blogs that I usually go to for innovation/new ideas/thoughts, but I didn't find anything that actually caught my attention. Perhaps I was thinking too hard about thinking...

I decided to just run a search on the subject of Critical Thinking and see what Google would throw my way in videos... I did not feel like reading tonight, I just wanted to listen/watch for a change.

Nights like tonight make me feel a bit old. I am amazed at what is out there in a world of "intelligent" human beings... there is a lot of stuff out there that doesn't exactly hit the mark for the word "thinking" even though the search criteria is requesting such.

I came across a really noisy video during my search to find something new on Critical Thinking. I ended up watching it twice because my 18-year-old daughter jumped up from what she was doing to see it. She laughed aloud watching the video. I am not sure she was able to catch any of the background message, but it was there, if you could tune out all that noise.

Here is the video for The Critical Thinking Song:

The message in the video, in case you could not tune out the "noise":
Step One: Be willing to say "I don't know"
Step Two: Define your terms
Step Three: Be open minded
Step Four: Produce ideas
**Consider the source
**Seek out alternative views
**Ask questions
**Look for at least three answers
**Lay your cards down on the table
**Write about it
Step Five: Accept changing perspectives
**Come up with your own conclusion

Maybe someone else out there will find this video just as humorous as my daughter did and be able to remember the steps listed in order to remember to think critically. I must say that I have seen Step 1 to be lacking in most projects that I have worked on, sadly. Admitting you don't know doesn't mean it is the end of the world, it means the answer needs to be found. I prefer "I don't know" to a lame excuse or not-quite-right answer... every time... It is not a weakness to say this, it is admirable when true. For the video... I admit the cat made me laugh...

Needless to say, after the noise, I was less lazy feeling... never mind the videos... give me words.

Somewhere in my research, I found the term "cognitive biases". Having read numerous books and other peices on biases over my lifetime, I decided to change my search criteria to that.

I found a list of cognitive biases. I think for tonight I will consider these biases and if they affect me or not... quietly... :) I bet one of those biases makes me think twice about the Critical Thinking Song...

On the Two Sides of Communicating...

2011-08-07T12:56:00.000-07:00

I just watched/listened to a TED talk given by Julian Treasure on "5 ways to listen better".

Take a few moments to "listen" to it, if you will....

The "filters" that Mr. Treasure includes in the presentation remind me of personal bias' that we have when we filter any information - written/heard/seen. And how it is important to remember to at least try to see outside of where we are/have been in order to communicate better.

Listening is an important skill, that although it is listed as a "soft" skill in most job requirements, it is more often than not, a "hard" skill to acquire.

The speaker used the acronym "RASA" (you will have to listen to the talk in order to hear where that comes from) to give tips for better listening skills.

I wish the talk had been more in depth, lasted longer... For many years, I have had the routine of taking time out for silence. It is something that scares so many people these days, but it is something that was so natural not too many decades ago. It is something I need to have to face the day. It brings me balance.

To clear the brain of noise, to "hear" what is naturally occuring around you, can help to not only allow better listening, but better appreciation for hearing.

I also caught up on another blog I often read, Metacool, one post that particularly caught my eye was titled "Effective storytelling, a countermeasure against complexity".

Together the posts made me think about things that are a value to me, that make me think about humanity and communication in "deeper" ways.

Storytellers have always fascinated me. As a young person, I always loved power outages. While the adults may have not liked thinking about the meat thawing out in their freezers, I loved that fact that folks were just not as distracted as they generally are. The adults would start to tell "stories" to get past the silence. It was wonderful. I remember such things as if they were burned in my soul.

I have met other storytellers along the road, and no matter what is going on around me at the time, I indeed will listen intently. They are a rare breed, few and far between, perhaps because the world is so "noisy" today.

Both of these subjects combined have made me think of the two sides of communication... the speaking and the listening... and they have made me think of what I can improve on in my own self.

What I Learned from "The Hitching Post"

2011-08-07T05:27:00.000-07:00

When I was in high school, many moons ago, I worked on the school newspaper. It was a great experience that I remember fondly to this day. One of the funniest things that happened was when the editor (another student) had accidently applied his name to an article I had written. I was able to “pay him back” in the April Fool's Day edition by submitting an article where he had been arrested for it…

I learned a lot about gathering information and sticking to the facts in that class. The instructor was passionate about hammering home a couple of important things to remember when submitting an article. And, believe me; it did not get published if it did not pass the test. The first thing he hammered home was "just the facts, ma'am". As a reporter in his class you were writing articles, not editorials. Your opinion was not to be included in the writing.

The second thing he hammered home was the 5 W's and 1 H concept. I think he must have said them aloud to us every day in the beginning of class…

I have found that these two items that were drilled into me in that class easily pore over effectively to reporting bugs.

Reporting the facts only prevents friction between development and testers. It largely prevents reports that seem to be attacking developers.

The 5 W’s and 1 H, in a simplified context, could look something like this:

1. Who? – The application/system/product in test

       2.       What? – What feature/component/link/etc.
       3.       Where? – Where is the testing taking place, what is the environment
     4.       Why? – If you think you know what might be causing the bug, add this to the report
       5.       When? – What is the state of the application/system/product when this bug is revealed
       6.       How? – What are the steps to reproduce the bug

Of course this is shown at a very simple level, but when considered during testing, these items are very useful in gathering information that will speed up the time it takes to get the bug addressed.

Sometimes, testers get caught up in the ability to “break” the application/system product, and forget that the reporting of the bug is more important in getting it fixed.

Here is an example of a fake bug report. In honor of the newspaper I worked on in high school, I will call the pretend product “The Hitching Post”. One of its features is the ability to create text documents. This is the kind of report I have seen go through the bug tracking system when the concepts above have not been considered:

Headline – The application crashes when attempting to save a text document

Steps to Reproduce:

     1.       Open a text document
     2.       Click the Save icon
     3.       The application crashes

When I have seen this type of report, I will send an inquiry for more information. Usually I will ask questions. In this example, I would likely ask at least the following:

1. What OS is the product installed in?

      2.       What version of the product are you testing in?
      3.       What state was the document in? New, previously saved, edited?
      4.       If the document was edited, what was entered in it? Illegal characters, font change, number of characters?
      5.       Does this occur when using the Save menu item or shortcut key?
      6.       When the product crashes, is there an error message? Is the message a product message or a system message?
      7.       Are there any error logs that can be attached to the report?

My belief in writing bug reports is to have development spend little to no time in coming to see me or talk to me – about the bug reports, that is J I find that applying these concepts to the report have caused me to be more focused on gathering as much information as I can.

Don't Forget the Simple Tools...

2011-07-25T17:36:00.000-07:00

The area I live in has been hit three times in the last month by weather systems that include something called microbursts. I have lived in places across my country that have included tornadoes and hurricanes, but in all the years I have lived, I have never seen such a weird pattern of destruction. Full grown/aged trees were ripped out by their roots.

To attempt to show the size of the damage with one of the larger trees that was uprooted, I had my daughter take a picture of me near the uprooted bottom of the tree. (She, at 7, refused to be in the photo... she acts 13 at times.) And, no, I am not crying about the tree, but a bit sober at the damage of a friends home...

A lot of folks were quite lucky not to have the trees fall on their homes. No one died or was critically injured, that I am aware of, through the last month when these storms occured.

All you could hear for the last few days outdoors, is a combination of chain saws, backing up trucks, and lawn mowers.

Some of the trees that were lost would make an aborist cry, I know because I love old trees and almost cried myself at a few of the old landmarks that are now gone.

A conversation I had with someone about the fallen tree removal got me to thinking about tools... The fellow said his chain saw could not cut through some of the older trees that were felled on his land due to their size. They were just way too big in diameter for the average Joe's chain saw.

Here in the small Northern Maine communities there is a really big tie to roots. Folks decorate their homes and property with items from days gone by. It is a really nice tribute to the history of the communities. It is part of the reason I love it up here - folks are still connected to where they came from. But that connection appears to create a Blind Spot to what their history reveals.

There are quite a few folks up here who have old tools hanging on the walls of their homes and barns. For instance, the two-man saw, once important to the lumber industry up here, now it adorns homes like an antique relic. This tool may have been taken down off the walls and cut the bigger trees in peices - using muscle and teamwork. But I don't think it was even considered.

This brought me back to testing. Our methods and tools used in testing change "to keep up with technology". But is this the answer to better/quicker/stronger testing? Yes and no.

It is always good to learn about the newer/latest developments in testing, but it is also smart to remember the roots of testing and to not assume the roots are without merit/pertinence to today.

There are lots of tools and methodologies in today's testing that can be considered wonders/working/snake oil/etc. And there are others that have historically been proven, if even just for the project they served.

Today... there are so many tools out there that could do the job faster... even sometimes better... than the older tools... The two-man saw can be beaten out by quite a few tools, but most folks with projects to tackle of that magnitude could hardly afford them, (I would think) and most businesses/organizations who don't use such tools to capture a particular audience would even consider purchasing them. Because of this, the fact remains that we need to keep whatever tools we have on hand sharp and ready to use.

Think about the tools you have used since you began your career as a software tester. Maybe one of those tools is what you need right now...

To me, the simplest tools, that require the least amount of maintainence, bring about the biggest value for my time, in both my personal life and my career.

Agile Garden Development - Sprint 1

2011-05-14T09:35:00.000-07:00

It all started with a flagpole… I wanted to have one in my yard. A lot of homes in my area just put them up in the middle of the lawn. I wanted something a little more than that. I wanted it to be part of a picture. I like to garden, so I started planning things out.

While beginning to plan out what I was going to do, I decided to incorporate an agile approach to the whole project. I realized I would also get to see what it was like to be in positions of the development that were outside of just testing it… I was going to be:

· The primary stakeholder
· The project manager
· The Business Analyst
· The developer
· The tester
· The end user

An interesting concept…

First, as the primary stakeholder, I needed to determine what I wanted to have and how much I was willing to spend. I wanted a garden that housed the flag and had limited maintenance. I set the cost I was willing to spend.

As the project manager, I began to accumulate what I needed in order to begin the project:

· Flag pole kit
· Mulch
· Available garden tools
· Containers
· Plants

As the Business Analyst, I put together the Sprint in the order that I felt things needed to be done and I gathered the requirements to the best of my ability. For Sprint 1:

· Select the location
· Dig up the sod
· Install the flag pole
· Mulch the area

As the developer, I began to do the work.

In the selected location, I began to dig up the sod. The terrain was difficult as the location selected by the BA had a lot of root sections. (The location was selected to remove a second obstacle from yard maintenance: a tree that caused an allergic reaction in the stakeholder when mowing the lawn. Since it was not a severe reaction, the stakeholder preferred to let the questionable tree live, but when approached with the idea that another garden was being installed, she was delighted to suggest encompassing that same tree.
The digging up of the sod took a little longer than expected due to the roots. The complexity of the roots was not planned for in the estimation, so that was a bit off.
Velocity was beginning to be affected, but when realizing what was happening in Scrum, the Project Manager went in behind the scenes to eliminate a potential impediment by calling in another developer (my 18-year-old daughter). While the second developer had not yet had any experience in developing gardens, the task was straightforward enough that training her did not slow down the process and did help prevent a major hit in velocity.

QA came in behind the scenes and read the requirements for installing the flag pole. They found several issues that would prevent developers from carrying out their task:

· Three inches of rock was needed

· Three inches of sand was needed

· Concrete was needed

This was reported in an impromptu meeting…

The Business Analyst and the developers were stunned… how did we miss that? The Project Manager went to the primary stakeholder and informed her of the situation. She gave her blessing to the funds for rectifying what was found. Development continued…

The developers:

· Began installation of the flagpole
· Began to lay down the mulch

They also ran out of time… The first Sprint ended…

Next Up: The first Demo/Review/Retrospective....

Understanding… When to Call on Test Specialists

2011-05-08T04:15:00.000-07:00

I brought my 7-year-old daughter to the Circus yesterday (not Walmart, the real one that comes to a nearby city each year).

One of the acts that caught my attention involved, what my research later told me, was a Space Wheel:

While watching the act, I began to think about how that piece of equipment might be tested. (I also decided I prefer to test software…). I then began to think about who might test that. Who would the stakeholders of the circus want to test it?

Circus performers can be generalists. The person who walks the high-wire may also tend to animals, dress up as a clown, and perform in other acts as needed. For testing the Space Wheel, the generalist performer may be able to provide high level information such as whether or not all the parts have made it to the next show destination. However; it is highly unlikely that the generalist could provide the information on whether or not it was functioning as it should, once it was assembled. And it is very likely that the end user is grateful for this…

I began thinking about the testing of the Space Wheel (and the different levels of testing it would need) because not too long back I was faced with a similar circumstance on the project that I work on. There were a couple of key areas that really needed expertise, specialists. I brought it up a few times and finally found a couple of allies that helped me help management understand the validity and necessity of such.

This is likely not an uncommon situation. In fact, it may be one of the main reasons that more and more organizations have been trying to get customers involved in the process earlier. And, while this might help mitigate some of the risk, I still believe that a specialist tester would be able to view things with a Systems Thinking approach.

I consider myself more of a generalist tester. I can provide a lot of information about the application/system/product that I am testing, regardless of what application/system/product that is. However; as a tester, it is my responsibility to report when something is beyond my ability/skill set, and to quantify the reasons in such a way that the management/stakeholders understand the need.

Note: When using the term “generalist” in context with what I am writing, I mean it more in keeping with the Wiktionary definition.

Speaking of “context”… if you have not gotten a chance to read “What Being a Context-Driven Tester Means to Me”, by Scott Barber... I recommend reading it... at least once :)

You Know You Are a Tester….

2011-04-30T08:10:00.000-07:00

If you question everything…

“It’s too early to catch fish, middle of May should be good.” “The water is too fast, too high, the conditions aren’t good yet.”

I went anyway. I have been going for a couple weekends now. Even if I don’t catch anything, it is so nice to be out in the woods, near the water, breathing in the atmosphere...

My little one and I go together. She talks and talks and talks… to sticks, to rocks, to the wind, to the water. It is fascinating to hear her gibber-jabber along. She loves the water, which is likely the only reason she puts up with her mother fishing.

We went to our regular “fishing hole” and she went about her talking while I went about my casting.

After about 20 minutes, I was planning on moving down the brook to the next “fishing hole”, when I hear a little voice in my head… “awe, go on, cast once more over there”. So I did. The hook got caught on a log, so I pulled a bit to get it off. It landed back in the water and I started to reel it back in when I felt like it was stuck again. Then… I felt a tug…

I pulled up a 13-inch brook trout…

I was soooo excited, my daughter said I was shaking…

All I kept hearing was the quotes from above… “too early”… “not yet”…

It reminded me of when I just know to run a certain test, in a certain area, under certain circumstances... It also reminded me of times when I found bugs that there “was no way” that could happen. Same feeling, same joy…

Only difference is I get to eat the fish for supper J

Understanding… Seeing things differently

2011-04-23T04:40:00.000-07:00

I have recently been reading What the Dog Saw by Malcolm Gladwell. I must say, there is so much food for thought in it that I can only consume one story at a time without having to put it down and chew on it awhile.

One story: "The Picture Problem: Mammography, Air Power, And the Limits of Looking" gave me quite a bit to think about, especially in light of one of my recent posts on Understanding... The Big Picture. Mr. Gladwell wrote that a physician and epidemiologist at the University Of Washington Harborview Medical Center

asked 10 board-certified radiologists to look at 150 mammograms. The radiologists did not see the same things. The story goes on to describe some of the differences and looks into other examples of seeing things differently with some added analysis.

This first got me to thinking about some of the basic differences in people on a general level. There are different perceptions to what the basic senses reveal between genders. It is an often studied, written about, and discussed topic. Most studies I have read suggest distinct emotional wiring differences. This can cause perceptions to be, at times, remarkably different. Some have suggested that while one gender perceives through the heart, the other perceives through the head.

Then there are cultural differences. I have lived in several states in my country (United States). Each one has its own, very unique culture. Sometimes these differences cause people conflict; sometimes they open their eyes to new and wonderful things. This depends upon the culture one has actually come from, and what they may have evolved their own culture to.

This then, led to my thinking about the differences on the team I work with. We share gender differences, cultural differences, and project perception differences. That is a lot of differences for a group that has, in the end, the same expected goal.

One thing that I believe has helped to lessen the risk of these differences, and increase the ability to succeed, is the agile development process we are using. Like with the gender differences and cultural differences, it takes commitment to the relationship and a desire to succeed, all the while keeping the end goal in site – communication is the key.

Agile development provides the ability to mitigate some of the risk using the Review/Retrospective process. While the tester sees things different than development, the BA sees things different than the tester or developer, management sees things differently than all three, not to mention the stakeholders and the customers… the Review/Retrospective can enable the core group to stay on the same page. Of course, like in any relationship, it takes dedication to the goal in order to accomplish the task.

Another benefit of having these differences is that it can help the entire team aware of the bigger Big Picture, the one that ultimately involves the customer. And, like in all relationships between human beings, this is not accomplished without some conflict. But, another helpful thing in agile development - that has the ability to mitigate the risk of the conflict getting out of hand – is the Sprint Goal. Since the team agrees to the defined goal of the Sprint, a decision must be made and implemented quickly in order to not adversely affect the velocity of the team.

I think that ultimately, if desired, the differences in how we see things, can produce remarkable results.

A Rant... and a Tip Of the Hat... on Privacy Issues

2011-04-20T13:30:00.000-07:00

The software development team that I work with takes great precautions in protecting data for the clients we serve and their clients as well. Sometimes this causes my thinking to be biased. Sometimes I believe that all companies do this. It is never good to assume anything, nor is it good to believe this is always the case.

I make a habit to Google myself every now and again to see what is out there about me. Because I have a fairly popular name, it is not as easy to find my specific person, but it still makes sense to monitor ones own privacy.

Today it was brought to my attention by a developer on the team I work with, that he was listed on a certain people "search" site. He was not happy. I checked for myself on it, I was equally not happy. I found and executed the "opt out" option.

After doing so, I went and researched some more sites that were similar to that one and found myself listed on some of those as well. I was able to easily "opt out" of a couple of them. However; one of them actually said I have to print a copy of a form, photo copy my drivers license, and snail mail/fax it in to them to be removed. Really? REALLY? RE-E-E-E-EALLY???

Yes... really:

There is so much talk about Privacy problems with sites such as Facebook (which I chose to not Opt Into), but yet these people search sites not only have access to your name, but your relatives names as well. There is something very wrong in making people "opt out" of things they never "opted in" to begin with.

I join clubs/organizations when I desire to. I am affiliated with a few that I chose because of their standards/ethics/goals. I have a private /unlisted/restricted phone number for a reason. I don't want to hear the speal about the latest things that will make my life better. I am very selective as to what/who I let in my life - by choice.

But... my choice seems to be getting overlooked when it comes to certain sites. And they are getting away with taking little peices of me and exposing them to countless millions on the internet... without my consent. Some of them even offer to sell information about me - some of which is true and some of which is false - for a membership fee.

Something is terribly wrong with this...

While I have the time/ability to monitor myself as much as I can, my elderly parents do not. They are not "connected" to the internet. They have no way to protect themselves. They only have me to warn them when things are there. And what about the countless elderly people who don't have someone to do so? The scenarios, from a testing point of view, are endless for discovering why this is not a good thing.

Today, while I rant on what I feel is an infringement on my rights as a human being, I also have to tip my proverbial hat to the development team that I am working with for all the thought/effort they put into protecting the privacy of the end users. From security systems to encrypted files... I tip my hat.

I also suggest you continue to "search" for yourself and do your part to make the insanity stop with online privacy issues. Think of the Doormouse in Tim Burton's Alice in Wonderland - while a very small creature, it took the eye out of the beast...

Quick Update...

2011-04-08T13:56:00.000-07:00

I recently received an email from the Association For Software Testing that really floored me. In this day and age where package sizes go down and prices go up... they have actually cut their price for membership!

If you are not already a member, and are seriously passionate about your career, I suggest you go check them out and see what they are all about :)

Also, I recently had my first article published in the Software Test Professionals newsletter. The title of the article is titled "Who are you talking to?". I hope you will feel free to go check it out...

With the ever changing technology that testers are faced with, and with the challenges of time and tasks, these are two great organizations that have a lot to offer in resources/learning and building on skills.

So.... what are you waiting for? Go check 'em out :)

Understanding... The Big Picture

2011-03-31T14:14:00.000-07:00

During my years testing... okay, even before that began... I have always viewed life by things like Newton's Laws of Motion, even before I knew they existed. And please, don't try to engage me on their
specifics, I don't study physics on purpose, they are just there... in nature.

Or, maybe more in line with the Butterfly Effect. "A small change at one place in a complex system can have large effects elsewhere."

In the "system" I work in, that could mean:

1. Each time code is changed in the product/application/system that I test, there is the potential that something else will "react" to it. This can be in a negative way (Bug) or a positive way (Fixed/Fixed
Indirectly/Better Behavior)

2. Each time a new OS/Browser is introduced, it has the potential of being something the customers/end users may have, but our product/application/system does not behave well in it.

3. Each time there is a change in the processes that are implemented for the project, there is the potential that it could cause something else to be missed that used to be a higher priority than the process itself

...among other things, that would likely lead me off topic...

If your intent, as a software tester, is to be the best that you can be, it is necessary to engage in thinking outside the moment. It is necessary to understand that a minor change anywhere could have a major effect elsewhere.

The minor change can be in regards to equipment/tools/management/product/system/application/processes/etc. If you see something
that might have a negative effect on the product or the company, report it. It may or may not be addressed, but I stand firmly on the belief that software testers should "provide information to the people that matter" (paraphrase of James Bach's definition).

It is seeing things with the Big Picture attitude that makes the difference. As a tester, I cannot focus
on one task, "does this work", I need to focus on many at the same time.

Some things that I have found useful in learning this approach - outside of how I was wired at birth - are:

* Read any book by Gerald Weinberg
* Take the Rapid Software Testing course, co-written by Michael Bolton and James Bach
* Always question everything - even why the sky is blue
* Learn about psychology and philosopy
* Read/Read/Read - blogs, books, everything, anything (as a child, I read Grimm long before ever reading the Happily-Ever-After fairy tales...)

Software testing involves understanding there is a Big Picture and trying/learning to see what that Big Picture is...

Hearing the Complaint, Listening for Solutions...

2011-02-08T15:45:00.000-08:00

For a couple years I have been learning how to fish. The Fisherman has taught me to fish from shore, on a boat, and on the ice. I have discovered that I really love to ice fish and along with the lessons I am learning, I have also been acquiring my own set of tools...

Each fisherperson is allowed to have up to five traps on the ice. There are baskets or bags available to fit at least these five traps and the other necessary items, such as extra line and hooks. One problem with storing five traps in the same container is the tangling of the fishing lines. If you have ever had to untangle fishing line, you understand that sometimes it is so frustrating that you create new words under your breath. If you have never had to do so, then be thankful.

A couple of weeks ago The Fisherman gave me a gift. It was a set of Reel Hook Holders.

The set of five hunter orange holders were simply lightly sewed to a piece of cardboard with no company name. I was amazed that such a simple solution existed for such an annoying problem. I was further amazed that no one was taking credit for it – no logo, no company name, address, or phone number. I decided that I needed to find out the origin of this creation.

I Googled the name of the product and found that a seamstress by the name of Penny Hatch, from Penobscot, Maine, who is also an avid ice fisher person, created the simply ingenious solution to the tangled fishing lines. She heard the complaints and listened for the solution.

Why is it important to understand the concept of hearing the complaint and listening for the solution?

In my opinion, we hear the following phrases throughout our lives more often than we should: “That’s just the way it is.” “Deal with it.” “You have to take the bad with the good.” These, and countless other statements, infer that it does not matter that customers are frustrated by the products/applications/services/systems they use. They infer there is no better way. Whether for fun or for business (or both at the same time - if you love your job), we all come in contact with these frustrations every day. And, I venture to guess, that if you are in any way involved in software development, you have heard the customer complaints (directly or indirectly). The question is, are we listening for solutions?

It’s not difficult to grow apathetic or complacent about a project/product/application/system/service simply from being involved with it for a long period of time. It’s easy to lose sight of the big picture where the end user is involved. In fact, it is even easy for the end user to be part of the problem because they have grown apathetic and complacent toward the very things that are causing them frustration. They expect to have problems and they expect to “deal” with them. (Think… popular operating systems…)

Some things that I have contemplated and reminded myself of during my exposure to this woman’s endeavor to make the ice fisherperson’s lives easier:

• Keep learning about what you do
• Learn things you think might interest you
• Be open to learning things you never even thought you would like
• Learn to actively listen to others, don’t just hear their words
• Teach your children to look for solutions when they complain or come across things that are difficult to deal with - ask them to try to find a better way
• Approach things like you should not have to “deal” with them
• When you have a problem with a product/application/system/service, try to understand what the real problem is and report it if you feel it would help solve the problem, or report it to make you feel better
• Don’t settle for the status quo, be the Linchpin, and expect the same in return
• Understand that quality is not just a team or corporate thing, it is a customer thing as well
• Find the lessons in day to day life, they are abundant, and incorporate them in everything you do

P.S. If you do ice fish... this solution for tangled lines is great!

On Simplicity...

2011-01-23T08:20:00.000-08:00

Everyday I use software, I don't just test it. As a tester who uses software I can think of countless examples of empathy I have for customers who come in contact with bugs in the software I test. (Bugs, using James Bach and Michael Bolton's definition of a "bug is something that bugs somebody that matters".)

Usually the examples that "bug" me the most are with the very software I use to log bugs/get reports/test with. I have reported some of these issues to the companies that develop them. Sometimes it gets fixed, sometimes it doesn't. Sometimes I am pointed to a newer version or an altogether different application because they are "no longer developing" the application in question.

We are tasked with finding ways to improve our processes and "work smarter not harder", but the truth is that more often than not in this world of ever changing technology, it is the technology itself that is an impediment to process improvement and working smarter. This is not just in software development, but in just about every business these days.

While thinking about this, I came across a great presentation by
David Pogue, over at TED, titled Simplicity Sells. It is a funny talk, but full of reasonable insight on simple/elegant design for an age of technology where users are constantly struggling with using software.

On Ignorance...

2011-01-22T03:01:00.000-08:00

I recently attended a webcast hosted by Software Test Professionals, presented by Alan Page, titled "Better Test Design for Everyone".

One of the things that I learned about was The Five Orders of Ignorance by Phillip G. Armour. I found this to be an interesting view of software development and since I believe that testing is part of development, I feel it too can be viewed through these five orders.

I thought about ignorance and how it can have both positive and negative outcomes in the development and testing of software.

In a positive light, it is what drives some of the questions that arise in testing. The hope is, as the questions are asked and the answers come, that the level of ignorance is lowered and the questions become the more important ones for the project/stakeholders/customers.

In a negative light, if knowledge is only gained in the development of the product/application/system, and not inclusive of the end user/customer needs, the risk of ignorance is catastrophic. The end result could be a great "storage of knowledge" that is really not what was wanted/needed. (I have bought books that have had this same end result with me. They have appeared to be something useful and ended up on the shelf. They simply do not meet my need.)

These positive/negative lights, among others, are why I like the Agile approach in software development. It involves every level that can be affected by the end result - from stakeholders to customers. It is an ideal approach to limit ignorance.

***Merriam-Webster defines ignorance as "the state or fact of being ignorant : lack of knowledge, education, or awareness". This definition led to a philosophical discussion in my head. While the concrete part of me seeks to achieve a level of knowledge that is completely removed from ignorance, the abstract part of me believes it to be un-wise to ever embrace that level. If I look at learning as a never ending process, and if I believe I have reached a level of knowledge that is removed from ignorance altogether, then might I find myself back to the level of "not knowing what I don't know I don't know"?

My "Cheat Sheets"

2010-12-16T14:59:00.000-08:00

I have worked on an agile team for about 18 months now. I have really enjoyed the time I have spent on this team and the challenges that have required me to stretch my skills and use my imagination.

One area that I stumbled over for a period of time was what I needed to have for documentation. I wanted to make sure that I had quick access to the requirements that were implemented into the application/product/system. These requirements were generally located in PBI’s (Product Backlog Items), specifically in the COA (Conditions of Acceptance). The application where these items are stored is often slow and hard to search. And the COA’s of some of the items lacked information that may have been transferred either by word of mouth or email during any given Sprint. While these items of information were documented within the system, they may have been documented on the SBI level; therefore the information on the PBI would be incomplete.

Over the course of a few Sprints, I developed a bit of a “cheat sheet” system which has saved me oodles of time and frustration. It has evolved, and will likely continue to do so if the need arises (what Agile is all about to me). All of the “cheat sheets” were created using Excel spreadsheets.

User Story Headlines – 3 Column Headers containing:

• User Story Number – for easy lookup in the system where the stories are located
• User Story Title – for locating a particular story by name
• Feature/Function document location – for listing which spreadsheet the “requirements” can be found in

***I actually have a How to Use this Document tab as well... in case I "get hit by a bus"...

Feature/Function document – 2 tabs (one for “requirements”, the other a navigation checklist)

Requirements tab columns:

• User Story Number – to trace the requirements back to the appropriate PBI
• Priority – How important the tester feels this needs to be verified
• Test Case Headlines – This is where the actual requirements are documented in what I suppose could be called test case shorthand… These are brief statements about the feature/function requirements describing (generally in one liners) what the feature/function should or should not allow/do.
• Notes – If a requirement has changed, it can be noted here. Also any other helpful information or definitions that might save time or be beneficial. – In this column I use a different font color in so that it draws attention.

Navigation Checklist tab columns:

• Navigation Item – the name of the item goes in this column
• Condition – conditions of the feature/function at the time of selecting the navigation item
• Expected Results – what the results should be when the navigation item is selected under the given condition

Menu Item Checklist – 4 columns, similar to the Navigation Checklist tab from the Feature/Function document, but encompasses the entire application/product/system by including every menu item available.

• Main Menu – lists the main menu name
• Menu Item – lists the name of the menu item
• Condition – condition of the application/product/system at the time of menu item selection
• Expected Results – what the results should be when the menu item is selected under the given condition

I have found some benefits in keeping these documents:

1. It is easier for me to search for items in the spreadsheets than it is in the system the PBI’s are stored in.
2. It is easier to find a PBI number in these documents to trace back to the original requirement when writing up a Bug; which when noted in the Bug saves development time in looking for them.
3. They are lightweight, but contain more than adequate information for checking that the application continues to hold true to the requirements.
4. They contain enough information to be useful as a training tool for testers that are new to the project.
5. They provide traceability to the requirements themselves.
6. While they are not test cases, they are beneficial in creating test cases

*** I know I could reveal more details... but I won't... because figuring out what YOU need to document for your team... that is something only YOU know :)

follow up to last two posts...

2010-12-02T14:41:00.000-08:00

Joe Strazzere commented on my last post and inquired of what book I am reading in the photo I now have on my blog.

First, to answer the question, the book is The Importance of Living by Lin Yutang. This is a book I bought back in June of 2009 after reading Rob Lambert's post titled The Importance of Testing. He wrote a little bit about the book and links he made between what he read and testing. I like philosophy and learning about it, bought the book and began reading it. This has not been a book I read through all at once. It is one of those books that I pull out every now and again for some sense of thinking differently or of savoring some wisdom from a time ago... I like the book...

I actually had to search for the original blog post in order to locate it and link to it in this post. This made me think to just mention to anyone who might be new to testing and just reading up on current posts... use Google (the company I love and hate...) and search for topics of interest in software testing and other things. There is a wealth of information in older posts on retired blogs from many testers...

The second thing I wanted to mention, that I thought was quite important, is the Michael Bolton series on estimation - it's a must read. If you don't have time to read (and re-read as I have) the whole series, do indeed read the final one in the series, Test Estimation (It is actually titled "Project Estimation and Black Swans (Part 5): Test Estimation", but the link feature in this blog would not accept that title... bug... oy) at least once. If you struggle with this (estimating your test time), despise this, must/already do this, are being threatened with having to do this, or want to do this better, Michael Bolton likely has the words that go with the thoughts in your head.

Blog Update...

2010-12-01T12:38:00.000-08:00

I started blogging about my career as a software tester in 2008. I decided to update it a bit since it has been a little over 2 years since I began.

Because the background color was pink, sometimes people confused that for my favorite color. This always led to the story of the "ugly" bug...

Years ago I was testing an application/product/system and marketing decided to do a bit of a logo/color change. The application/product/system was used by professionals, likely of the middle aged group... male and female. The color change caused some parts to appear not just pink, but Barbie pink. While this color is great for Barbie and her friends, I was not so sure that if I were a middle aged male, I would want to view this color every day I worked.

For weeks I tried to convince development to change this, but I kept getting told it was a marketing decision. I don't let up easily when it comes to things that I really think will bother the customers. After a couple of weeks of trying, I went up a level. The application/product/system allowed signatures in a certain part of it, I created a Barbie pink signature and placed it in whatever places it could go in. This finally caught the eyes of the developers and a small change was made that turned the color to a brick red shade vs. the pink.

Ever since then I use pink as a test for lots of things. I have bought some things in pink just to be a pain... including a pink fishing pole :)

The photo I had for blog picture was also significant. A high school friend of mine from Costa Mesa High in sunny, southern California contacted me. We talked for a while and he wondered how I could possibly live so far away from the ocean after all the years I spent near it. I took the picture to show him that I just have a new "ocean" of snow, and sometimes it got nearly as high as the sea water did when wading in it.

So there lies the story of the color/picture of the blog's beginnings...

What the investigation revealed...

2010-11-30T12:27:00.000-08:00

I wondered what I did in a "typical" day as a tester, so I investigated my activities. I found out a few interesting things about me, about what I do...

The first thing I found is that I process things while I sleep and often wake up and write them down. Sometimes this is related to testing and sometimes it is of a more personal light... I can go to sleep with a puzzle in my head and wake up with the answer in the morning, and if not the answer, at least another piece of it. I like that this happens... even if I am not completely sure of why it does...

The second thing I found is that I test people and things all day long. I sometimes wake my children with tests... I might say something completely off base to check their "balance"... I might simply ask a question that makes them have to think first thing in the morning... I find this testing of my girls makes them sharper than average, more observant of words and body language. I guess, in a way, this type of testing is teaching.

Aside from my children, I often test my co-workers by taking what they say either literally or off the beaten path and repeating it back to them in a way that they see what they said differently. (This is also quite fun, especially when others play along.) I also test people I run into every day, such as the cashiers at the local stores. They may tell me how much money I saved making a purchase, and I will tell them I saved nothing, I spent such and such amount... The response is generally a look that says "I never thought of that" (the response/expression we likely all give when we find out we are looking at something one-sided/one-way).

The third thing I found is that I test for longer periods of time than I thought. I connected the fact that as I document, so do I test. I never document anything about the application/system/product in test without having it open and without "doing" what I am documenting. The same is true when I test documentation that is given to me to check for the application/system/product - such as help files/knowledge base write ups/user guides. This is still testing and still reveals bugs that I may have overlooked, were implemented incorrectly, or documented incorrectly.

The fourth thing I found is that I constantly test the processes. I constantly ask "where, what, why, when, and how" about all of the things I do. When I say "the processes" I include what I do when I test. This proves to me that I can never completely test anything... Why is that? Because one day I may be focused on performance, the next day I may be very nit-picky and go after the small things that seem to pose usability issues. I may decide I am going through "good book withdrawals" and concentrate on being an editor for the day by reading through documentation or checking out the overall look of the application/product/system.

Because I can come into testing with any one of many "persona's" on any given day, and because the application/product/system continues to evolve, I may find something six months later that I would have found earlier if I had my certain "test face" on that day.

The fifth thing that I found (and the final that I will mention here), is that I cannot actually track what I do in a day to a perfect measure. In fact, I have found that attempting to do so actually cuts my creativity and time spent testing.

How can I track my time spent on any one activity when it is actually only an estimate? How can I estimate the time it takes to test something when I could be the nit-picker one day and the performance tester the next? I should say, "how can I accurately" give time to these things? If I go to sleep at night and wake up and jot down on paper three things I need to test, do I write the time down and add that to the time spent testing? And what about the time I was sleeping... how do I know how long I was processing during that time?

Maybe I am just "testing" this part of what I do more than I am testing the others because those activities are so natural that I don't really have to think about them. Maybe it is because I have an aversion to measuring what I do. Maybe it is because I have a problem with the gap between "estimated" time spent versus "actual" time spent because of the fact that it is not going to be exact. Maybe I am over analyzing the measurement factor because of my experience in a 10Th grade algebra class...

Through this investigation, I have pretty much concluded that while there are typical activities done nearly every day in my job, there is really not a typical day. I believe this is one of the reasons that I love testing, it is not typical, it is ever-evolving, and it is challenging.

And I just received Michael Bolton's "highly sporadic newsletter", which just so happens to have "Project Estimation and Black Swans" as one of the topics. I will begin reading the "five part blog series" tonight. Talk about timing :)

What do I do in a "typical" day?

2010-11-02T02:12:00.000-07:00

There will be changes to some processes for the team I work with. Since the changes will impact the time I spend testing, they got me to thinking about what it is I do in a "typical" day.

With thinking, along comes a bit of research... I wondered if anyone else has attempted to sum up a typical day in software testing. I found
A Day in the Life of a Tester, and read through it quickly.

In this description of a typical tester's day, about 4 hours and 40 minutes was spent actually testing - of course no distractions are included in this time frame. No visitors or phone calls or interruptions.

Also no meetings or documentation are included in this "typical" day of a tester....

This article on How Does a Software Tester Spend a Workday? really floored me. It says, "software testers spend most of their working days removing bugs and defects from programs". Yes, it seriously says that...

Google aside, time to actually think about the subject at hand, what
activities do I do in a "typical" day as a software tester... And how much time do I actually get to spend testing?

I think I shall investigate this...

This is broken...

2010-09-28T13:09:00.000-07:00

I listened to the Seth Godin video, called This is broken three times in a row today. I found it to be so true, and so thought provoking I actually used the link as a tagline for an instant messaging application that I use at work.

I am a big fan of Mr. Godin, his work is something that makes me think differently and gives me insights into things that I might not see if someone else did not shine a light on it.

In the talk, Mr. Godin points out 7 kinds of broken (broken things appeal to my QA/Software Testing hat)....

1. Not my job
2. Selfish jerks
3. The world changed
4. I didn't know
5. I'm not a fish
6. Contradictions
7. Broken on purpose

I find I can apply all of these to what I see daily in my career as a software tester...

I challenge you to watch and listen to this video on TED and not come up with some ways you can relate what you have seen in your testing career.

Oh... and I challenge you not to find humor in all of it...

An Ordinary Pocket Knife...

2010-09-25T04:54:00.000-07:00

I had a conversation with a co-worker the other day that went something like this…

She said, “We should be able to do that with all the new technology available.”

My reply, “It is not the tools that matter; but it is the hands that hold them.”

I proceeded to talk to her about an ordinary pocket knife. In one person's hands, it is a simple tool they use to cut things with. In another person's hands, it produces works of art. Check out these Civil War Soldiers, carved "mostly with a pocket knife".

While doing some research on whittling, I found that the majority of the folks who do it, do it because they simply love it. They have a passion for doing it. Like Lawrence Spinak who notes on his site, "I whittle for fun, not for money. I don't sell any of my works, nor do I work on commission. Please don't ask." Be sure to check out some of his stuff by clicking on the My Work button. They are amazing peices of art.

I also found whittler0507's channel on You Tube. This fellow has oodles of videos where he shares his knowledge about how to carve things. He doesn't just have a passion to carve, but a passion to teach others as well.

The BEST do what they do because they cannot help it. They have a love/passion for what they do. They willingly share their knowledge. They constantly build their skills. They don't rely on A tool, they rely on the insight they have developed throughout their lives. By practicing what they love, they become the Outliers in their field. They become craftsmen/women.

It's not about the technology, it is about the people that use it. I have no doubt that "we should be able to do that", but it is the "we" that will do it, not the technology.

Mind Stretch...

2010-09-01T16:09:00.000-07:00

The human nature in me can cause me to be "stuck" in places, so I try to avoid this by reading blogs and newsletters on innovation and creativity. One of the emails I recieve comes from destination innovation.

The recent email newsletter contained this video:

When I first watched it I thought it was cool and creepy at the same time - who really likes clowns?...

But when I watched the "making of" video that is linked to it... I realized I "again" missed something... so it stretched my mind to think differently...

How Do You Eat An Elephant?

2010-08-03T03:33:00.001-07:00

It was a very windy day up here in Caribou, ME about a week ago. My house is surrounded on three sides by trees. A particular tree out back is where I tie Henry, my German Shepherd during his "out" times. When I came home from work that blustery day, Henry's tree was broken in half. Half of it was stuck in the ground,
peirced through like nothing I had seen since I left the coast of Massachusetts and lived through hurricanes.

After being amazed for about 5 minutes, I picked my jaw up off the ground and thought about what to do next. I first considered automation. I called my sister and asked if her husband, who had a chain saw, would be able to come and assist me. 24 hours later, with no response yet from him, I called a tree removal service to come by and give me an estimate... still hoping for an answer that involved automation...

The next day my brother in law called, he said he would be too busy for the next few days, but if "a male friend of mine" would like to borrow his chain saw that would be fine. The tree removal man called within hours of that with his estimate... which was alot more than I had thought...

While looking at the tree, I got to thinking... "a male friend of mine".... "A Male Friend Of Mine"... "A MALE FRIEND OF MINE!"... what did that imply... that only a male could take the tree down!

A tad bit irritated by this whole inconveinance, I started wondering... what tools do I have to do "something"... "anything" about this.

The tree was unsafe to have hanging up on itself like that. Henry lost his tie out, and I have a small daughter that could get hurt if she was out there when the tree fell the rest of the way.

I went to my shed. I found some really simple tools - a bow saw and an old extension cord - I had to use my rope for Henry's temporary tie out since his was under the tree.

I decided to cut off the excess branches with my bow saw - the blade was not fresh, it was old and had been used to cut down pine tree boughs for years, to keep the
branches high enough to mow and garden under. I cut off all the branches that I could reach.

The next day, I decided to employ a new thing. I would cut about 2 feet up from where the tree impaled the earth and then loop the extension cord around the tree and pull... I did this three times... each time the tree would fall nearly in the same place and it would still be leaning against the half that was still standing.

About a couple hours later, I decided to make a cut four feet up and perform the same actions, though it was a bit harder to do this time due to the thickness of the
tree.

When I finished pulling, cutting, pulling, cutting, over and over, the tree decided to land one more time up against itself, but this time I knew it was leaning there
without a grip. I took the saw and cut whatever branches I thought would try to "get" me when I pushed the tree... and then I pushed it... over it went and it made a thud as it hit the ground...

Up went my arms as I shouted "Victory!". I had eaten the elephant one bite at a time...

I had manually done what automation could not deliver - with simple tools.... a bow saw, a cord, and my brain...

And then there was the challenge... the cost of "automation" and the response from my brother in law playing in my head....

Before this begins to sound pathetic, I will say that two friends of mine did offer to help me out. These friends are as busy as me, and work just as hard, I took the tree down before I told them what the estimate was because I did not want them to have to do so, and because I have a stubborn streak - I admit it - especially if I am told that I cannot do something.

I could not help thinking about the "simple tools" and "automation" part of this whole endeavor, and how it reflects some things that I have learned in testing.

Simple tools like blank text documents and checklists can be really useful in testing. And just because automation may be too expensive or unavailable for a project, it doesn't mean the job cannot get done successfully. Sometimes you just gotta remember how to "eat an elephant".

Pay Attention...

2010-07-04T17:51:00.000-07:00

This video pointed out a weakness that I personally have. I love the old murder mysteries... Hercules Poirot, Agatha Christie in general, Alfred Hitchcock... I used to watch them over and over again... but I found this video actually tripped me up...

Sometimes it is essential to observe things without bias... with "new" tactics... paying attention is important, and learning to limit your bias behind the attention is key to observing what is actually going on. This is why I like stumbing across things like this video... they help me remember I do (indeed) have biases... and need to keep them in mind for testing...

A Simple Tool I Use...

2010-06-30T15:36:00.000-07:00

One of the simpler tools that I have and think comes in handy for my testing is a Menu Item Checklist. It is devised simply and kept in an Excel spreadsheet.

I list the Main Menu, then the Menu Item, then the Conditions, and finally the Expected Results. I have found some good benefits of this list that seem to not lose value:

1. A new tester can easily go through this and learn something about the application/product/system in test.
2. Changes that are not communicated through the development process can be found if they directly impact any of these menu items. (I have seen this first hand... )
3. It helps to verify that nothing has changed without permission on an updated application/product/system.

How often do I utilize this tool? When new features are added that also include menu items, I might pull it out and make sure the previously added items still have the expected results now that the new item is added. I might look at it every now and again during a defocusing session to gain fresh ideas, add conditions, or perform regression testing.

How do I know this tool has value? I have seen it in action. Menu items added/deleted/changed without information/communication from development or product management.

This is a simple tool, but I feel it has value in reminding me of what the expected/designed/required results are for the menu items. And, in my opinion, it does not cost much time/money to maintain.

"That's not my job"

2010-06-24T13:09:00.000-07:00

There is an old story, from an anonymous author that

goes like this:

This is a story told about four people named, Somebody, Everybody, Anybody, and Nobody.

There was one important job to be done.

Everybody was sure that Somebody would do it, but Nobody did it. Somebody got angry about it because it was Everybody's job. Everybody thought Anybody could do it. Nobody realized that Everybody wouldn't do it.

It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.

I came across a situation very fitting to this story just this past week. A bug was let loose due to it - and was allowed to live in the field for quite some time. I admit I am disheartened when I come across stories like this.

Maybe it was because my formative years were spent poor. Maybe it was because my family instilled in me hard work ethics. Maybe it is because I spent years raising my four girls on my own. Maybe it is because I have little fear and believe there is always a solution to a problem. Maybe it is because I was raised to do something if I saw a problem instead of complaining. Maybe it is because I have pride.

Whatever the reason is, I don't have much tolerance for the pass-the-buck syndrome. I don't have much tolerance for a people distancing themselves from the team. And to me, the team is the whole system of people in an organization, not just the little groups or departments.

I know a developer that reports bugs when he finds them. I know product managers and business analysts that do the same. This never injures my pride, it builds it. When they find something I overlooked, I am glad they did, especially if it is before our customers did. And I learn from it, if/when I can.

I know a class A tester that answers customer support call issues when asked to. And she does it with a smile and a sense of gratification that she helped someone out. I know a manager that stays late nights and helps the test team test when it gets close to release/shipment. He rolls up his sleeves and asks, "what can I do?".

I know of a front desk/reception lady who comes in occassionally when there are late nights and brings around a candy cart to keep the troops fed when testing.

And then there is the other side... the side of fear. Those who won't "cross the line" for fear of "stepping on toes" or taking on jobs that are not theirs.

In 2008, I wrote a blog titled This reminds me of when I was a waitress. I still believe the job I do is service oriented. When asked a question, I will answer, "let me see what I can find out", "yes", or "no". Sometimes I take a couple days and think things over - I plan. Sometimes I answer right away - if my schedule will or won't allow it. Sometimes I offer to help even if I have no clue what the solution is.

To me, the whole thing that I do is for the customer and me. I take pride in what I do and I do not want the customer to find issues/bugs/problems before me... I like the challenge in that part of it :)

Today, it takes more than doing your job, as set by the description, to make a difference in the end result or to add value to the organization, the product, the project... Stop being afraid... be ready/willing/able to not just "inform" the stakeholders, but to serve them as well.

article claims Google Chrome 5 is bug free....

2010-06-24T11:45:00.000-07:00

Personally, I like Google. I use the search engine like no one's business. I have an iGoogle page that I set as my Google Chrome home page. On iGoogle I have three pages worth of gadgets to give me articles and links to topics I have interest in.

Though I have pointed out their lack of concern over my own personal privacy, I still use them to keep an eye out on/research lots of things, including myself. I look forward to seeing/using/testing with (hopefully) the Google OS as well.

All this aside, I read an article today that made me laugh out loud and write this blog as a challenge to my fellow testers. Bloomberg Businessweek author, Nathan Alderman, proclaimed in the first sentence of his article on Google Chrome 5 "Bug-free and beautifully designed...".

I do not believe that any software/application/product/system designed is bug free. I do not have a Mac, nor do I currently have access to one, so I put this out there for those testers who do...

My question/challenge to those of you have a Mac and have installed Google Chrome 5 on your system... is this browser really bug free?

A Challenging Validation...

2010-06-17T12:39:00.001-07:00

My 20-year-old daughter and her fiance came to visit from Nashville, TN for a few days for her 17-year-old sister's high school graduation. We took a lot of pictures, of course, and she decided to go to a local pharmacy to get hers put on a CD for us to have a copy of a couple of hours before her flight home.

After ordering the CD, she was told it would take about an hour to finish, so she gave me the receipt and went to lunch with her sister before her flight home (I would be meeting them there after picking up the CD.)

I went to the pharmacy when the hour was up. A young lady came to assist me and to inform me that originally my daughter selected the Express option through the photo kiosk, and this was out of order. She had my daughter select the Today option and they thought it uploaded, and evidently there was an issue with that option as well.

I talked with her and asked her a few questions about it, then agreed to just get a refund on the CD. She then stunned me by saying, "Thank you for not yelling at me."

I asked her, "why would I yell at you?" She told me that people are "funny" about their pictures. I told her I test software, and that I understood that it was the technology that had the "bugs", and I understood that it was people's frustration with it that caused them to be "funny" about things, and that I was sorry that the customers took it out on her.

I kept thinking about this conversation for days later... and I took it as a personal challenge to continue to grow and improve as a software tester...

And I challenge you to do the same... conversations like these validate the need for testing professionals in software development.

What's on your walls?

2010-06-04T01:58:00.001-07:00

I recently read a post called What's on your office Wall? by Jeffrey Phillips on his Thinking Faster blog.

This post inspired me to take a look around my office and share what inspires me throughout the day when I need a bit of motivation...

This question mark was painted to match the surrounding ladybugs by one of my daughters. The collection reminds me that it is in questioning a product/process that I find bugs....

On the wall to the right of me, the first thing I see is the art work my girls have given me over the years I have been at my current organization, and a mirror that has a sign over it that says, "People Problem? Check with this person first."

Moving to the right on that same wall is a bookshelf with my "bug babies", real "babies", and two of the books that have inspired me on my journey...

Lastly, on that wall, are the slinky hanging from the ceiling that makes space invader noises when pushed up from the bottom - for stress relief... and the two certificates that mean anything to me. One is from the completion of the Rapid Software Testing Course that Michael Bolton taught our group some years back, and the other is the tongue and cheek All Things Quality Certification that was given by Joe Strazzere.

On the wall directly in front of my desk, I have a Dream Your ABC's poster to remind me to be positive in what I believe, a National Sarcasm Society tin (cause I can be quite sarcastic), a Michelle Street sign that was given to me (with a personal bug, since my name has one "l" in it), a Patton quote, and a sign that reads "Everyone brings joy to this office, some when they enter, others when they leave."

My walls that surround me combine inspiration, motivation, and humor... what's on your walls?

Privacy... Online... ?

2010-05-31T02:25:00.000-07:00

I find it funny that people are just beginning to concern themselves over privacy online. I read an article today on people getting ready to quit Facebook as of today over concerns about privacy. The thing that is funny to me is that this concern is over a site where people willingly signed up - and I wonder how many of these people have googled themselves to find the oodles of other places where privacy was taken away from them - without their permission.

Take Google maps for instance. I put in directions to take my daughter to a school mates birthday party, only to find that there was a picture of my house available. I had to ask to have it removed, not give permission to have it placed on there. And researching into this a bit further, I actually found pictures of people on some of the images of houses along with vehicles with viewable license plates.

And then there is Intelius, a people search site that gives not only the name and city on a person that is looked up, but lists possible relatives that are viewable to anyone - even without a subscription. I have not joined the site, but I wonder what other info they offer... again, without permission.

These are just two examples of how much, or rather how little, privacy is really concerned about online. You have to be proactive to keep guard over what is out there on you. I google myself every now and again to see if there is some site that has encroached on my rights to privacy, and I am likely missing some places where this has happened, and I hope that if I am having difficulty finding it, so will others...

I am not on Facebook, I never signed up for it because years ago I signed up for Myspace when my children were younger and joined it. I found the whole thing to be way different than what I expected. I thought it would be cool to connect with people from different places and share cultural exchanges, but instead it was like an online dating camp for weirdos... No thanks, I prefer finding places to network and connect with people who share similar interests with me... when I have the time. Whether that is in person, or on sites dedicated to the things I do, such as the Software Testing Club.

Going after Facebook due to it's privacy settings is a good thing, but what about the rest of the sites out there that quietly trespass on the rights of Average Joe? The Web is world wide, and until they figure that out, I will continue to search for myself online and "opt out" of anything that has taken advantage of my rights to privacy.

Best Practices... ?

2010-04-29T03:51:00.000-07:00

For who? When? Why? What project/product/process? Where is it best? How is it best?

Something happens to me when I hear those words...

If the goal is to achieve best practices and incorporate them across the board
within an organization, doesn't that stifle creativity? Doesn't that place the process over the people?

Innovation: Is there such a thing as 'best practice?', a blog post written by Derek Chesire sums up simply the belief that folks looking for best practices are believing there is "one true way".

To me, chasing after best practices removes the creativity, process improvement options, innovation, and artistry that people can contribute to what it is they are doing.

If there are three children in the family, they are three separate individuals, even if they come from the same two parents. If you have raised any children, you will know that no two of them are the same. The same practice of the simplest things, such as the bedtime routine, will not apply to all three children. Looking back in history, doctors used to send new mothers home with instructions on how to "schedule" the feedings, nap times, etc. of newborn children. I wonder how many mothers ripped the instructions to shreds while questioning what they were doing wrong before they caused the hospitals to stop sending them home with these "best practices" for taking care of newborns.

Add to this thought the studies that have been done on birth order, the differences of gender, cognitive differences, health differences, size differences, etc. The revolution in thought brought about by Dr. Spock, who helped teach parents to value their children as individuals. It is impossible to have a "best practice" that applies to all three children, or even to two for that matter. Parenting children is the epitome of agile development.

There are, undoubtedly, somethings sometimes that need to be done in a standardized way to provide what some stakeholders want or think they want, but we should always be on the lookout for better ways of doing things...

If practicing something can help you become an expert at it, that implies that things have the option, the need, to change/flow/grow. To me, the "best practice" is the one that works today and looks to change/flow/grow for tomorrow. To me that embraces the "practice" in "best practices".

Fishing Lessons...

2010-04-28T17:38:00.000-07:00

Matt Heusser recently wrote an article for Sticky Minds titled The Fishing Maturity Model. This article made me think about what I have learned in the near-a-year that I have been learning how to fish...

My first time was at a river with a casting rod and reel that belong to my Teacher. I spent most of the time watching him fly fish down the river from where I was. I had no idea what I was doing at all. I did catch one fish, which I had to release due to the size of it, and that made me feel excited about the whole thing.

The open water season closed right on the heels of that experience, but my Teacher invited me to go ice fishing. In all my years I never thought that I would stand on the ice in the middle of a lake and fish through a hole that was drilled through it. (One good thing about ignorance is that I did not realize how thin the ice was when I first ventured out on it... It started out about 4 inches thick and by the end of the season it was close to three feet thick!)

At first there were no rules to follow other than what the governing forces have in place (conservation, size, limits, etc.). During this time my Teacher let me have fun. Then it was time to learn.... and learn by watching and asking questions. I am curious by nature, so I tried lots of tactics... none of them rewarded me with a fish... I was bankrupt with catching any for quite some time. What changed? Me.

I liked the challenge of catching a fish, and the joy of actually pulling a fish through the hole, not to mention the satisfaction of finding wonderful recipes to cook it and finally eat it :) So I became patient and persistent, and by end of season I may not have caught as many as my Teacher, but I caught enough to be happy with the outcome and to be content to understand I was learning from someone who had fished for many, many moons... an expert.

When open water season began again this year, I took my six year old daughter fishing with me several times alone. (I should call it practicing casting because I caught nothing.) The joy of sharing this time with her surpassed what any that catching a fish would do for me. Her and her Barbie fishing gear which contains no hook yet, but a butterfly practice "thingy" on the end of it, she can cast with the best of them and is so proud of how far her butterfly goes. She learns about nature, biology, science, life... all while being in the quiet surroundings of the water and woods. It is beyond words to describe how special it is to spend that time with her apart from technology and the noise of this world...

But, for the subject I am trying to tie together here... I went with my Teacher on a fishing trip to a couple of brooks recently... Because I already learned to listen and watch (and because good teachers sometimes just give you a really good tip), I caught a couple fish. Some of them were too small to keep and had to be released, but the knowledge I gained and the experience I had catching them, was priceless.

How does this tie into Matt's article? I went to several web sites and so called "experts" to learn about fishing and learned that I wasted time and money on things that did not produce the "expected results". Finding a Teacher, a Mentor, an Expert... is priceless. And the funny thing about these people is that most of them never actually feel like they have attained what they think an expert is, but they seek to achieve it constantly. They share knowledge of what they do and if you are "listening" to them, you will hear the secrets of their success.

I have had exposure to such people in my years testing as well. People from all over the world who have had advice/tips/thoughts/philosophies on testing and on life that have affected me or made me think differently or given me ideas or inspired me in some way, shape, or form... and I am thankful for all they have shared.

I blog for myself... It is a way for me to express things that I think/feel/believe. My blog title speaks volumes to who I am as a person... Losing Focus is a wonderful thing because it gives you a new perspective on everday things, helps you to "see" things outside of the box...

It was suggested to me to start a blog roll by a tester I admire and have learned from. This blog is dedicated to him and the testers that have taught me much. Because like my Teacher, they have exposed me to some very valuable lessons and they are the beginning of my blog roll... with thanks:)

Self Evaluation...

2010-04-22T02:04:00.000-07:00

Every week I take my trash out to the curb in two 34-gallon, wheeled and covered, trash cans. It takes me a few minutes to get them down the sloped drive, so I usually put them out the night before so I am not rushing around the next morning. More often than not in the morning, I end up seeing the sanitation man come to dispose of my trash. (This is likely due to the noise of the truck when it backs up.)

After taking the trash out of the cans, he always places the covers neatly back on the containers and puts them back in line. This behavior is admirable. In all the years that I have had sanitation pick up services, no other person has been so tidy with my cans. At the least, the lids would be put inside the cans. At the worst, the cans would be tossed back to where they originally stood.

In the winter up here in Northern Maine, we generally get about 116 inches of snow. The city has people that are paid to plow the roads when the storms come. The experiences I have had with the man who generally plows my road have been anything but pleasant for the two winters that I have lived in this home.

The first year went something like this… I would get up really early in the morning, head out and shovel out my drive… yep, shovel. At the end of the drive, I would push the snow pretty far out to both sides so that I would be least likely to end up with that great big mound of snow that can come from the plow when it passes by. However, when the plow man would come he would make two passes by my drive – on the same side of the road - from both directions. I would see him do this from my window just about every time he plowed.

The result was generally a 3 foot high by 4 foot wide barrier between me and the road. I would have to suit back up and shovel the heavy stuff he left me back to the sides so I could exit the drive in my car. Four storms later, I reported him. The two swipes went to one, but he still caused me to have to redo all the work I had done.

The second year was not as bad for two reasons. The first reason was we had a lot less snow storms. The second was that a friend of mine let me use an extra snow thrower he had on hand. But this plow man still managed to show some poor ethics. My six year old daughter watched as he plowed over my trash cans one morning, knocking the lid off one can and causing the trash bags to tumble out. He did not rectify the situation but continued on his way.

So what’s the deal with these two stories? I have thought about a few things when watching these two completely different men provide their services.

I thought about the differences in their employment. The plow man has a city job. Generally speaking, city workers have pretty decent benefits and pay. The trash man is self employed and in competition with at least two other companies who provide the same service. Again, generally speaking, self employed, small business people have a much harder time financially. They have the stress of keeping their business alive on top of providing services.

Another thing that comes to mind… The plow man knows how I feel about him because I had placed a call to his supervisor. The trash man, however, has no idea how I feel about him. Others do, however. He has been a story I tell about ethics and service oriented work for the last year, to several people, including my children. I admire him for his simple, honest display of ethics and service.

Evaluation of other service oriented employees is pointless if I don’t apply the same rules of engagement to myself. How do I ensure that I am doing my best to serve my co-workers, customers, organization, family, friends, and myself? How do I check to see whether I am being viewed more like the plow man or the trash man? How do I figure out what I need to change/improve? What parts do I have the power to change/improve?

At the organization I work for, we are required to do annual self-evaluations. We have key competencies that we rate ourselves along with how well we achieved our goals that were set the previous year. Some people may look at this time of year with dread because it is something they really don’t like to do or they somehow do not feel all that comfortable evaluating themselves. Personally, this is something I do on an ongoing basis throughout the year. In order to improve any aspect of myself, I have to start with an honest look at where I am now. That helps me to determine if I need to up my skill set, change my communication style, improve processes that I use, eliminate wasted time, organize things, etc. This is something that is beneficial on a personal as well as professional front.

Testers have a tendency to be “evaluators” by nature. Always questioning what they might be missing in coverage or what the product/application/system might be missing. This same evaluation, when applied to self, helps me to see where I was, where I am, and where I am going by helping me to set goals of what I would like to achieve/change/improve/etc.

*An added bonus of personal self-evaluation throughout the year: filling out the annual self-evaluation at work only takes me 10 minutes… :)

Everyday Usability Issues

2010-03-16T03:01:00.000-07:00

There are certain things I do everyday, or nearly everyday. From washing things like dishes and clothes to personal hygiene. Most of these things I do involve the use of one or more products. Recently I have found that some of these products have packaging that has what I would call usability issues.

I have two examples of what I am referring to. The first is Crest Pro Health toothpaste.

The package is designed so that it can stand up. (I have children, so the idea of the tube remaining in a stand up position is quite unlikely.) The design of the packaging also makes it quite hard to squeeze the paste out and onto the toothbrush once the level of product has been decreased. This factor made me feel as if quite a bit of the product went to waste once I could no longer bring myself to attempt to get the toothpaste out of the tube without talking to it in a fairly unfriendly way.

The second product is Downy Simple Pleasures fabric softener.

I have found that while the package is pretty it is not very user friendly. The user can only pour the liquid when holding the container in a certain direction due to the spout design, but this direction is not apparent on the package. More often than not, I found that after I took the cap off I had to turn the bottle around
before I could pour it. While this causes no real harm, it is annoying. When I have to sit there and line up my softener bottle in a certain way to stack the odds in my favor of not having to turn it around in my hand, that is one more step I have to take to get my laundry going.

Both of these products allow me to do my job, to get done what needs to be done. Both of these products have reputations for having a certain level of quality. But both of these products have pretty packaging that makes me have to think about what I am doing; while the tasks I am set about to accomplish are everyday,
mundane things that I should not have to think about.

I have to wonder what the target audience was for the changes and if the packaging changes were tested by actual consumers or if it was just for marketing purposes. Upgrades and redesigns should make the life of the consumer easier or better in some way. Take for instance the pop-tops that are now on most cans. Every now and again I do think about this when I go to feed my dog and do not have to search for the can opener. (Of course that might be due to the fact that I am old enough to remember having to use a can opener on every canned item that was purchased, and what a pain
that was.)

Usability is one reason that I am appreciative of the Agile model's "Release Early, Release Often". While I find bugs in the software that I test, the likelihood of my finding the everyday issues that bug the customer are not as high because I am not using it for the same reasons.

Involving the customer early on in a project, generally through the use of a Beta testing program, can help minimize the usability issues in a product. Interacting with them, asking them the right questions, and soliciting overall feedback is vital to creating not just a usable product that gets the job done, but a product that makes the customer's life easier - which is what customer satisfaction really is.

What is Quality all about...

2010-02-09T17:52:00.000-08:00

Wrapping up from a fairly long day of working - and attempting to balance home life along with it - I went to the bookmarks I keep in the "Thinking" folder of the browser I most often use. I clicked on metacool... The topic was the "Thought of the Day" and it was just what I needed to hear tonight...

Sometimes, as a tester, I get really "worried" about releases. I wonder how many customers will be "happy" and how many will be "disappointed" in the latest/greatest/newest release. Scenarios play through my head, especially those I could not get to in testing, and most of these can have potentially negative outcomes... But one thing I have neglected to remember... the customer has a voice... and if we (the organization/stakeholders/developers/testers) listen, we can use this to benefit the product and the reputation of the organization...

What do I mean? I not only "serve" customers, I am a customer. And as a customer I am more likely to stay with an organization/product that admits it is fallible and works with me to meet my needs than to stay with one that claims to have it all figured out (or one that has a reputation of meeting the needs of most others).

A couple of posts ago, I talked about A Revelation... I had about customers (because it related to myself, of course), and Markus Gartner commented about not knowing "what to do about it either". But I thought about the "Head of Lettuce" philosophy that I see at the grocery store and I think people/customers will eventually make/take a stand against poor quality/high prices. [The "Head of Lettuce" philosophy that I see is because of what I perceive as a consumer in the produce section every summer. Lettuce becomes very pricey, quality goes down, consumers let it wilt, the price goes back down, the quality back up. I have seen this go on for years (mostly in summer when 'salad' is an entree).]

I mention this scenario only to give credence to the blog post that I read, or rather my thoughts on it. Only three sentences in length... yet it reveals much about the future of software development - to me. The customer drives the market. Perfection in software development is not possible... customer satisfaction is. A customer can be satisfied knowing that they matter. Perfect software is... well... an illusion.

However, when we learn to listen to our customers, and fulfill what they need, we will find success. The problem with quality is not as likely in the product as in the production of it. We cannot get so carried away with the technology as to lose focus of what it it for. It is to help us... to help our customers... to get our jobs done faster/better/more accurately. That is all that anyone really wants. That is satisfaction - getting the task-at-hand done so you can move on to another one that needs attention (and isn't there always another one?).

Let's not forget what it is all about... customer satisfaction... not perfection. That is what quality is all about.

Developing People

2010-01-31T05:44:00.000-08:00

As a single mother in the 21st Century, there is a lot you want to say and do for your children to help them avoid the pitfalls that this world sets up to snare them and make their life more difficult. As any/every parent knows, it is difficult to see the fruit of your conversations and prompts with your children. But every now and again something shines through that makes you see that all you say and do really does have an affect on them. I had one such moment this week with my 17-year-old daughter.

She is a senior in high school and struggles with the system the same way I did when I was in it. The way the English classes are run/taught has been difficult for her since her Freshman year. However, give her something to write about that she feels deeply enough about and you can "see" who she is and what is "in" her.

Today I am going to switch from software development to people development. Today I want to share her essay on "A Satisfying Life".

"A Satisfying Life" by Rebekah Smith
Dissatisfaction comes from ourselves. People constantly blame others for the way they feel when really we are the ones that control our own feelings. If people would realize that they are responsible for their own lives, including their levels of happiness, that would be the first step in being happy. People these days don't want to admit to being the cause of their own problems. It's easy to point fingers at teh people who have hurt you, and you can blame them for your current state of mental crisis. , but in reality, no one else controls you except for you. Brent from the book, "Whirligig" proves my point. He went to that party and was rejected by the one girl he had always wanted, and his friend wasn't being all that friendly either. So he took the car and drove until he spotted another vehicle, and he ends up killing another girl, rather than himself. He blamed his unhappiness on the fact that he was rejected rather than the fact that his mood hadn't been so good earlier in the weeks either.

Another thing that prevents every from being happy is the amount of artificial crap they buy to give them a temporary bout of happiness. That's the thing. People go through life just experiencing bouts of happiness here and there and that's what they live with. They're used to this concept and it's all they know. Yet when those bouts are over, they're unhappy again. So they buy something else. From drugs to new cars; and laptops to houses. None of it gives you a long term good feeling, it all just makes you happy for a minute and then you're back to feeling like junk. Mitch in "Tuesdays with Morrie" was like this. He thought that a beautiful house and a great paying job would make him happy. It didn't. The new shiny car he had didn't make him happy. Things don't make people happy.

Actions can prevent happiness. We do something wrong, we hurt someone else and we end up damaging our own mentality rather than the person we had targeted in the first place.

It makes me feel exceptionally proud to read the words of this essay and the thoughts behind them. And it helps me to understand that developing people... or helping people develop to put it in the correct context... pays dividends not only to the people in the "relationship" but is paid forward in time as well.

This week think about the interactions you have with people. Think about what you would like to invest in with the "relationship". Think about what you would like to see as the dividends. I am willing to bet that you notice some things about yourself as well when you do this.

A Revelation...

2010-01-26T14:26:00.000-08:00

Michael Bolton, as I stated in a previous blog, suggested the book The Inmates Are Running the Asylum to me to read.

Not quite into Chapter 2 and I wish I had read this book a long time ago. Because I use software in my daily work, the following paragraph from the book jumped out at me:

"Most software is used in a business context, so most victims of bad interaction are paid for their suffering. Their job forces them to use software, so they cannot choose not to use it - they can only tolerate it as well as they can. They are forced to submerge their frustration and to ignore the embarrassment they feel when the software makes them feel stupid."

What a simple, yet powerful statement. How many times I have been at my wits-end with the defect and test case management tools I have been "forced" to use. And yet I never really gave much thought to the user/customer base of the products that I test within the same light. I wondered why that is.... and I think I gained some insight into it.

The software I test is delivered to me along with conversations with developers, product managers, documentation, flow charts, etc. I understand the "expected" behavior. I understand what the software is "supposed" to be doing. But the huge missing peice is that I hardly know the customer/end user. And that missing peice is huge because that customer/end user is the one that is "forced" to use it to do their job. What a revelation....

Which part is the revelation? Understanding that I am a customer, paid/forced to use some software products/applications that make me feel either "stupid" or "frustrated". How can I use this "revelation" in testing? While it is unlikely for me to get to know the actual end users/customers, I can advocate for simplicity in UI, performance issues to be resolved, and spend a bit more time researching the way that the users interact withthe software/application/product.

Some of this I already cover: I read forums that users of the application/product/software I test - and similar/competitive applications - communicate in. I check out reviews that are available to compare the product/application/software I test with other comparable ones. But the customer voice may still be missing in this. We - most of humanity in the 21st Century - have grown accustomed to using software, even less-than-worthy/frustrating software, just because it does part of our job for us, just because we have become dependant upon it. We are, quite frankly, so used to bugs that we tolerate and expect them.

Can software actually be user-friendly? Something to think about while testing and while navigating through the world of software we live in each day....

ET and the Bug Bash

2010-01-19T19:29:00.000-08:00

Michael Bolton suggested, via a comment on my last blog, that I might like the book The Inmates are Running the Asylum by Alan Cooper. (At first I thought he had visited my team without me knowing - ha ha.)

I ordered the book using a gift certificate from Amazon.com that I won as a prize from a "Bug Bash" at work. This "Bug Bash" consisted of some rules. I broke just about every one of the rules...

I thought I pulled myself out of the contest by doing this... and that didn't bother me because I was interested in a couple of other things. I wanted to see the bugs that were submitted by my colleagues - especially those who generally don't do exploratory testing, and I wanted to see if my instict of focusing on something else was viable - I guess I was testing my mind.

Both of these things had interesting outcomes. Those who generally did use exploratory testing skills excelled as always. Those who did not, or were newer to the field, did not. This brought to mind a few questions and added fuel to the fire of my belief that ET IS a skill. (If I hear one more person say "monkey's banging on a keyboard"... ) Wouldn't it be interesting to interview a tester who was new to the experience of exploratory testing and ask them just a few questions? I have met a couple testers along the way who just could not wrap their brain around the concept. They wanted... no - needed... to be pointed in the right direction.

When I was lead of a certain project, and a certain tester was made available to help me, I found the best way to help this tester to utilize exploratory testing skills was through Session-Based Test Management. I would lay out the features and the times the tester was to spend on them. An example: Feature A - 45 minutes. At that point, the tester was instructed to stop testing it and move on to the next feature. This worked wonders for the tester, which added value to the service for the project.

This particular tester had trouble with a few things. He/she would feel a lack of confidence when given an exploratory testing assignment. "I can't find things like so-and-so, I look at the application/product/system and my mind goes blank." When given a set of instructions, sometimes the "blank" mind becomes preoccupied with the task and forgets it may not "find things like so-and-so". Some people are task oriented. Tell them what to do and they can do it. That does not mean they don't have some level of skill, it just means it is tapped into differently. The other issue this tester faced was related to time. Thinking about doing a single task for the entire day can be daunting - even if it is something you love to do. Breaking the time into sessions is a great alternative for people geared this way. It alleviates a lot of the percieved boredom and stress.

Exploratory testing, in my opinion, is a skill. It can be learned, and it can be built upon. It is a matter of training, whether of yourself or others. Even if you have natural capabilities, in software testing you need to continue to build upon your skills as the technology changes - train yourself to keep up.

As for the second thing I wanted to see... If my instinct was correct... this time it was... oh Happy Day :)

User Characters...

2010-01-12T02:36:00.000-08:00

User Stories are generally about an average user. When a Product Owner writes the stories he/she is considering what they believe the user would like to have the application do. This makes perfect sense until development has implemented the feature.

As a tester, it is my job to create some Users and see what happens to the story. If the User Story says, "As a user, I would like to add a sheet to the document I am working on, so that I can continue to add information to my report". It is important to have an understanding of who the user is and what an average sized document consists of - how many sheets specifically in this case.

Once the application passes the tests for the average user it is time to then test it according to the non typical user (time to have fun). A User Story typically won't mention things like:

"As a User I would like to add 200 sheets to my document and still have the application respond so that I can complete my task and continue to use my PC."

"As a User I would like to add sheets to multiple documents when I am working on them, having multiple instances of the application open, and not have all my CPU tied up, so that I can finish up before the big game."

"As a User I would like to add sheets to my document quickly so that I can get the document to the Post Office before it closes."

Depending upon what the User Story is suggesting the User wants, there are lots of other "Users" that the tester has to think about and test for. Characters can be thought of as the Story unfolds to the tester. What types of User Characters can be invented to use the application while testing? The typical User, the multi-tasking User -who has several applications running at once on their machine along with the one you are testing, the Forgetful User - who cannot remember to shut down the application, the Random User - who starts and stops and changes their mind while using the application, etc.

When testing User Stories, I find that creating User Characters, or thinking about the different types of Users that could be running the application/product enables me to feel more confident in what was tested/how it was tested before the items move to "Done" - even though it is highly likely that I will not cover them all, a random sampling of extremes can cover a lot more ground.

Balance...

2010-01-11T19:11:00.000-08:00

I am always on a course of seeking balance in my life, and it often seemed to elude me... Until I realized that seeking balance is really the biggest part of achieving balance. Since I came upon this realization I feel a lot less "guilty" for not having achieved it to the degree my nature desires to have it (type A), and a lot happier with myself for having the desire/need/aspiration to find it, and the drive to do what is necessary to find it.

In the course of the last few months I have found peices of myself that I had left to sit in the corner of the room while I was looking to achieve certain goals I had. While some of these goals were forthcoming, they lacked something that I could not put my finger on. Turns out the peices of myself that were in the corner of the
room was what was lacking. And I discovered some wonderful things in those peices.

I have placed a large emphasis on my career and my children in the last five years - being a single mom will do this to you. In focusing so much on these two things, some aspects of my life became cob-webbed over. Astrologically, I am a Libra, the scales are the sign, yet I could not seem to get the balance inspired by this - I began to think about it - alot. I began to think about what I wanted, where I wanted to be in a few years - my personal goals, and I decided to take some time off.

I did not take the time off from work or from being a mom, that would be impossible, but I took the time off from being a driven individual with a single sight on the two things. I began to take care of some "me" things. I found I can still laugh at myself, still play, still explore the things that inspire me, and still dream like I did when I was five - with the inspiration to believe that I can have what I dream
about.

In the last couple of months I have built snow forts and back yard ice skating rinks, gone fishing, written poetry, took life a lot less seriously, and began to write what I hope will be my become my first fiction novel, took up cooking again - used to actually enter contests and sometimes win, among other things. These are things I either always wanted to do, forgot how to do, or never even thought of doing. I guess I took time off to "test" myself. To gather information for the "person that matters" in order for her to make some decisions and create some life goals. I am pleased with the results and look forward to the rewards that I will find in continuing to seek the "balance" of my life.

One of the biggest trials - with great rewards - has been the transition I have had in the project I am working on currently. I have been transitioning from a multi-project team to a single-project team.

This has brought about a lot of challenges that I am sure will stretch and grow me. It has been a lot like a young bird leaving the nest and learning to fly on their own.

The project, as a tester, is a once-in-a-lifetime challenge. Testing from the ground up on an agile team that has been put together by the powers that be in expectation of having a "dream team". (No pressure there...)

I have been learning what it means to value "individuals and interactions over processes and tools" - this was the one concept of agile development that was fuzzy in my mind prior to this project, but has begun to develop into an understanding.

Not much of a people-person by nature, I have begun to understand the value of working as a team for a common goal - because that is really the only way to achieve it, and the only road to success.

While this blog was mostly on personal discovery, isn't that what really drives the tester? Without personal discovery there can be no more questions....

Paperwork Implies Something... it does not Do Something

2009-11-02T01:47:00.000-08:00

Okay, so now I had a certificate up on my wall... Did that make me a good tester?

Have you ever met someone who went to school to become, let's say, a teacher? If this person has all the paperwork to prove they can be a teacher, does this mean they are a teacher? Anyone who has spent any time in school has met someone who should not be at the head of the classroom. At the same time, surely most have met someone who had no paperwork, no college education whatsoever, and has taught them a lot. Paperwork implies something, it does not do something.... and when tested under fire, it is useless.

Not long after becoming certified, I was exposed to two of the best training courses available for software testers...

In our weekly team meeting, it was announced that the organization I work for was going to be providing us with a 3 day Rapid Software Testing course with Michael Bolton. I was excited to have an opportunity to learn more about testing.

This course helped me to take ownership of my testing. The use of heuristics and oracles was something I had never taken into consideration. It is not that I had not used them - everyone uses them to some degree , but I didn't know how to use them smartly.

The course also gave me confidence in testing. Not only did I believe that I could test any application/product set before me, but I went on to do so with success, on each of the projects within the facility I work for. In short, the tools provided by this course have enabled me to organize my mind in my testing.

I knew some time after this course that I needed to test myself. I knew I was good at what I was doing, but I was unsure if what I was doing was good. At this point I signed up for the Association for Software Testing's BBST Foundations course. This course was great. There were all levels of testers in the same "class". The points of view brought in were amazing and the main project allowed me to gain some experience in working on a geographically dispersed team. This ended up helping me quite a bit when I was actually involved in a four-location project.

This was an intense, fast-moving course that provided me with an opportunity to learn from not only the course materials, but other testers from all over the world. It not only added to my testing knowledge, but to my communication skills as well.

I would highly recommend both of these courses to all testers regardless of time and experience they have in the field.

Taking the Test... Twice

2009-10-16T01:37:00.000-07:00

The test that was specially created for those of us who were applying for the permanent QA position included multiple choice, essay, and lateral thinking questions. The multiple choice and essay questions were taken from the ISTQB syllabus.

I have never had much difficulty in taking tests that involve memorization. I have been able to simply read through the study materials a few times, take a test, and pass. This information is generally only placed in a temp file in my brain. It does not actually commit to memory unless I need or want to keep the information. So I began to read through the materials each day until the day of the test.

I passed the test and was offered the job. I accepted with a literal shout of joy!

There had been talk about certification in some of the QA meetings that I had been in prior to taking this test. Because the test was based on the ISTQB syllabus, and because the ASTQB was going to be in Boston in a few weeks (about 400 miles from where I live), I decided to take a trip and take the certification test.

As luck/fate would have it, my brother in law was a pilot for an airline that flew out of the local airport and he was able to get me a ticket that only cost me a little - round trip. And my baby brother, Josh, lives in the Boston area. Being a single income family, it took a bit of sacrifice from all of us to scrape together the necessary costs associated with taking the certification test, but we did it.

Long story short... I took and passed the test. I was proud of myself for making the trip and for challenging myself to go a step further than I had to. I put no stock in the certification even at that time because to me it was just memorization of terminology. However, the challenges to get there, and the impact it had at my job, was well worth it.

A couple of months from the date I took the test in Boston, I would be exposed to something that would empower me to embrace the way I think, sharpen my understanding, and give me a great set of tools that can be used both inside and outside testing...

Exposure to Outside Influences...

2009-10-13T02:58:00.000-07:00

My first exposure to information on software testing from outside the office came in the form of a couple of the web site links the QA Manager shared with us temps.

The first was the Center for Software Testing Education & Research. The second was StickyMinds.com. Both of these web sites were, and continue to be, great resources for learning.

The first book that I borrowed from the QA Library was Testing Computer Software (Kaner, Falk, and Nguyen). I read the book cover to cover and now own a copy of it myself and use it for research and as a resource in my testing activities.

So much of what I was reading, learning, and doing caused me to come to the realization that this was the job for me. Certain personality traits that I had been told, from significant people in my life, were negative, turned out perfectly posititive for testing. I felt at home with this job.

The trouble with feeling this way about my job was that it was only a temporary position. There was a scheduled end-time and the QA Manager made sure we all knew that. One by one I watched the other temps leave. Whether it was finding another full-time, permanent job or because they did not like testing, only two of us remained to the end of the temp time.

A couple of days before I was supposed to get done, the Manager came into my office and told me that my time had been extended by a couple of weeks. I was quite happy with that. I had decided not to panic at the end and start looking for another job in the area. I had decided to continue to learn and keep the worries at bay while I did so. I had made a decision that, even if I were only hired on as a temp, I was going to continue to do my job as if it were permanent. I had decided that this was a career I wanted to pursue. I had been bitten by the software testing "bug".

It was not long after this that I was told a permanent position was going to be made available. There were other candidates within the organization who would be applying for the job as well. We would have to take a test as part of the application process...

Ahhhh.... the Questions....

2009-10-12T13:54:00.000-07:00

My previous blog entry ends where I begin to ask questions about what I am doing, what the product/application is doing, and everything in between :)

The senior members of the QA team that I was hired on as a temp to help, were very helpful and patient in answering or finding answers to any and all questions that I asked.

Not long into running test cases, I began to submit bug reports. Being a "newbie" to the whole software testing field, these reports were generally missing something. Fortunately the development staff where I was hired was again, like the QA department, very patient and helpful. If they thought there really might be a bug, they would come over to the temp office and work with me to find the information that was lacking in the bug report. They would also give me further information about the product/application and the whole "system" in order to provide me with more information to use in testing and submitting bug reports.

A lot of the required reading materials spoke about the friction between development and testing. I did not understand this while I was reading. Wasn't the goal supposed to be to get a product/application/system out to the customer in the best shape it could be in? Wouldn't we all be working for that same goal?

Turns out I was lucky to be hired on to an organization that really believed that. If there was any friction between QA and Development, I did not see it.

It was at this point that I wanted to learn more....

In the Beginning...

2009-10-10T18:46:00.000-07:00

My life had dramatically changed and I needed to find a new job. I filled out an online application for a temporary QA position in the city next to the town I lived in. I had no idea what Quality Assurance was, but I had some of the qualifications they were looking for. To my surprise, I was called to be scheduled for an interview.

In the reception area, I was greeted by the QA Manager. He was dressed in jeans, Hawaiian shirt, and sandals - this weirded me out, but was a bit humorous as well. I followed him down a long hallway to his office, where he proceeded to sit down and put his feet up on the desk filing cabinet.

The interview was unlike any I had ever had. It seemed to have nothing to do with work at all. When the interview was complete, he had to ask me if I wanted to know what the job was. I had enjoyed the interview process and the odd questioning so much, it never occurred to me to ask :) The one thing that stuck out above all else was that the man was all about his team. He was as proud of them as a father is of his children. This made me want the job more than anything. Like an awkward teenager wanting to not be picked last for a sports team in gym, is how I felt when I left.

I got a call a couple of days later. My children were in the room with me when I received the phone call. They waited with patience as I spoke with the QA Manager on the phone. When I got off the phone, I let out a rigorous "Yes!" and slid on my knees across the linoleum on the kitchen floor. (All the children left the room, not sure why.) I was picked for the team... of what, I did not know, but I was picked. (Thanks Bob!)

The first three days at the job, me and the other temps hired on, spent reading software testing materials. I have always loved to read, so this was no big deal to me. What was a big deal to me is that I thought... "this job surely requires a college degree". In spite of the fact that I did not instantly understand the information, I decided to continue to read anyway and hope that this, as most of things I learned in my life, would be comprehensible when put into action.

After the reading days, we were set to task running scripted test cases for a product. The information that I had been reading was still floating like fractals above my head, but the test cases that we ran were written understandably enough for me to understand what I was doing in the program/application that I was exposed to. (Notice I did not say that I was testing it.) Here is where I began to ask questions...

Tester Types...

2009-10-08T15:36:00.000-07:00

Rob Lambert has done a great job of asking What tester are you? on his blog. What makes me think this is great, you ask? Or maybe you don't....

I am a firm believer in personal growth and personal accountability/responsibility. These blog posts are a great way to take personal inventory of a few things:

1. Who am I as a tester?
2. Can I quantify what I do?
3. Do I behave in a civil manner?
4. What can I do better?

I personally sent these "tester types" to the members of my organizations test team. Knowing human nature is to "type" other testers, each time I was approached with "so and so fits this type" I said, "this is for you to find your type.

While these "tester types" may not be scientifically proven, or even viable in all cases, we should all take some time to think about who we are as a tester, a team member, and a person from these definitions. Or at least ask ourselves "What type of tester am I" and find a way to improve.

Thanks Rob!

A Compact Fluorescent Lightbulb Moment...

2009-09-29T02:33:00.000-07:00

Two testers on two different projects. Both working for the same organization. Both on an email thread describing processes/practices currently being used or intended on being implemented in the future - across the board - as best practices. For one of these future goals, tester A says it would be a good idea to implement it. Tester B says no thank you.

I was tester B. Later on, I was asked personally why I said no. I explained why, based on my project and my team. But I felt like I was missing something in my "arguement" and I felt like more explanation was necessary though I could not verbalize what that was. Days passed and I could not stop thinking about the missing peice. I could have argued about "best practices", but that did not seem to be the right route to take. I had to take some time to think this out, and time is a precious commodity when releases are pending and you have to balance those late days with your home life.

I kept talking to myself (I tend to do that alot :)) about the different projects in my organization. About how project A differs from B in some aspects, and project C is in a league of its own. The differences in the projects range from code language, release cycles, size of product/application, and how test leads manage what/how it is tested, etc. When you have multiple projects in test, it seems to be a valid point to attempt to take what works on one project and apply it to the others in an effort to have "best practices", so continuing to talk about the differences might only illicit that same feedback... so I continued to think about it.

I don't believe in adding processes or tasks to a testing project that do not benefit the success of the project. I need suggestions to be validated, even if it is in an abstract form initially, in order to see the value of doing something. I do not believe in wasting time because time is limited, testing takes time, and testing costs the organization money - it does not make money - so it should spend both wisely. Because I feel this way I think not only about whether or not a practice is best, but whether or not it is time/cost effective.

It was at this point that I remembered something. A compact fluorescent lightbulb went on just over my head... The Seven Basic Principles of the Context-Driven School. While I had read this before and read several debates over it, I had not realized the importance of what it was saying. This was my missing peice. Co-authored by Cem Kaner and James Bach, this is a very well thought out and written explanation of my sub-conscious reasons for not wanting to see processes/practices implemented across the board whether or not they benefit the individual projects (or taking that down to the root - whether or not they benefit my project).

Today I will share this explanation, along with my new found understanding of it, with those who asked me personally why I said "no". At the very least it will give us all something to think about and talk about.

Autonomy, Mastery, Purpose... Motivation

2009-09-17T03:25:00.000-07:00

Money only motivates for a limited time. Have you ever held a job, where the only purpose you held it was to earn money? How motivated were you to excel in what you do? How much time did you devote to the job outside of the organization? How did this make you feel?

I watched an interesting video on TED from Daniel Pink about the the surprising science of motivation. Now, because he admits to being a lawyer, I don't take everything he says to be fact ;), but the underlying theme resonates with how I feel about motivation. There is more to it than money. Even people who are motivated to gain money are usually doing so for some other thing, not the money itself.

Up here in Aroostook County, Maine, where I live, teenagers sometimes participate in the annual Potato Harvest. This is a long held tradition, but a difficult job. It offers long days of physical labor, taking rocks and other debris out of the conveyor belt that is loading the dug up potatoes onto the truck that runs along side the harvester. It can be at or below freezing in the morning and hot in the afternoon. This is what fall is like up here. You go home covered in dirt/mud. You are exausted, and the morning comes early the next day. The motivation for completing a harvest job may appear to be the money, but if you look at it a little more closely, it is the goal of the money that is the motivation.

The speaker lists of three things that could be the reasons we are motivated: autonomy, mastery, and purpose. These motivators ring true with me, but I would add a couple more: passion and self-gratification being two of them. By our very nature, we like to feel good about what we are doing, it has to give us some sort of gratification in order for us to excel at it. Even those who live to serve others continue to do so for some sort of gratification.

It is easy to be motivated when you are on a project that is exciting or new. Sometimes the tasks or projects that we have to do are alot less meaningful. During these times, when doing the mundane or less than exciting tasks associated with my testing or my life, I find that I have to purposely motivate myself. I do this by looking at the big picture instead of at the task itself.

Anyone who has had a child or a puppy can understand the big picture mentality. My German Shepherd, Henry, is still a puppy. He is only 8-months old at this time. There were times during the last four months when only looking at the big picture motivated me to continue training him up to be a part of my family :)

I question just about everything, whether aloud or in my head. When I come to a point where I feel less than motivated, I ask myself why. Then I look at the big picture. If the lack of motivation cannot even be rectified in the big picture, I look for an alternative. Because of my passions and my admitted need for self-gratification in what I do, I agree with the speaker in this video... what drives my motivation is autonomy, mastery, and purpose.

A Lesson Worth Learning

2009-09-05T02:56:00.000-07:00

One of the projects that I am currently involved in is being developed using agile/scrum methodologies. The product/application/system has no previous/historical test documentation. This is a huge opportunity for learning. While I have done quite a bit of reading on situations similar to this, nothing really compares to being involved in one.

How easy it is to forget things, usually by way of assumption, has been one of the first lessons that our team has been learning. A generic example of this:

Feature A is being implemented in this sprint based on a User Story.
The whole team worked together to break it down into tasks/SBI's during the Planning meeting.
Unit tests were created during the development of the feature.
The feature was implemented according to the User Story.
The tasks/SBI's were completed.
The Unit Tests passed.
But...

The User Story assumed that certain limitations would be in place by default. There were missing requirements that were not considered during the implementation of the feature. According to the Conditions of Acceptance on the User Story, the feature is done, but outside of the task board, it is not.

We have faced this challenge a few times. Fortunately, our team communicates efficiently/effectively. When these challenges have come up during a sprint, they have been discussed and dealt with according to the potential impact on the project. It could be that a new PBI has to be composed, a bug is written (either to be fixed within the sprint or deferred), and sometimes technical debt is incurred.

This challenge of remembering not to assume has had a positive impact on each of us as individuals and as a team. Individually, I remembered the
Rapid Software Testing course that Michael Bolton delivered to our team a couple years ago. Specifically, I remember the lessons on inattentional
blindness. I have decided to go back through the materials from the RST course to refresh myself and to pass on relevant information to the others on my team. You don't have to be a software tester to benefit from this course.

As a team, the impact of this challenge has helped us to communicate stronger, rely upon each other, and it has kept egos at bay. We realize that not any one of us can come close to remembering what all of us together can. And while on the surface, this challenge can appear to be of a negative nature, it has produced positive change - and that makes the whole lesson worth learning.

Don't Settle for Mediocrity

2009-08-09T05:42:00.000-07:00

It was a long and busy day at work. I had several things that had to be done at home before retiring for the day. My five year-old needed a bath and the lawn needed mowing. I asked my sixteen-year-old to put the little one in the bath while I mowed the lawn. She agreed to do so. Mowing the lawn takes about an hour and a half.

When I came back in, I noticed my five-year-old's hair was not washed. I inquired of the older one why this was so. Her response, "you did not ask me to wash her hair." Seriously... seriously?! We had a conversation about implied requirements. I found the whole thing funny, only because I know that the teenage brain does not engage quite as it should, but I also found I was taught a lesson in mediocrity.

Doing only that which is asked/required, in my opinion, is mediocrity.

In my years of working, whether as a tester or not, I have had to work with people who simply do what they are asked/required to do. They do not go beyond the call of duty. I have often found great difficulty in working with people who exhibit this type of behavior. It is easier for me to work with people who openly admit to not "give a damn" then it is for me to work with people who approach a job with mediocrity. How can you argue with someone who actually does what you asked them to do? How can you argue with someone who meets the requirements you laid out?

Here is an extreme example of mediocre performance:

A person gets hired at a restaurant to work in the kitchen on the night shift. He/she is told to do the dishes. The supervisor comes into the kitchen in the morning and sees pots/pans/silverware/glasses/coffee cups all over the counter. A meeting transpires between the new hire and the supervisor.

"You were told to do the dishes last night," says the Supervisor.
"I did the dishes," says the New Hire.
"When I walked into the kitchen this morning there were dishes all over the place," says the Supervisor.
"This is highly unlikely, as I know for a fact that I did all the dishes last night," says the New Hire.
They walk into the kitchen together to see/determine what was going on.
"See, this is what I came in to see this morning," says the Supervisor.
"Yes, this is the way I left the kitchen last night. What is the problem, I met the requirements, I did what I was asked to do," says the New Hire.
"How can you say you 'met the requirements' when all these pots/pans/silverware/glasses/coffee cups are all over the counters?" inquired the
Supervisor in a bit of a surprised tone.
"These are NOT dishes," said the New Hire.

Can the supervisor argue with that? Did the New Hire do what was required? Some organizations would say "yes", but these are not the organizations that excel/succeed/profit. Some organizations would begin to kill trees by creating a procedure/policy for each job. Maybe the kitchen job would have a list of things for the New Hire to do when asked to do the dishes. Some organizations would say "no" and begin to address the issue with the employee. This is Employer/Employee responsibility. This is what is necessary to maintain the health/success of a business.

I stumbled upon a really good article on Motivating the Mediocre, which is from the health care industry. While this article might not be directly related to software testing, but it really addresses the issue of employees who exhibit mediocre performance and the possible ramifications this has on the business.

The article defines two possible problems: "Is it a matter of ability or a matter of willingness?" Some people simply do not know what is required/expected of them or when to step outside the defined task. Some are afraid to venture past the boundaries that they percieve are set. Some people simply do not want to do anything more than what is required of them. Figuring this out requires communication and patience. It also requires a willingness to do something about the problem once it is known/defined.

Are you striving to go outside the box? Once you know what you are required to do, do you ask "what is/are the missing/implied requirement(s)"? Do you approach your job as a service to the stakeholders? Or do you feel your job is a paycheck?

If you want to succeed, you have to be willing to go the extra mile. Do not settle for mediocrity in yourself or in those you work with. Go beyond the requirements, try to understand the needs of those you work with. Communicate with those you feel might be putting forth mediocre performance. This is the beginning of success on a personal level, a team level, and an organizational level.

PERSONAL Goals

2009-07-28T17:53:00.000-07:00

It is goal setting time again at the company I work for.... Every year we come up with goals that we set out to achieve for the coming year. We generally use the SMART goals criteria:

Specific
Measureable
Attainable
Realistic
Timely

Over the past two years of using the SMART criteria, I have found it to be considerably lacking for me. The goals that have been laid out have become more about the goal itself than the person trying to accomplish it.

Since the goals actually make up a part of the annual review process, it seemed vital to have the goals created and completed. A lot of my own goals seemed to be geared toward specific projects and ended up being left wanting in the end. There were several reasons behind this unavoidable reality for me. One main reason was the changing of projects for me. I changed projects prior to completion of a couple of the specific goals that I had laid out for the year.

After giving much thought to the whole business of setting goals, I realized the main reason I was having difficulty in completing the ones that I set was because they were not personal. If I am to put effort and desire into completing a goal, it ought to be something that affects me personally. I realize I ought to be setting goals that will directly affect my personal beliefs, desires, and career path. The goals I set should not be project-specific, but person-specific. The person that is affected by the outcome should be me, not my boss, his/her boss, or the company. If I set goals that I want to achieve, then I believe the value will be felt even by the others that I work with. The value will impact my team-mates, my boss, and my company if I am striving to better myself.

Having thought about this for a couple of weeks now, I have come up with a really quick acronym for how I am going to build my goals for the coming year...

Progressive - favoring or advocating progress, change, improvement, or reform, as opposed to wishing to maintain things as they are. Does this goal mean to change or improve what I am already doing? Will it add to the value of what I am doing?

Expressive - meaningful. - Is this goal meaningful to me? Or is it just a way to meet the company desire for me to have goals?

Relational - of or pertaining to relations. Is this goal in relation to what I am currently working on or what I am aspiring to become?

Satisfactory - giving or affording satisfaction. Will this goal give me satisfaction? If the goal will only satisfy an objective and not my personal desires for growth, it will not be worthwhile, nor will I give it my best effort.

Ownership - the state or fact of being an owner. Can I take ownership of this goal? Is it worth my investment?

Noteworthy - worthy of notice or attention. Is this goal worthy of my attention? Or will it sit on a back shelf and be done only to meet the company demands?

Agreeable - to one's liking; pleasing. Is this goal to my liking? Does it in any way please me to accomplish it?

Leverage - the use of a small initial investment, credit, or borrowed funds to gain a very high return in relation to one's investment. Does this goal give me a high return in exchange for my time/money/investment?

While these are just my initial thoughts on it, the acronym is mine to keep. When I set my goals for this coming year they will not just be SMART, but they will be PERSONAL. This is the only way I believe I will be able to not only achieve them, but benefit from them.

**All definitions have been taken from Dictionary.com.

Practice that Inspires

2009-07-12T06:26:00.000-07:00

One of the teams that I am currently working with is using agile practices. First of all, let me put out my definition of this. The word practice, as I view it more often than not, is "repeated performance or systematic exercise for the purpose of acquiring skill or proficiency" (Dictionary.com). So, regardless of the definition of agile being used, and regardless of the connotations this word has... the key, to me, is practice.

One of the first things that I took notice of was the conditions of the team. A couple of us had worked together, but most had not. Because of this, the condition of the team was that of a new team. A new team generally goes through the Forming-Storming-Norming-Performing model. However there seems to be a big difference in the way these stages of the model are approached when each of the team members is geared more towards the overall success of the project and not in a competitive mode.

One obvious thing that makes a team have an easier time to get to the Performing stage is communication. A noticable benefit of working with a team that is using agile practices is the amount of communication that takes place. This can often start out a bit awkward for the team, who may not be used to talking about what they are doing, but as the practice continues, the communication becomes more open and beneficial to the team and the project.

Another benefit of being on this type of team is that there are no real defined practices. We have the added advantage of creating our own way - and changing it when/if it needs to change. It is freedom with responsibility. Allowing the team to be individually creative while the whole group keeps each other on task toward the goal.

The word practice can incite a lot of different feelings depending upon the context that it is used in. I personally like the word because it inspires me to continue to learn and grow, while allowing me the freedom to try things out and see if they fit - which grants me permission to fail on occassion. While this is not what I hope/expect the outcome to be, it is necessary to be permitted to have some failures along the road to success, otherwise nothing would ever improve personally or professionally.

One pretty good example of the inspiration of the word practice that I find helpful is when it is used in conjunction with medicine. Doctors are referred to as Practicing Medicine. Their offices are referred to as Practices. Now, while this would not sound good to the ears of a person in need of diagnosis/repair/surgery/etc; without the continual practice of medicine we would not have the life expectancy that we have as humans... not to mention how horrible it would be to go and visit a doctor.

To me, while we often seek to have best overall practices, it is more important to remember to aim for the definition of acquiring skills and proficiency in what we are doing at this time and on this project, taking into account that the same skills and proficiency may not be of benefit on the next project, challenging us to grow our skills.

Continued Success... Requirements

2009-07-09T15:20:00.000-07:00

I first heard of Richard St. John by Simon Godfrey when he posted a comment on one of my earlier blog posts. I have since decided to continue to explore the world of TED myself, since this is where the link was originally posted.

It was during this morning's visit to the web site that I found another podcast from Richard entitled Success is a Continuous Journey. A 3 minute 58 second talk about how it is vital to continue to have:

Passion
Work
Focus
Push
Ideas
Improve
Serve
Persist

The 8 Secrets of Success need not end when we reach a level where we feel comfortable. There should never be a level we reach where we feel this apathy toward growth. The same is true in every endeavor in our lives.

For example, I like to garden. I like to plant life in the soil and watch it grow. However if I feel that I have done enough, do not check water or weeds, what will happen to my garden? Will the healthy plants be choked out by the weeds? Will the plants die for lack of water?

How about relationships? Do they not need tending the same way? What happens when the passion fails here? Or when the desire to meet any of the "8 Secrets to Success" burns out? Does the relationship survive?

The same is true for a career in software testing. The "other half" of the relationship continues to need the "8 Secrets" in order to continue to prosper. It is very important to keep these close to heart in all aspects of life... for balance, for health, for success.

Walk through testing....

2009-06-23T17:19:00.000-07:00

Do you walk? What is the purpose of your walk?

Excersizing?
Getting from point A to point B?
Stretching out between test sessions?
Getting to that extra peice of pie before someone else does?

I walk for several reasons every day. In the early morning, I walk my dog. This walk has two purposes. 1. To train my 5 month old German Shepherd to walk correctly on a leash. 2. To excersize.

I walk to and fro in the house in order to get things in order and prepare for the day.

I walk to and from my car in order to get to work, or to run errands.

I walk to and from different offices in order to get information when necessary, or to go to meetings when they are scheduled.

I walk in the back trails to see what latest wild flowers are in bloom, and maybe to cut a few for an at home display.

The purpose of my walk/journey is what determines the pace that I walk. It determines the energy that I expel. The plan and the purpose determines the journey.

The same is true for testing. What is the purpose of my testing? What has changed in the product/application/system? What is the timeline allowance for my testing? What are the stakeholder expectations?

Just like you determine how fast and how far you intend on walking, using the purpose of your walk as a guide, so also you determine your testing strategy.... And, yes, there is always that unexpected car-breakdown that causes you to have to push it all into overdrive for a little while, but doesn't that add color to the whole story of your life? What fun would be missed out on if there were no "stories" to tell :)

"Adaptive Toolbox" for Testing

2009-06-21T04:44:00.000-07:00

During a recent look into decision making processes, I came in contact with what is referred to as bounded rationality. This study led me to find the book "Bounded Rationality: The Adaptive Toolbox".

The book is put together with papers submitted by several contributors. The fascinating thing about the papers is how much they line up with decisions that software testers make every day on the job.

The "adaptive toolbox" of bounded rationality "provides heuristics, and these are composed of building blocks. I describe three functions these building blocks have: they give a search direction, stop search, and make a decision." Sound familiar?

How am I going to test this application/product/system?
When do I stop testing?
Are we 'done'?

One of the focus points of the concept of bounded rationality is the use of a simple heuristic versus attempts to optimize (optimization is impossible in testing... and just about everything else).

"First, contrary to conventional wisdom, limitations of knowledge and computational capability need not be a disadvantage. The heuristic tools of humans, animals, and institutions can be simple, but nevertheless effective in a given environment.... Simplicity, by contrast, can enable fast, frugal, and accurate decisions."

I find this book is well worth having on hand for thinking about my own "Adaptive Toolbox" for Testing.

How do you respond to Change?

2009-06-16T03:57:00.000-07:00

"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." (Author Unknown)

Matt Heusser's latest blog entry The Boutique Tester points out some very interesting possibilities for the future of software testing.

Rosie Sherry over at the Software Testing Club has started a Flash Mob Testing group.

James Bach's latest blog entry is about remote testers.

Response to change is a common thread between these three test leaders. Let me further explain.

The recent economic changes have forced businesses and customers alike to begin to quantify every dime they spend, while the demand for value has not decreased. Technology has evolved to where Virtual teams are more and more common, and this same technology continues to evolve.

Change is a constant fact of life. Everything from age to weather proves this to be the case... visibly. How we face changes determines how we progress and where we end up. We do not have to give all the power of change over to someone else. If we don't look towards the future and define our role, someone else will determine it for us. Personally, I prefer the freedom to creatively define my role, based on the knowledge of my own strengths and weaknesses in order to give the best value I can to the stakeholders.

Software testers are always in the midst of changes, this challenge is one reason I love testing, it eliminates the possibility of boredom. Testing is not a nine to five job, it is an adventure. It requires constant forward thinking. My personal favorite statement from the Agile Manifesto is "Responding to change over following a plan". It goes beyond software development and is a life lesson.

I challenge you to think about the word "Change" today. How do you feel when you hear the word? What do you think about? How do you respond to it?

I challenge you to read the blogs linked here and think about the ideas expressed in them. What do you think about the future of software testing? Have you begun to define your role for the future? Or will you wait for someone else to do so?

Certifiable Testers....

2009-06-04T18:09:00.001-07:00

How do you know you are a certifiable tester?

Ha ha ha... you think I am talking about certification, that is why you clicked on the link to this blog to begin with. Think again. In fact, just think while I tell you a story...

A few months ago I was asked if I would like to join a new team. Because of the normal business protocols of not saying anything at all about it, I will not be able to divulge any of the facts, but I will tell you one thing.... After a few "OMG's" and nearly jumping out of my seat to hug my manager (not a good idea), I cried and said, "now I know what Miss America feels like when she gets the crown!"

To me, the biggest thing that a tester can bring to the table and offer the stakeholders of any project she... or he... is on, is passion. Passion to test, passion to learn, passion to communicate, passion to see a project through to success. Without this passion, there is not much to offer.

The general public would find this response to be a bit much. After all, isn't a job a job? Aren't we just trying to earn a living and get by? Working for the weekend? Writing test cases, demanding we be heard?

I think not. Wherever your passion lies, there is where you should be. Are you hoping to be a programmer? A manager? A better tester? Don't wait for opportunities to become better, make those opportunities happen. After the 40 +/- work week is over study your desire, learn it, make it your own. Passion for something is not just a desire, it is a habit. A habitual need to become what you feel you want to be, or to find your own niche in the place where you are.

Dictionary.com has the word "certifiable" defined in the number 4 reference as "uncontrollable". Do you have an "uncontrollable" desire to be your best? If so, then you are passionate about what you do. If so, you are a certifiable tester.... Kudos to you!

Question Everything.... On Purpose

2009-05-28T18:30:00.000-07:00

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 ;-)

Consider the Ordinary

2009-05-25T02:50:00.000-07:00

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.

The Why and How - Guidelines I Use

2009-05-21T02:26:00.000-07:00

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.

Juggling...

2009-05-16T16:17:00.000-07:00

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)

Assembly Required

2009-05-11T01:45:00.000-07:00

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…

Seeing Beyond the Mission

2009-05-03T08:17:00.000-07:00

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…

Testers Rock!

2009-04-23T02:46:00.000-07:00

Software testing adds more value than it is often given credit for. When I think about the tools that I use on a daily basis I can see that testing actually helps to drive the economy. Hardware and software vendors receive value from testers who are not even responsible for testing their products. Part economic stimulus….

Testers also help to drive education. How many books have been written and who receives value from this. Publishers, vendors, and people, perhaps mostly other testers, receive benefits from this. We also have a tendency to drive education in other ways that may not be so evident. What and how we teach our children seems to be a bit different than what is generally expected. Our kids generally ask questions and do not accept the status quo. This adds value to the classrooms they occupy if they go to a public school. Most of us self-educate and help train other testers. Part teacher….

Some testers have developed philosophical stances and ideas that have gone past the boundaries of applying only to testing. Most hold some philosophy that includes systems thinking and realize how one thing can affect another. Adding value to how one might think about life. Part philosopher….

Testers help to protect consumers from crimes that could be committed against them by checking the security of bank applications and credit applications, etc. Part security guard….

Testers do not accept things at face value. In work and out of work we investigate what people say, claims that are made. We research and look for evidence that proves or disproves the claims. Part private investigator….

Testers report issues to agencies when they find them. Whether it is through announcement or through emails, we communicate our findings to the people that matter outside of our sphere of everyday work whether this involves local shops, governments, or online sites. Part philanthropist….

Testers are quick to share information with other testers, managers, developers, etc. Whether in the office or outside, we have a tendency to not withhold information that could be of value to someone else. Part reporter….

When testers write a report to get an issue addressed, whether in the office or outside of it, we have a tendency to have already gathered the facts. We present arguments to show why these issues should be addressed. Part lawyer….

Look at all the value that has been added to the system that a software tester is a part of!

We may feel stuck sometimes; or wonder about what we are doing and why we are doing it, but for most of us it is as much a part of who we are as what we do.

So, whether you are a lump-of-coal, a beginning tester who is trying to find out what direction to head down or how to improve your skills, or if you even belong in the world of software testing; or a diamond that has helped cut out and illuminate the path for other testers, maybe feeling stuck at a juncture in the road - remember one thing – Testers Rock!

Balance

2009-04-15T02:59:00.001-07:00

I set aside three hours for a solo “swashbooking” session. I picked out a few books from a local used bookstore a couple of days prior and left them untouched in a bag until today’s session.

The titles that I selected came from different sections in the bookstore; ranging from philosophy to biography. These are the books that I selected:

The recurring theme that I found throughout the books was the struggle of humanity to balance the logical/doing and emotional/feeling sides of their inner selves. I found this theme based on notes that I jotted down when something “popped out” to me in the pages that I was reading.

I found the session very interesting and the theme well worth contemplating. It is not that difficult to find oneself leaning towards one side or the other, throwing off the balance between the two sides of the inner self. I took a walk in the woods with Henry (my pup) and contemplated what I had learned.

I thought about how if the balance is thrown too far off in either direction, the person usually has to be made aware of it by someone else. Perhaps a child or a spouse has to pipe up and say, “You are not listening to me”. Or a coworker/friend/family member says, “Hey, you really should lighten up.”

Balance is important in all aspects of life or complications can arise. These complications may not appear immediately. Take the person who overeats due to an imbalance on the emotional/feeling side. How long before the scale screams at them? Or if the person is imbalanced on the logical/doing side; how long before they end up with physical issues and/or end up in the ER?

So, how does one strive to maintain equilibrium? The first step to doing this is to be aware of you. Be aware of your physical, mental, emotional, and spiritual self. Be aware of the systems you are part of, those you affect and those who affect you. Once a person is aware of these things, it becomes easier to see when the balance is off and to put something in place to even it out.

Spending too much time at the desk working on a problem or a deadline? Maybe you cannot take a week’s vacation in the Bahamas, but you can go for a walk, take a bike ride, or dance like crazy for a few minutes.

Feeling a bit emotionally drained from certain circumstances, got the blues? Maybe you cannot make yourself feel better, but one of the best cures for this is to do something for someone else and lighten their load. Putting a smile on someone else’s face winds up putting one on your own.

Striving for balance may seem alien or difficult at first, but the effort is well worth it to yourself and those around you. Be aware of yourself and take care of yourself, enjoy your life.

Competitive 'Swashbooking'?

2009-04-10T02:53:00.000-07:00

Over at the Software Testing Club, which is now at a membership of nearly 2800 software testers, I started a discussion on How do you keep your brain sharp?. Lots of great answers were shared, but one in particular caught my attention. James Bach, developer of the Rapid Software Testing course, said he practiced "swashbooking".

Everyone who knows me, both in software testing and outside of it, knows that I am a huge fan of books.... and James Bach's teaching/ideas/philosophies. But what exactly is "swashbooking"?

Have a look at the Brothers Bach participating in a round of Competitive Swashbooking.

While watching the video, which is both entertaining and informational, I had a couple of thoughts. When I have needed to research for a particular subject - I stuck to the subject at hand. The problem with this "philosophy" is that not all subjects are equally represented informationally. Many times I have encountered dead-ends in research due to a lack of information that was subject-specific.

"Swashbooking" appears to have the ability to help create a reference book in the brain. This could help me to "remember" something that I can use to help formulate an idea, give substance to a thought, or back up an arguement/opinion.

I am definitely going to try this out. There are at least three used book stores in the area. This weekend I am going to visit at least one of them, purchase some books, and set myself up with a timed session on "swashbooking".

***Thanks to Jon Bach for posting the link!

Exploratory Training

2009-04-05T04:56:00.000-07:00

Last weekend my girls and I travelled “Downstate” to pick up a German Shepherd puppy.

Henry (German: Home Ruler) is 3 months old.

Needless to say, puppy training is top priority at this time.

The number one thing that I have discovered is that training a puppy is a process that needs to take several stakeholders into account. Henry, myself, my daughters, my family, friends and neighbors are all affected by the training that the puppy receives. Each of the stakeholders expects something different from the end result – which is “Henry the dog”.

Henry, I imagine, expects to feel safe and loved, and be fed, walked, and played with. I expect Henry to treat me with respect and to not be destructive. My daughters expect to have a buddy. My family and friends expect to be able to come over my home and not be jumped on or frightened by Henry. My neighbors expect Henry to leave their property alone and not frighten them or their children and pets.

Before the process of training a puppy begins, it is important to know what the expected result of the training is and who (which stakeholder) will be inevitably affected by it. The expected result of the training is determined by what the desired behavior of the puppy will be when each phase of the training is completed. How do I determine the who, what, where, why, when, and how of the training?

First I need to consider finding some oracles. I have set up a network that allows me to consult with three human oracles (these oracles are breeders and/or owners of dogs, two of which are German Shepherd specific), and there are several oracles that I have found online (these are sites that cover basic puppy problems and training techniques).

These oracles have, and undoubtedly will continue, to provide me models of training that have worked for them. They will provide me with heuristics as well. (Heuristics are fallible ideas or methods that may help me simplify and solve a problem. [Kaner and Bach] For further information on oracles and heuristics please see the Introduction: The strategy problem and the oracle problem page at the Center for Software Testing Education & Research Web Site.) Because these heuristics are fallible the odds are high that part of the solution will be to address a common problem associated with training/raising a puppy; and part of the solution will need to be specific to the stakeholders involved. There are project differences between the human oracles I have access to and my personal project. These differences define the ultimate success or failure of the mission. Some examples of the differences include, but are not limited to: children in the home, rural vs. suburban living, schedules, and the “purpose” of having the puppy to begin with.

In order to reach success for this mission/project it is imperative that the differences are addressed along the way. This will require *Exploratory Training: simultaneous learning (what is the potential cause of this problem, whose problem it might be, which part of this is not working), training design (how could I address this problem, what could be the missing piece here, what if I…), and execution (apply training method).

Training manuals, programs, and processes will get me only so far in any project. The scope of any project may be defined for me, but how I approach the project within my own mind is not. Oracles that I use may have value to me, but they are not the rules of application to me. Heuristics are themselves defined as fallible, but how I choose them determines some value to my project. It is impossible to perform rote activities to train a puppy successfully. When training is applied in this manner there is a lack of bonding and loyalty. This will inevitably be an issue with all that are involved in the project. Exploratory Training is what encourages and enables that bond to be created and the relationship to grow in a positive direction. It is when using this approach that one begins to feel invested in the project, the project becomes personal, and it’s success begins to matter.

*Based on the definition of Exploratory Testing by James Bach.

Are Your Lights On?

2009-03-25T14:55:00.000-07:00

I just finished reading Are Your Lights On? by Donald C. Gause and Gerald M. Weinberg. The subtitle of this book is “How to Figure Out What the Problem REALLY Is”. The subtitle, coupled with the Customer Reviews on Amazon, is what drove my decision to buy/read the book.

My favorite chapter is Chapter 10, "Mind Your Meaning". This chapter deals with the words that are used in written communication and how there are multiple meanings that can be taken from what is said. The first example in the book is about a sign hanging in a window that says, “Nothing is too good for our customers”. The example goes on to question what that statement means. Two optional meanings listed in the book are, “There is no thing in the world that is too good for our customers” and “Giving them nothing would be giving them something too good for them”.

While the book approaches the problem with problems in a humorous way, there is much to learn from it that can be applied to everyday situations. The reason that Chapter 10 is my favorite chapter is that is where I need the most work. It will be a bit of a challenge to/for me. When one person communicates with another, there is often the assumption that the other party “sees” what is in their head and "understands" what their intention is. This is not necessarily true. Unless people build a relationship between them it is often difficult to be on the same page.

The book describes a problem as “a difference between things as desired and things as perceived”. This definition certainly did give me a lot to think about considering that it widens the circle of what I would consider a problem in my little world with my little biases. If someone feels like they have a problem with me, then they do have a problem with me? And vice versa? Then how do I know if the problem is mine? Or someone else’s? This book has some great (and humorous) examples of problems and addresses “whose problem” it could be by listing out the potentials.

“Are Your Lights On?” is divided into 6 parts:

Part 1: What is the Problem?
Part 2: What is the Problem?
Part 3: What is the Problem Really?
Part 4: Whose Problem is It?
Part 5: Where Does it Come From?
Part 6: Do We Really Want to Solve It?

I found the book thoughtful, fun to read, and insightful.

Experimenting with "COTS"

2009-03-22T07:42:00.000-07:00

The company I work for has hired 3 Temporary “COTS” testers, and by this I mean, “Came in Off the Street”, not Commercial Off the Shelf. They were hired with the understanding that 1 position could become permanent. The reasoning behind the hires in the first place is the growth of the products that we are testing. The basic job they will fill is running scripted test cases for legacy products while the more experienced testers are working on the new one.

We have no set training program for new testers, especially under these circumstances. Information ends up passed on as needed from multiple sources. This was no different when I was hired on in a similar situation. Self-learning, self-motivation, self-management, and self-leadership are essential for developing a career in software testing.

Although I just stated that this “was no different”, it actually is different in one respect. The team I work with was previously exposed to Rapid Software Testing. This exposure caused me to wonder what would happen if these new folks were exposed to some of these ideas early on? I am not a teacher by nature, but when I have a passion for something, I have been known to inspire. And a real live experiment was available, how could I resist?

The products/applications that I am test lead of were the only ones left in an RC period, so I inquired of my manager if I could have the temps. This was agreed to so I set about on my mission. Please be advised that much of the following information is based upon what I gleaned from the Rapid Software Testing course, and I give credit to such.

Day One:
1. I went in their shared office and opened up a five minute conversation with them by asking “What is a bug?” and following that with “who are the people that matter?”.
2. History of the product that I was having them look at
3. Mission: “You are an alien from another planet; you have landed on Planet “Insert Product Name Here”. Your prime directive is to gather information on this product to bring home to your people.”
4. Tools: Something to present your information on, decide this for yourself
5. Questions and Answers
6. Task: Email the information to me at the end of the day

I visited them a few times during the day to see how it was going and ask what type of information they were finding about the product. One of them was way outside his typical comfort zone given a mission with so “few guidelines”. I explained a bit about Exploratory Testing and Rapid Software Testing to them.

When I received their Information Sheets at the end of the day, it was amazing how different each one’s focus was – in fact one had no focus, one appeared to have scripted test cases, and one had a few product enhancements.

I commented each of these out and emailed them back to the appropriate owner. My comments/questions included things like “what would happen if you did this” or “how is this information important to which stakeholder”. I pointed out the good and bad in each report. One spent so much time making the Information look like a Presentation that I commented about how more time spent in this document is less time spent testing/exploring the product. (I deliberately did not give them guidelines on this when I asked them to do it, this way I would have some sort of an understanding about what they feel is important information.)

My manager stopped by to ask me what I had them doing. I explained the above assignment to him and he asked me if I had given them any oracles. I said they are available, but I had not given them to the group. I wanted to see what they would find out on their own. It is easier to give a lesson in something when someone sees the value of it. A couple of them did seek out the Help files on their own. And one of the persons found a viable bug in the product.

Day Two:
1. Went into their office after giving them a half-hour to go over yesterday’s returned Information Sheets
2. First Assignment – without helping each other, go through and uninstall the application from yesterday. Gather information on this and ask yourself questions about it. Do I like the uninstall process? Why or why not? I set them to task to investigate and gather information on it. This was a timed 30 minute session.
3. Day two’s five minute conversation was about the constant changes and challenges in testing. Being able to switch from one task to the next without too much time in between is essential in our department.
4. Discussed the uninstall process of the product – this particular product has an ugly uninstall process and leaves too much behind. I wanted to see if anyone found it all. No one did, but I showed them where everything was and explained why this product did not meet our company’s standards for uninstall, that this was a bug and there are plans to fix it.
5. History: I presented them with product two that is in the group of products that I am responsible for and gave them the history on it.
6. Mission: Same as Day One
7. Oracles: I gave them the definition of an oracle and presented them with three of them. User guide, help files, and marketing material.
8. Questions and Answers
9. Tools: Something to present your information on. Decide this for yourself.
10. Task: Email the information to me at the end of the day.
Once again, I popped in and out of their office to make myself available for questions and to add little bits of information to the task. The same person who found a viable bug in Product One/Day One, found a bug in this Product Two/Day Two.
When I received the emails at the end of the day, only two of the temps had sent me their Information Sheets. (Not sure what happened to the third and I hate to make assumptions.) This time I gave them each other’s sheets to check out. This sets out to instill the “constant change” and to set up for the Day Three conversation.

Day Three:
1. Went into their office after giving them a half hour to review each other’s Information Sheets
2. Day Three’s five minute conversation was on sharing information. After acknowledging to them that I am aware that they may feel that they are in a competition for the possible permanent position at the end of the temp season, I informed them that their competitive edge is what they do with what they learn and that most of what they will need for this edge will take place on their own time, not within the office that they share. I spoke with them about the necessity of sharing information and used the example of my father to drive home the point (Why Share). I discussed how they would need to become reliant upon each other and build a bit of a mini-team within the team. Information sharing and teamwork are essential for success.
3. First task of the day was a 30 minute session on uninstalling the product from Day Two and to gather the information about it together. We then discussed what they found out about it.
4. History: I gave them the history of the product that I was having them look at on Day Three. Being part of the test team for this one from the ground up allowed me to explain what it was like to test a product with little documentation and how the project people had to focus on getting the product/application changes implemented, tested, and out the door. This product/application is much more complex than the other two that the temps had installed. It had scared off a few experienced testers when it originally came in house.
5. Mission: Same as Day One, only by all means help each other out.
6. Oracles: Same as Day Two.
7. Questions and Answers
8. Tools: The template that our team uses when conducting Exploratory Testing.
9. Task: email me the ET Sheets at the end of the day.

That was Friday. When I briefly glanced at their ET Sheets before heading out for the weekend, I was pleased with the results. Each one has their own style of writing, but each sheet was more focused on information and contained less “filler” material.

While they are not being utilized on another project (which is subject to change while I type); I will continue to share information with them. The above is a brief summary of what was brought to them in the past week, but within each “lesson” there were other “embedded lessons” as well. I have not planned out the “lessons” but looked for what was lacking or not understood in each previous lesson in order to drive the next.

I have no idea if what I am doing is going to produce any benefits to them, to the team, or to the stakeholders. Time will tell.

The Perfect Storm, Part II

2009-03-15T05:07:00.000-07:00

Wow, a lot can change in a few weeks. Evidently, more people on the project realized the extent of the problems and some things have been changed.

Most importantly, Point of Contacts were created for the applications/products/systems. In the case of the primary project that I am responsible for testing, I now report to an on-site individual with a background in programming. This has made a significant, positive impact on the project in very little time. No more trying to explain the implications of a bug. The POC has an interest in the project success because it reflects upon himself. Pride/ownership is now instilled in the project at the next level. There are now three of us, in two geographic locations, driving the test effort. All three are testing differently. One is primarily unit testing, one is calculation driven, and one is program/system testing. Usability, functionality, and integration are being tested by all three of us, but each with a different approach. We share information and the desire to see the product/application become a success. This simple change has enabled me to test more deeply, provide more information, and enjoy doing so without the added tension that was in the project before.

Now, here is where the story gets funny. My first meeting with the POC was in order for him to see what “QA” was responsible for and what coverage we were providing. I had written some regression test cases for the Automation team to implement. These were run through one build. While in that meeting, it was made apparent to me that even these were going to be rendered useless. A large part of the program has been changed. Along with the large change, several smaller usability issues were finally addressed as well. By the time the meeting was over, there were two test cases left that automation could run for the regression testing! I do find this quite humorous. First because I hate writing/running scripted test cases, and secondly because my heart belongs to Exploratory Testing.

I was also able to discuss with him my concerns on the project, up to an including the people problems and the problems with development not providing any information about what was done to fix a bug. (When a bug was sent back to be retested, all it said was “completed”. Now, seriously, what does that mean? What was changed? When I get bugs backed from developers with no information, it “bugs” me.) He has promised to get these issues to a place where they are not issues any longer.
The major program/application changes will be continuing until at least the August 2009 release. In fact, that particular release will hold the most risk due to the changes that are pending for it. I look forward to seeing the program/application develop. I look forward to testing the changes. I look forward to seeing the positive customer feedback due to the changes. I can work with this team. And because we share the same common goal, it is much easier for me to do my job and enjoy it as well.

The two other applications now have a POC as well. This is an unknown variable until after the March release, but I can now look ahead with an optimistic attitude to the changes that will come about. My one problem, which is mine alone, with the other two products is that I cannot seem to stick within the boundaries that I have been given. I am supposed to only focus on the direct integration portion of the products, but I cannot help but explore past the boundaries that have been given to me. Sometimes this affects how other testers relate to me. Crossing over my boundaries heads directly into their “territory”. I have been reminded of my boundaries by management, but not prohibited from pursuing my course (I argue well). I take this as a “go ahead to do it, but not with my permission” attitude. I have explained that I cannot help myself. I only hope that eventually the other tester who is the lead of the project will see that I do not want his project, but I do want the customers to be satisfied. I hope he will see that we are on the same side and that an “extra set of eyes” is a good thing. And I am respectful of the lead testers in all the projects that I test on. I provide them with information and only go around them if an issue is such that it affects another project.

Time will tell how things go with the other two applications/products. One thing I do know, when I pointed out the issues that were outside of the scope of testing the product/application, this information was just as helpful to management as the information on the project. The powers that be saw the project in a different light, took into account what I was frustrated with, and changed things. These are “people that matter” (James Bach) to the project. Everyone really wants success over failure and reporting the issues with the processes (even if they are people related) can be just as important as providing information about the product/application/system in test.

The Perfect Storm

2009-02-17T04:39:00.000-08:00

I am involved in a project that has been labeled “The Perfect Storm” by my manager. The label actually has helped me to put my role in perspective and enabled me to come up with a few ways to do my part to get the ship safely to shore. Here are a few details about the project.

1. Four different geographical locations with 2 different time zones
2. Three separate products/applications that integrate with 3 separate larger applications/products/systems
3. Two “QA” groups with different roles and two different cultures/managers/processes
4. Three bug tracking systems
5. At least 4 different development teams are involved once the products reach integration
6. Each “QA” group has several other products/applications/systems that they are involved in testing – most of which take a higher priority

Communication is of the utmost importance – yet early on it was easy to see this was not going to be easy. Issues involved with communication can and did easily turn into trust issues since human beings are involved. Finger pointing, accusations, misinformation, stepping on toes, and just about every conceivable issue with communication became apparent to me within months of my being involved in this project.

My first response was to get extremely annoyed/angry/defensive. The teams that I have spent most of my time working with did not behave in this fashion. My second response was to go to my manager and hand the project back over to him to give to someone else. This was how I had received the project to begin with. It was handed over to the manager to hand over to someone else. I did not want this project to be my "undoing" and I told him so. It was at this point that he said some things that have changed my view of my role on the project. It took me a couple of days of contemplation to transform my thoughts.

First, it was his description of “The Perfect Storm”. I have never read the book, nor seen the movie, but I have lived on both coasts in the U.S. (New Bedford, MA for about 17 years and not far from Huntington Beach, CA for six years) and have been through my fair share of hurricanes, major storms, and blizzards. The implications of this description were not that difficult for me to imagine.

Secondly he said, “Maybe it was because I was in the military, but any task I was given to do, I did. I did not have an option out.”

Finally he said that I was the perfect candidate for this project. (Why? Is it because I appear to be more Vulcan than Human? Was it because I call things as I see them? Was it because there really was no one else to take on the project at this juncture? Was it the projects reputation? Was it a compliment? Was it selfish on his part?)

I determined what I was responsible for and cast aside what I was not. I remembered that first and foremost I was responsible to the stakeholders and customers of the project. What would they expect of me? I based this answer upon what they have come to expect of our number one product/application/system. What should I be doing if this is what they expect? (I can use the number one product as a consitency with project heuristic.) What do I have the power to change in this project?

I divided up the people on the project into groups in order to determine what I felt each group would expect from me in terms of documentation and other forms of communication. I am currently documenting what I do and how it affects the overall project. More posts on this to follow….

Side Note: This is one example of why I respect and admire my manager. He uses my own beliefs and character against me. This challenges me and keeps me in touch with my own principles and values.

Testing With Spec(ulation)s

2009-01-31T04:59:00.000-08:00

There is no doubt that we can test without specs. We did it for over a year with a particular integrated product, but now we have reached a pretty large impasse where the powers that be need to make some decisions.

We have two test teams who test multiple products between them. We have several products that integrate with the primary products/applications/systems that we test. One particular integrated product was brought in a year ago. This product was primarily tested by the team that is off-site from mine. While we participated in the test effort with the integration process between our primary products, we were not “responsible” for the product. The first year the product saw little controversy. Year two has been filled with it. Since the product has no requirements specifications, questions have been asked that have previously not been thought out.

The first to feel the ramifications of this was the customers. A bug was reported and at first it was handled by the primary test team. The response was to handle the bug with what knowledge of the product was available. This limited knowledge is dependent upon how the tester feels the application should behave. There was no business logic in this response. It took about 6 weeks for this bug to funnel through to the development and product management staff’s associated with the primary products. Since the customers of these products/applications/systems were the ones who were being affected, the bug was pushed to be fixed immediately.

And as with every quick bug fix, there is likely to be another bug. And there was. Or rather, maybe there was. In different scenarios, the product displays inconsistent behavior; therefore the inconsistency is a bug. But what if the bug is really in the consistent scenarios? This depends on what the intention/design/business logic is supposed to be. And, as of yet, no one has an answer.

Our two test teams met to discuss several aspects of the product integration of this particular application/product. The initial meeting was to define who plays what role in the testing and to answer the question as to whether or not we are duplicating test efforts. (This was my fault as I go a bit further in how I test the integrated products than was written in the test plan. I have several machines with various “customer” installations. I keep these updated and run end-to-end testing; I don’t just bring in the file that integrates. That is not in the test plan.) The meeting did shift to give us (testers) the opportunity to discuss what we are really lacking on the project to help the stakeholders make the business decisions - and to help customer support to help the customers. One of the primary concerns is the lack of specifications. How do the stakeholders want the application to behave for multiple years as far as integration is concerned? How many years of the primary application should be supported in “backwards” integration? What if the customer does not purchase updates, how should that be handled in the integration? How should customer support handle this? Will the product be supported in this instance? Then there is the customer base. The multiple primary products have customers who behave differently. Should the application behave differently for each customer base?

Who is to blame for this issue? Perhaps everyone, maybe no one. There was definitely a lack of communication between the product management teams, the development teams, and the test teams, but this may have been unavoidable because of the geographically dispersed teams, the number of products involved, and the diversity of the customer bases. Determining what the desired behavior of the product should be will have to involve at least 4 product management teams. Due to the diverse schedules, deadlines, and commitments for the various projects, people have a tendency to focus on their aspect of the big picture, the part they are “responsible” for. It is not too difficult to see that sometimes some things may be overlooked. We are all human.

As it stands right now, the testers involved the most in this product have been able to funnel to the test team managers and the director of our department the concerns that we have in the testing effort. Questions, including the ones above, have been placed in their hands. They have agreed that this is a large problem that affects multiple product/application/system teams and they will push these concerns further up the line to the product management level. A potential rift between the two test teams has been quelled by the realization that we are all in the same boat. And, as far as I am concerned, we did exactly what we were supposed to do. We provided “information to the people that matter” (James Bach) about the products. I hope that they will reciprocate with information for us.

About Stupidity...

2009-01-24T04:10:00.000-08:00

I was in a mood…

There was a bug in the software that I was testing. This software affected two other applications/systems/products in test. Customers were already broken in one of the products and the other project people wanted to know if their customers would also be broken. One quick test said “yes”.

The second project was told of a “fix” for the customers. I was asked if the “fix” would work. Testing the “fix” revealed it not only would not relieve the customers in the second project, but following the given steps could not have actually relieved the customers in the first project. I put forth my findings, along with screenshots, in the ever growing email chain. I inquired if there was a step missing which would actually fix the issue because the second project would need to know what it was. There was a shift in the communications at this point.

From can we “fix” our customers if they get broken in this scenario, to one of the key people beginning to point fingers “what does not work for Michele is what we used to fix our customers…” How does an email go from determining "if the customer has a broken application can we fix them" to pointing fingers at “Michele”? There was accusation in the thread as if to say I was causing unnecessary trouble and I had no idea what I was talking about.

I did not respond. I did however talk to myself for about five minutes.

Stupidity is what I attributed the shift in the communications to. In fact, I thought about stupidity for the rest of the day and began to google it when I got home. That is how I found Understanding Stupidity, a study by James F. Welles, Ph.D. (The author has written a couple of books on the subject as well.)

I have not yet finished the reading, but not long within its pages I found some interesting thoughts to ponder.

Here is a quote from the study:

“This is exactly what stupidity is —a schematically generated, self-deceptive breakdown of the feedback mechanism between behavior and the environment.
This breakdown necessarily follows from stupidity's success in creating an arbitrary world that will maximize cooperation of group members. This can be done by blocking disruptive input as well as by inventing pleasing images and ideas. Such tactics may prove to be maladaptive, but this is the price for the immediate reward of enhanced social cohesion.
As effective as stupidity may be in promoting cooperation, it disrupts a system's capacity for effective learning. Understanding is sacrificed for the sake of social cohesion and cultural stability.”

This is a very interesting read. Well worth checking out for thought-prodding information on not just Stupidity in others, but our own as well.

Dark or Bright Future? Who decides?

2009-01-18T04:08:00.000-08:00

I read Michael Bolton’s Two Futures of Software Testing presentation, twice. I have had some experiences with both the Dark and the Bright Future as they are described in this presentation.

I work with a couple of teams because I test a variety of products that integrate with the main application/product/system that our company develops. One of the teams has a tendency to promote quite a bit of the Dark Future, while the other is generally on the Bright side. But, on occasion, even the “people that matter” (James Bach) on the Bright side forget things.

An example of this forgetting occurred last year during a Release Cycle for an application that I was testing. The application (in very limited description) consists of user input that calculates on data sheets below, allowing the user to simultaneously enter data and view the changes. The data sheets are modified and updated by one team of developers, the input pages are modified and updated by another developer, and the application is handled by a third team. Only the application developers and product management are on-site with the testers. During the Release Cycle, testers were submitting bugs on one version of data sheets and the developer was fixing them on a different version (a later version that was not in the application at the time). Obviously this caused a great deal of confusion as well as a lot of wasted time/money. It was time for a meeting.

The meeting was supposed to be for the group to find a way to make sure that we were all on the same page, testing and developing on the same version. Two things that were said at the meeting will remain embedded in my mind for a long time. Both comments were made by Product Management. After we all agreed that there were some problems with the process and with the communication, the “we need to release this” subject came up. The conversation went something like this:

Product Management: “Why don’t you just stop looking at it?”
Me: “Are you asking us to stop looking at the application when it is in test? Are you asking me to stop testing?”
PM replied: “Well if you keep finding these bugs and we have to keep fixing them, you will never release the product.”
Me: “We, the testers, do not make the decision to release the product, (pointing around the room) you all do. We simply provide you all with information so that you can determine the risks involved.”

Since I was in a meeting with most of the people who actually make up the Release Group, this was just a reminder of the truth. It was an “oh, yeah” moment.

On the team who leans toward the Dark side, product management seems to allow testers to design changes to the product and to determine when the product is to be released. For this group, I was invited to a defect review meeting on the phone. I asked my manager to sit in with me for two reasons. The first was because I did not want decisions to be made by the tester in regards to changes that needed to be made based upon the integration with our product. The second was because I did not want to say something that would get me fired (sometimes I am zealous and outspoken). My manager simply said “Product Management will decide…” at the end of every significant defect that came up, sometimes interrupting the test lead and developer as they were discussing a fix. The funny thing is that once he started saying that, the Product Manager felt empowered and began to take the reins.

Though I hope the message remains in the Dark example, it is likely to need continuous reminders. Habits die hard. As perplexed as I was about the tester role they embrace, it is highly likely they are just as perplexed at the views we expressed when communicating with them.

I could not help thinking about the Jedi in Star Wars while reading the presentation, but my exposure to the movies/books is limited (I prefer Star Trek) so I cannot really draw a decent analogy because I am not sure if it fits. One thing I do know, I do not want the Dark Future of Software Testing to become a reality. I have the power to stop this from happening and so do you.

How? Remember who you are. Remember what your mission is and why it is important. Communicate this to the others involved in the projects that you are on. Become involved in the future of software testing by becoming involved in software testing discussions and communities such as the AST and The Software Testing Club. Discover what matters to you and actively promote it. One voice may be but a whisper, but many voices are hard to ignore.

Models and Metaphors

2009-01-17T04:26:00.000-08:00

I was asked by Shrini Kulkarni in a discussion at the Software Testing Club, if I distinguish between Models and Metaphors. Indeed I do.

My view of metaphors and models was instilled in me when I was a child. Not by my parents or my teachers, but by books that I read.

As soon as I could read on my own, “Fun with Dick and Jane” got tossed and I was reading classic literature, along with allegories, fables, and Grimm’s version of fairy tales. When I was young these books took me to fantastic places and built my imagination. When I grew older and read some of them again I saw the double meanings and revelations of truth within the fiction. This had a powerful effect on me.

Literature is ripe with metaphors. Classics such as Melville’s “Moby Dick” have underlying messages within the story, pointing to the author’s view of things through the use of the characters selected. Shakespeare’s plays and sonnets have been a source of great deliberation and speculation because of his use of metaphors. Greek and Roman mythology is said by some to be truth veiled behind metaphors. And let’s not forget poetry where the use of metaphors brings about an added level of emotion and beauty.

As for models, the first real one that I was knowingly exposed to was in my Uncle Charlie’s basement. He had a very elaborate model train display complete with houses, people, vegetation, animals, roadways, and vehicles which were all put together in miniature scale. I enjoyed watching the train as it went through various tracks in the village and I imagined what it would be like to be on the train. But I had also been a passenger on a real train. Because I had been exposed to the real thing I noticed differences between the two. For one thing, the real train I rode on did not run on electricity and was not guided by a remote control.

Models, to me, are objects or ideas that can be used as a guide for something tangible. They are no more “usable-as-is” than metaphors, but they offer more substance to work with. If I wanted to build a train, my uncle’s model would only offer guidelines/ideas to do so. The materials, engineering aspects, tools needed, blue prints, labor, etc. would need to be radically modified if I were to create a usable product.

This is, “in a nutshell”, how I distinguish between metaphors and models. I find value and usability in each, but generally neither one is complete on their own.

We Can Affect Change

2009-01-11T17:06:00.000-08:00

I made a promise to myself when I found out that I had the weekend off. I promised myself that I would finish reading Outliers by Malcolm Gladwell.I lied. Though I completed the book, I am not finished with it. I have no doubt that I will be thinking about it for quite some time.

Points of the book that had a big impact on me can be summed up in the following words: opportunity, practice, communication, and hard work. I have made a decision to focus more deliberately on these things with my children. I have always been an advocate of reading with my girls. I read to them when they were younger and kept them reading thereafter. It was not until my youngest daughter was born (11 years after her siblings) that I realized how much was not instilled in my children. I introduced the youngest to classical music, number flash cards, and the solar system before she could sit up and have continued to provide opportunities to her as she grows. These, of course, are in conjunction with the drive to read. I taught her about imagination and how to use it, when my other children were younger I thought it was a natural part of childhood. The culture that I was raised in was one where parents had little involvement in children’s lives. The provided for the needs but did not nurture the education of the children. This is not to say that I lived in a house without love, but borrowing on a theme from the book, it was the way it was for generations in my family history.

Another significant cultural and historical family way that was passed down through the generations of my personal life, that was not touched upon in the book, but came to mind while I was reading Chapter Six “Harlan, Kentucky” is the way they perceived the role of a woman. A woman’s role is beneath a man. In my family history there are no women who pursued an education or a career until this current generation. And even though this generation has begun to change the historical culture of those before, most of them still struggle with being a woman and doing such. It was simply something that was not done, and if it was attempted, the woman was looked down upon. She was made to feel guilty and disorderly for doing so. I did not raise my daughters with this historical view of women and yet one of them has continued the pattern. Reading this book has helped to put the pattern in perspective and now I have a different approach that I can use when talking to her.

The chapter that was most significant to me on a career level was Chapter Seven, “The Ethnic Theory of Plane Crashes”. The communication issues raised in this chapter really affected me; I actually did not feel well when I was reading it. Pilots have a significant higher loss if they do not communicate well than software testers, but the lessons are the same. I was particularly fascinated by the seven errors versus one fatal error illustration.

One point in the book that I found profound and wish that the author had expounded upon were the “qualities that work has to have if it is to be satisfying”. This is pointed out in Chapter Five, “The Three Lessons of Joe Flom”. The qualities are “autonomy, complexity, and a connection between effort and reward”. The words impacted me as I read them because I had never heard of the qualities of job satisfaction before. These same qualities are why I love my job, but it took me time + an (accidental) opportunity to find it. I just wondered what would happen if high school students knew these qualities in advance.

This book is not trivial. It will make you think about things in a different light than you are used to. We have a tendency to either take things at face value or believe in luck. What I took away from reading this book is that if the opportunities are not there by fate, we can at least try to provide them. A quote from Chapter Eight, “Rice Paddies and Math Tests”, proves to me that hard work can change things. “No one who can rise before dawn three hundred sixty days a year fails to make his family rich.” Rich, to me, is not necessarily money. And family, to me, are those I know and have constant contact with, therefore I believe we can make things different. We can affect changes.

I Still Love My Job

2009-01-06T15:29:00.000-08:00

Oh the joy of testing tax software during the holidays. Between the hours spent at work and the shopping, family get-togethers, visiting Santa, wrapping gifts, etc. you never know what day of the week it is until after the Release Cycle ends. You wake up one day and it is January 5, 2009. Of course for the next few days you have to retrain yourself to remember what day it is and remind yourself that the Calendar year is now 2009.

I am not complaining at all. In spite of the extreme amount of hours, major releases with the group I work with on site, are always a great time of learning, excitement, bonding with other testers, going through the trenches with them and seeing development and product management roll up their sleeves and get into the cycle as well. A common goal can do that to people. It is great to be a part of such a group of individuals. This is why I have such a difficult time when it comes to dealing with people who do not seem to have the same vision/goal as these folks do. It was nice to be a part of the on-site team for the whole release cycle and not be pulled into any other projects during it. It may have been more hours than I wished I worked, but it actually brought me peace:) (Testing – Politics + Great People + Common Goal = Peace)

So in order to treat myself and my tax-season orphans to a day out, I took off early on Monday and went to the local mall. I took my youngest to the bookstore to buy “12 Dancing Princesses” (a Barbie book) and found “Outliers” by Malcolm Gladwell on the shelf. I picked it up and have started reading it. For a bit of a background on what the book is about try this Pop!Casts presentation. I was going to order it online (when I had the chance to sit down and think) but finding it there saved me shipping, handling, and having to wait.

Speaking of ordering online, I also pre-ordered ”Secrets of a Buccaneer Scholar” by James Bach. I am looking forward to reading it. I have a list of people I admire and have learned from, and James Bach is definitely on it. In fact at one point in time when my boss was seeking to hire some temps to help out on a project I told him to ask James Bach if he would like to come on board for a time. I even said I would share my office with him if he said yes. The team I work with know I do not share my office space or computers with anyone so this shows how much respect I have for the man. I don't think my boss took me seriously because the subject never came up again....

Today it was back to another “fire” on another project, but this tester is much more at ease with life. A few days of “just plain ol’ testing” and I am ready to go. I still love my job:)

Sometimes Soft Skills Can Be Hard

2008-12-27T06:09:00.000-08:00

When I took the BBST Foundations course through the Association of Software Testing, I participated in a group/team exercise. The participants were separated into groups to discuss and deliver a joint assignment on the testing of a certain type of software.

One of the issues we had to deal with involved the distance and time differences between us. In spite of working in a geographically dispersed team, we shared the same goal of wanting to be successful in our project. This goal was enough to ensure that we worked together, treated each other with respect when debating, and kept our communication lines open. We placed the common goal before the challenges. In other words, the remainder of the issues that face virtual teams fell second to the desire to be successful. This was truly a great experience.

But….

I work on a project that involves a geographically dispersed team. The lead tester is located in a different State and the developers are located in a different country. I became involved in the process mid-Release Cycle of the last release to customers. I had barely any time to get to know the product before we were off and running. No big deal, I hold fast to what I learned in the Rapid Software Testing course that Michael Bolton taught at our company some time ago. I especially hold fast to the thought that I can test anything that is put in front of me. It may not be the best plan, but as the late General George Patton said, “A good plan, violently executed now, is better than a perfect plan next week”.

I installed the program and the associated hardware (which I had very little knowledge of using) and began to just explore. I submitted some bug reports on the product. Next thing I know there is an email chain circulating on whether or not I understand my role in the testing of this product. One would assume that testing was my role. Evidently I was missing something. Oh yes, the politics of it all. Long story short, I stepped on toes.

For the next couple of weeks it was quite difficult to work with the people involved. There was a lack of trust (on both sides), a lack of information, and above all else a lack of communication. The communication that did take place was forced and inadequate for working together on a project. I was completely frustrated. I did not understand why this much ado was taking place over a simple collaborative project. I came quite close to giving the project back to my manager so he could put someone else on it.

So now what….

I have no power to change anyone. I can only change myself. I decided to put my anger aside and my mistrust. My manager and I have had a couple of talks to discuss what the real issues are. Issues with processes and communications are the focus, not the people involved. Focusing on the issues instead of the people helps to prevent blame and finger pointing. It enables you to look for possible solutions to the problems. And added, and one of the most important benefits from this approach, is the removal of bad stress.

It is also possible that this current challenge can end up a positive experience for all involved. We both have our own separate processes and protocols in place. While theirs may not work for us, and ours may not work for them, and both of us using our own is not working for the collaboration, we may just find some improvements in the way that we do things that could benefit all of us. This is possible as long as we can all remove our biases from the situation and place the common good over the individual.

2008-12-23T01:46:00.001-08:00

I awoke yesterday to approximately a foot and a half of snow. A Noreaster had blown through in the night and left the gift of a White Christmas behind.

After a normal snowfall, I usually get my driveway and walkway cleaned up in about an hour. This was not normal. What to do?

Approaching the task can be compared to testing a product/system/application. Where to begin?

First, there is observation. What do I see? What does the terrain look like?
Second, what tools do I have that I can use? Unfortunately I did not have access to Automation (a snow blower would have been nice). There was not enough time or resources to acquire/learn/use automated tools. I did have three tools that I could use. My mind, a scoop, and a shovel were available.

My brain guided my decisions throughout the endeavor. When there is approximately 18 inches of snow you cannot just shovel it out of the way. You have to think about where you are putting the snow so that you do not run out of room to put it. You have to think about how much space you need in the area you are cleaning. A shovel's length path may be fine for the walkway, but it takes a lot wider of a path for a car to fit through the driveway. Without using thinking skills, the tools would not have been much help to me.

Now with the amount of snow out there, one could get overwhelmed with the task at hand. How should that aspect be handled? I decided to divide my time into sessions. I spent 30 to 40 minutes of shoveling, followed by 10 to 15 minutes of warm up. I did not put the task aside for warm up, but used it to survey where I was in the project. It could appear that the project is making little progress at times, especially where the driveway intersected with the road (product integration can be a bit taxing at times), but one saying rang through my head the whole time: "How do You Eat an Elephant?"

When approaching a test project that seems a bit bigger than you, or a storm clean-up that is nearly as tall as you, just remember how to eat an elephant. (One bite at a time :))

The picture, though not altogether glamorous, does provide a bit of measurement of the plowed wall of snow at the end of my driveway. I am 5 foot 2, the wall is close to four feet high. It took 3 hours to shovel, and I forbade everyone around me from singing “White Christmas” for the entire day.

Happy Holidays and Merry Testing!

Lesson Learned

2008-12-14T04:14:00.000-08:00

I have a direct nature about me in communicating. I am also pretty zealous when I am testing a product/application/system. During this most recent Release Cycle of the product I am testing, this has gotten me into trouble.

The group of people that I am working with this application are in various locations. At least four different locations as a matter of fact. The processes involved in this particular project are not quite what I am used to either.

With our in house projects, when a new build is released to test, there is a certain level of information provided to the test team in order to know what has changed. This can be lacking and there can be omissions, but there is something provided. There is a certain level of information contained in bug reports that are sent back to us as well. The amount of information depends upon the developer. (Some of the developers are great, they give code specific changes. Others give information on areas the change may affect. Some do not provide any information, but when you work with them over a period of time you begin to understand what type of changes they generally make and it helps you to think about what might be affected.)

The project that I am currently on does not provide either one of these communications of information. When we received the most recent build there were significant changes to the installation. Some of the people testing the application in another location could not get the product installed. These testers are data testers, not program testers. The application is data/calculation driven. This either makes or breaks the project's success. These testers also work on various products/application/systems so their time is stretched thin.

Due to the diverse locations of the groups involved, it took over an hour to get the appropriate information to these testers in order for them to install the application and get to the testing. I was incredibly annoyed. I have a habit of thinking on two terms in my testing. First the customer, second the money. As ching-ching was ringing in my head over the potential amount of tester monies/time wasted because of a lack of communication, I sent an email.

The email was short and to the point. It was a request for a list of changes with new builds. It also pointed out the wasted hour. I ended up in my manager's office.

My manager pointed out that the folks I deal with in house can "see" me and "know" me, but the people I am dealing with in the other locations can not. I understand this and am glad that I did not type what I was really thinking at the time.

Mid-Release Cycle is not the time to point out deficiencies in the processes and the lack of communication. People can be stressed with looming deadlines. I thrive on them, but other people may actually be having a hard time with the pressures associated with it. It is, however, the time to take note of what is going right and what is going wrong.

When this cycle is through, my manager has agreed to have a post mortem with me and help me to quantify the changes needed in the current processes in order to help things run more smoothly during future release cycles. (We both agree that the processes are guidelines and not rules.)

Lesson learned. But, if you happen to walk past my office during the remainder of this Release Cycle, don't be surprised if you hear me talking to myself.

I Now Better Understand Cloud Computing

2008-11-27T14:52:00.000-08:00

I was fortunate to be able to attend a Microsoft Emerging Technologies presentation a couple of days ago. Apparently one of the ISV Architect Evangelists has family in the area and came up to spend Thanksgiving with them. He had met some of our development team at a conference that they attended in the recent past; one thing led to another and he wound up doing this presentation for us. Our QA department was given an option of attending. I jumped at the opportunity to attend. No matter how one feels at times about Microsoft, to me, they have done an extraordinary job of getting the average Joe to develop a daily use of personal computers and software. Since testing software is my passion and pays my bills, I feel like they helped build a bridge for me to get where I am.

The planned presentation was apparently supposed to be development oriented and over-the-heads of most of QA. Turns out that was not the case. To me the gist of the presentation was a Microsoft selling pitch. But, all that aside, I did get a grasp - finally -of what Cloud Computing is all about. I found it both fascinating and frightening at the same time.

Fascinating - the technology has existed for years to actually achieve what Cloud Computing hopes to accomplish (and has already accomplished). What I find frightening is the power that large scale corporations could have if this is used without regard to the same average Joe that has a dependency upon computer technology.

This is worth keeping an eye on for all consumers. I also feel that it is important to keep an eye on the technology changes that are paving the way for these changes as a software tester. It has turned my interest to several areas I may want to study up on in order to be more prepared for the future. These areas are based on the software testing that I currently do (depending upon your area of employment, yours may be different than mine).

There was a bit of information that was exchanged during this presentation that I am not at liberty to discuss due to signed non disclosure agreements. I will say that I believe it is important to continue to educate myself in the latest changes that are taking place in the technologies that surround us.
Since today is Thanksgiving in the US, I would also like to say that I am definitely thankful that I work for a company that values its software testers. Having an option to attend a presentation that was supposed to be development driven is a perfect example of the treatment that our QA department receives from the company that I work for.

For a bit of a background on Cloud Computing and briefs on some possible implications, please see the Wikipedia article on it: http://en.wikipedia.org/wiki/Cloud_computing.

Lesson Learned in Moving

2008-11-26T14:56:00.000-08:00

After much ado, I am finally moved into my new home :)

It nearly passes all the specs that I wrote on buying a home in the area:
1. The house will cost less than the appraised value
2. The house will be located in the same town where the owner works (the residents call it a city, but I know better)
3. Work, school, and home will be located in the same town
4. The house will be one story tall
5. The house will have a nice yard
6. The house will be in a quiet neighborhood
7. The house will have enough bedrooms
8. The house will be located in the Bahamas

The house meets seven out of eight of the criteria. And even though it does not meet the eighth item, it does provide me with a new hobby – home decorating. I have already decided to allow my teenage daughter to do as she will with her room. I must be crazy, but what teenager doesn’t want to have a self-designed living space? And my little one will have a room befitting the princess that she is :)

One thing that I did find out while moving here that did not appeal to my customer side, but did appeal to my software testing side was the transfer of my internet/email account.

Apparently the high speed internet company that I use removes your email account from you when you move – even if it is just to the next town in the same state. And, they do not inform you of this activity, unless you ask the right question. What is the right question? “I forgot my password because I set my mail up to remember it and now I cannot log in. Can you help me?”

I was quite annoyed at this. If I moved out of state, I could understand this (the email address includes the state I live in). If I changed internet companies, I could understand this (the email address includes the company name). I moved approximately 13 miles away, in the same state, with the same company – this I do not understand.

I ended up having a “ticket” in to get this resolved. I was told that I would have to wait about a week to have the situation resolved. I did not wait a week. By day two I had my email account fixed back up for me. This did not resolve my issue totally. I have to plan for the future. What if I do move out of state? I have moved to various states in my life so this is not out of the question.

I have decided to begin to investigate a couple of different web based email accounts that I have already. Perhaps I will have to develop a deeper understanding of these. Maybe I will have to learn to trust one of them to be my primary email provider. I doubt that I will trust them, I know too much, but I will have to look into this. It is very difficult to not be able to access email on demand. And these days it does not seem feasible to be able to go without it for very long because so much communication is dependent upon it.

For the love of books....

2008-11-12T16:48:00.000-08:00

Via Grig Gheorghiu
http://agiletesting.blogspot.com/2008/11/phrase-from-nearest-book-meme.html

I could not resist... I love books:

Grab the nearest book.

Open it to page 56.

Find the fifth sentence.

Post the text of the sentence in your journal along with these instructions.

Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.

"May I suggest , sir, that I only recently came off duty?"

THE MOON IS DOWN by John Steinbeck