Tested

Created this today when working on my testing book. 

I’m trying to find a cure for recurring anxiety.  I think the answer lies not in drink or drugs, but in words somehow. 

This is one of the formulas I’ve created for myself to read in times when I feel tested.  Consider this post as me putting it into clinical trials.

Formula 6:

Though this may seem a troubled sphere
And worry may have brought you here
The facts have yet to be made clear
Before you know which way to steer
 
You’re tweaked, you’re scared, you’re out of grace
You’re feeling mostly out-of-place
This happens in the Human race
These times when life is hard to face
 
You’ve either failed or out of luck
You’re in a loop, severely stuck
Or feeling you’ve been lightning-struck
Or waiting for the firetruck
 
You’re scared of what would surely come
You’re feeling like a no good bum
Or maybe that you’re feeling dumb
And more askew than perfect plumb
 
You breathe, you drink, you take that pill
But nothing works to cure your ill
The vexing problem lingers still
To test your heart and mind and will
 
But wait, I may have just the fix
To cope with this life’s many tricks
I’ve added substance to the mix
And called this dose Formula 6
 
Inside these words, line after line
You may just see the Great Divine
Or maybe not, but you’ll be fine
Just read the words before your wine
 
If you don’t know which way is best
Just say “Time out. This is a test.”
The council who has seemed at rest
Will show up as you’re feeling stressed
 
You’ll hear them if you listen close
They may be terse, maybe verbose
If all you feel is more morose
Wait 30 seconds for the dose
 
In lifetimes past your council met
You know us well, and that’s a bet
A deal was made that you’d forget
We’d be right there to stop your fret
 
You planned this out before you came
Before your life, before your name
You may just think that’s pretty lame
But simple truth is: life’s a game
 
I serve for you, as Council’s eyes
Believe as truth or believe as lies
You hired me in this disguise
Some call us God, but we’re Surprise
 
Life’s tests are meant for us to see
Might who you are, might who you’ll be
You told me this and trusted me
To answer when you gave a plea
 
“Time out” you say, and we obey
To help which card you’d like to play
The next thing that you have to say
Is call “Time In” and go your way

I just spoke to your class.  I showed you the Psychic App, the Mysterious Spheres, the Notepad bug — it’s the same stuff I show professional testers.

Your next assignment is to tell me a problem you’ve seen in something you’ve used.

You’re using Twitter, Tweetdeck, Facebook, MySpace, SecondLife, maybe even LinkedIn. 

You’re creating web pages, uploading pictures, downloading games, deleting spam, running virus checkers and firewall software.

You’ve got a Blackberry, a Razor, an iPhone, a Droid, maybe even a Zune.

From the App Store, you’ve installed Wa Kingyo, PixyMe, Shazam, Pandora, and a hundred other gizmos.

You own a DS, an XBOX, a Wii, a PSP, a PS3.

You’re playing Bioshock, Inferno, MassEffect, Zelda, Mario, CoD, GTA4, WOW, Farmville, MafiaWars, Tatsunoko vs. Capcom

You upload and download homework to the wiki, do your papers with OpenOffice.

You’re on Skype, Windows Live Messenger, Facebook chat, AOL IM, and texting on your cell.

You’re on Wave, Buzz, and Docs and you uploaded to blink.tv, YouTube, Flickr, PhotoBucket, and Viddler.

And of course, you’ve got your blog or your vlog or your podcast, skypecast, or webcast.

You’re surrounded and outnumbered by custom-made streams of electrons, pedabytes of ones and zeroes flying around you per second.  And while you swim in all of this technology, I bet you’re not thinking what you want to be when you grow up. 

While you wait for the video you edited to go viral and wait in line to become an internet millionaire, I suggest you pass the time by starting to notice problems.  There are companies that will pay you to test their technology and report problems. Yes, there are a lot of people out of work, so that’s why it may be good for you to start now.  Start building your experience ON YOUR OWN.  Employers might not care what school you went to, but they WILL care what stories you have to tell about problems you found.

So, all you have to do… (for now)

… is start noticing things. 

Start remembering errors and annoyances and things that go badly in all of the technology you’re using.

Discover something that doesn’t meet your expectations and practice describing it in writing — what you did, what you saw, what you had installed on your configuration.

I can help.  If you’ve found something, report to me in email or find me in Skype.  I’ll coach you how to report it, or to find other things — on purpose.

Testers are detectives.  We hunt for where software is broken and then tell a quick story about it called a bug report.

Don’t let the teachers fool you.  You’re smart and you already know a lot (look at the list above).

You have eyes and you have a brain.  That’s all you need for now to start practicing.

Get started.  Report one software problem you’ve seen in the last year.

Think about it, or if you forgot, find another one.  Professional testers like me never get tired of hearing stories, and we can help you know where to look.  We may not find what you find because we have a different configuration than you do, but that’s the fun.  Bugs are treasures waiting to be found, and companies want them found either before or after shipping (usually before).

Get on Twitter and query the #testing hashtag.  Read what people are saying.  Try out some shareware or a 1.0 app, get a machine you don’t care about and fill it with software, then start hunting.

Or, you can just wait until your video goes viral on YouTube and Tosh.0 and *others* will let you know the problems with it.

My dad is famous for writing books with crazy ideas:

* A seagull who breaks the rules of the flock to experiment with limitations of flight, only to realize there are none.

* A messiah who can levitate wrenches and heal people just by looking at them, but gives it up because he just wants to fly and fix airplanes.

* A flight instructor who realizes that changing our lives can be as simple as accepting new suggestions into our consciousness, as if all we need to do is agree to play along with the hypnotist onstage.

He’s made an amazing living on writing books like this.  He hasn’t had to hold a job since I was born (1968) because ideas have been his bread and butter — er, more appropriately, the wind beneath his wings. Money has flowed into and out of his life, but his ideas have always been his greatest asset, always lurking backstage, ready for him to turn them into a best-seller.

That *idea* itself, is contagious, so I felt compelled to talk about what happened when I tried to develop 3 of my half-baked ideas as a test manager last year …

Idea #1: When fast-food chain McDonald’s came out with its yearly Monopoly promotion, I got a little game board and posted it in my cubicle.  It was a fun little thing I wanted people to help me with.  If you went next door for a Big Mac, give me your little game tokens and help me fill in the board. But one of my staff knew I was a testing geek and dared me to find a testing analogy for McDonald’s Monopoly.  Somehow, it only took a few seconds for an idea to hit.

“You know how Baltic and Mediterranean are the least expensive properties, and Boardwalk and Park Place are the most expensive?  Maybe we could organize tests like that.  Color-code them by value.  There you go.”

I amazed myself.  The idea came from nowhere and it was kind of a joke, but I liked what I had just said!  A splash of color may actually be valuable to see on a spreadsheet — all of our tests, colored by value instead of boring black and white cells.

Ben shook his head and smiled, called me “the master” and said I had done it again. 

“Wait,” I said.  “I’m serious.  This idea might have merit.” 

I told him to contact a colleague named Robert Sabourin who uses color in his testing exercises to help testers do test design — Failure Modes (red), Capabilities (green), Inputs/outputs (purple), White-box testing (white), etc.

I gave Ben an assignment, playfully.  Write me a little experience report on this idea and whether it actually might work for us. And you know, he did.  He called Rob Sabourin and he came up with what seems to me to be Color-Aided Test Design.

Did we use it on our projects?  No.  I’m not sure why.  We got busy, I guess.  We knew the territory and rarely looked at our test plan spreadsheets anyway. Was it a failure of an idea? No, and here’s why.

About a month later, I asked Ben to give me the list of tests we ran every cycle (6 weeks), then the list we should place emphasis on when we’re 3 – 5 days out from ship, then the list of tests we run every day, then the tests we run on every build, then the final Gold tests on ship day. He came back with an idea — a pyramid representation of those tests — and — he color-coded it. 

The 6-week tests were the base, colored in Sapphire; the 3 – 5 day tests were the next level up in Emerald, the one-day tests were a layer above that in Ruby, the tests we did every build were over that in Gray (known as the BVT), and the apex was gold for the tests we did with Gold bits — the release checklist.  To me, this was the keeper idea, and I used it all the time when talking to management about where we were.  It wasn’t long before all I had to do was speak about which color we were in.

—–

Idea #2: I used to manage by walking around to my staff’s cubicles and checking in every now and then. But I noticed some of them sighing when I’d do that, as if to say, “Hey, don’t bother me.”  Even though they said it was ok, I thought there could be a better way.  Then an idea came to me — index cards.  Maybe if each of them took a stack of index cards and wrote their to-do items on each and posted them in their cube, I could walk by without saying a word.  I would know their status by way of a personal kanban.  

The idea worked.  People did a good job of keeping their work items up-to-date in columns for me to see when I came by.  But the thing was, they’d still want to *talk* about it. 

Then again, when they weren’t in their cubes, I could still see their progress.  Micromanaging, perhaps, but at least not as annoying.

That is, until the first snowstorm hit, literally. In late December 2008, we got a foot of snow, and ice to make it tricky to get to work.  Many people didn’t come in to work, including me.  We all could still work from home, but in a few hours, that personal index card kanban would be obsolete.

#FAIL, right?

Not really.  What I needed was something electronic, someone web-based.  Electronic, web-based index cards!  That’s it.  Then it hit me. 

Duh… another group I managed used ScrumWorks Pro to manage their workflow.  That’s what SWP basically is!  Why the hell wasn’t I using it on the project whose team I asked to use index cards on their cubes to report status?!?

When the weather got better and we got back to work, I went about telling my staff that I wanted to try a pilot project with SWP.  I wasn’t laying down a doctrine, just an idea.  Let’s try to get some ScrumWorks Pro licenses for a week and see how this thing shakes out.  Mythbuster Adam Savage is one of my heroes, known for saying “Failure is *always* an option” and I wanted to consider that.  Besides, better to allow a culture to integrate something new than to force that culture to adopt it.  History is full of lessons there.

But it worked.  The pilot program showed that people found value in it, so we extended it another week.  By week 3, it was part of our toolset.  People reported status by saying, “check the burndown in SWP” and they included screenshots in their status reports for me.

—–

Idea #3: There was a projector in one of the conference rooms that had a burned out bulb.  The thing was it couldn’t be removed because it was chained to the desk with a lock and no one knew the combination.  Not even the admin knew.  Still, another projector was brought in and the old one shoved aside as best as could be. 

This annoyed me.  Here was waste, just sitting here on the desk, a blaring reminder of bad form — someone forgot the combo and this thing would take weeks to be sorted out, if ever.  No one cared because no one thought anything could be done.  So during a slow meeting, I started hacking the lock.  It was only 4 digits.  I figured it might take me several long meetings in a row to run 9999 combinations, because I was testing about one per second.

Testing.  This was a testing problem!  What I was really doing was reproducing one bug, right?  The combination!  So the test/explorer in me kicked in.  What heuristics can I use?  The number of the conference room as the combination? The admin’s birthday? The number of our street address? Why try all 9999 when all I needed was a smart risk-based strategy?

But no, it wasn’t that easy. Even when getting others’ opinions on what the combo was, it didn’t budge.  But there I was, fiddling anyway.  I tried an OFAT test — One Factor At a Time. Instead of counting up, I started at 5555 and tried 5655, 5675, 5678, and drew a little diagram where I would use a V model, counting up then counting down in the 5000s by changing one number. 

At 5235, it popped open.

But even though I could describe my approach, and it worked, it was still heuristic.  It was still fallible.  Still, the important discovery I made, despite being flush with success (and a small celebrity for my accomplishment) I decided it was a worthy testing game. 

The next day, I came to work with a combination lock of 4 digits and invited my testers to try ideas to crack it, noting each of their ideas in a notebook for them so they could try things very quickly.  I was their log file, basically.  And it was fun, and revealing.  Everybody tried 0000, 1234, 1111, 2222, 3333, etc.  They seemed the easiest tests with the littlest cost of remembering.

To get clues, some asked me what my birthday was or what my cube # was.  That was fair game.  “Yep,” I said… “I thought of those too with the projector lock.”  But they also offered things I didn’t think of, like whether the combo was on a little slip of paper in the box it came in; comparing it to another new lock from the same rack at the same store; and determining the combination by feeling the way the tumblers rolled, listening with their ear to the lock for any clues as to what digits may be “looser” than others. 

The anchoring idea here was the creation of a portable tester game that sought to test critical thinking skills in a low pressure way.  The next day, someone brought in a 5-digit lock, but instead of numbers, the digits were letters, and you could program it to be anything you wanted, if you knew the secret trick.  Cool idea.

—–

Not all ideas might work — that is, not all will meet expectations to the degree you need them to.  But I find that many half-baked ideas are worth baking. They can lead to what my brother calls “learning cascades” — a series of discoveries made by following curiosities that lead you to the next big idea.

I’ll close with this:  My title at Quardev is “Manager for Corporate Intellect”. 

It was my idea.  I made it up. 

I knew that if we’re going to sell testing services, technical writing services, consulting, and training, that our success in these four categories would be based on the power of our ideas — our intellect. 

I bet the same is true for you.

For what it’s worth, I don’t think enough of us are talking about our half-baked ideas, especially our failed ones, so “Half-baked Ideas” has been the subject of my last few conference talks.

I look forward to hearing yours!

I’m back.

At the behest of a colleague named Lanette Creamer (a fantastic blogger worth following), I just went ahead and decided to just get busy, just get over myself, and just post an entry. 

A few things went through my mind as to what to say after such a lapse, but the ideas seemed shallow — pet peeves, annoyances, ramblings, diary stuff.  Nothing worthy.

Then I thought of Lanette’s reliable, refreshing honesty and openness in her blog, and the idea came out of nowhere. 

An apology. 

To testers in India.

And here’s why…

For years, I put you in a box and closed the lid.  I labeled it “Indian Testers” and shelved it, thinking I knew everything I needed to know about you.  It was easy to do this.  For years when I worked for a local (Seattle) test lab, you were a competitor. I believed what others said about you because it made it easier to believe that the lab could compete with your testing companies despite being lower cost.  Even though I left the lab last year for a bigger company with more challenges for me, I found out a few months later that you were replacing me and most of my staff, taking jobs away from my country when we most needed them.

Nevermind that it was not your fault, nor that the few Indian testers I had worked with in my 15 years of testing were pretty good.  I dismissed that as an anomaly.  Besides, those testers lived and worked in the United States.  I considered them “American”, and let that other folklore rule my perceptions about testers who still lived in India. 

Folklore said you had no passion or skill or curiosity or personality.  Everywhere I went, people agreed.  They said you were too compliant. You appeared to do only what you were told, and you always seemed to agree and understand, nodding your head and saying “yes, certainly sir.”  You only wanted the software to work (not to fail) and your shallow tests only confirmed that.

So like the others, I tended to see you as commodities and machines.  You were only good for running easy conformance tests that required no skill — good for tests that no one else wanted to do. I would see short, strange emails from you that said “Kindly send me a sample test plan for the testing, please.”

This was more evidence for me that Indian testers didn’t think outside the box or have much imagination. They were not critical thinkers. They stuck to the test procedure, even if it was badly written. They wrote bad procedures themselves. They didn’t ask questions. They didn’t take initiative. They said yes to everything and rarely lived up to promises. While very polite, they had the “no problem” syndrome. They did not push back when something was difficult, or impossible.

In May when I last wrote a blog in this space, the company I worked for announced layoffs and told us that we had to train our replacements for the next few months.  In that time, the new Indian staff would have to be as good as we were even though most of my staff had many years of experience with the product. 

As a trainer, manager, and coach, I had fun teaching technical skill and product domain knowledge. But what I CAN’T train is curiosity.  I cannot train someone to have a hunger to learn and discover and explore.  Either they have it or they don’t. After all, remember that the folklore told me that companies who went to India to outsource their testing were coming back because of the poor quality. The trend even had a name — “backshoring.”

When I was told about the layoff and told I had a few months to train my 3 teams before our exit from the company, I knew the transition was not going to go well.  The Indian replacements would surely fail, and my career would go down with them, I was sure.  It was not a good time to be a test manager. There had to be a way, but I couldn’t think of anything.  Maybe by being a son-of-a-bitch boss, I could take these Indian folks and scare them into being good testers.  It was against my nature to do that, but I had no choice.  I didn’t know how else I could turn people who didn’t want to learn into those that did.

A month after the layoff announcement, I was right.  The transition classes for one of my teams’ projects had started, and the Indian testers were mechanical and uninspired.  They asked few if any questions despite the product being complicated. When asked if they had questions, they said no. It was going badly, right on schedule, just as I had predicted, just as the folklore said it would.

Just before the transition classes were about to start for another of my project teams (the biggest and most complicated), I learned about a class available for whoever on the team wanted to go.  It was called “Doing Business in India”, taught by an outside firm.  I was too depressed and burned out from training the previous day to do any real work, anyway, so I figured I go to the class and have an onsite “vacation day.”  The class would surely be full of boring, useless platitudes – a great place to escape for awhile. It was a free day away from the rigors of transition of our work to India, at a time when my great staff would soon be out of a job.

I felt like a problem child in that class.  I sat in the back row and defied the guy to teach me anything. This wasn’t like me at all, but on this subject, I thought I knew what I needed to know about Indian testers. 

But he did a strange thing.  He did not talk about platitudes.  He explained that he had been a cultural anthropologist, having lived and worked in India for 25 years.  He talked about why the generalities and perceptions of Indians were so pervasive. He validated my perceptions, talked about their history and why they seemed to be so complicit.

I went up to him at a break and told him more about my perceptions (listed above).  I eventually said “Listen, I just want one thing from this class: tell me the key to unlock their souls.”  I smiled when I said it, but he seemed to know that I wanted his help to break through the veneer of their politeness and complicity to expose if they had real personalities and talent like the few “American-Indian” testers I had worked with.

I was being glib, but he answered me plainly.

 “Such a key does exist, Jon,” he said with a serious look.  Then he looked away. “I’ll mention that when we reconvene.”

And true to his promise, when class reconvened, he said: “If American-cultured testers are 80% business and 20% personal, flip it when working with Indian testers.  Focus a LOT more on the personal than you ever thought you could stand. You’ll get the productivity you want.”

He was talking right to me.  He almost dared me to try it. 

So in defiance, I did.

When transition started for that bigger, more complex product – ushering in a new group of Indian testers — I took them team to lunch.  It was July 3, the day before Independence Day. I asked them about Indian independence. The talk quickly turned to ideas of freedom and culture and … well, marriage. After all, weren’t all marriages arranged over there? How could that be freedom?

Even though one of them was from an arranged marriage, another was from what they called a “love” marriage. That surprised me. I asked each of them to tell me more about that.  The one in the arranged marriage said “You grow to love them.” Being married for 10 years, I had to admit that I understood that.  There are things about my wife that I have grown to love over the years, even though it did not start out that way.

He later said that his wife was joining him the next day, and what he said next surprised me. 

“From what you said about your Independence Day in the United States, when my wife arrives tomorrow, it will not be Independence Day for me.”

I didn’t understand at first, but then he smiled.  Ah, a joke! 

As a married man, I got it.  And right there, I had my first success.  I saw a personality under the veneer, and I liked him right away.

The next day I went to my other team, the one I was not having much success with.  I decided I would start over.  I gave one of them a task.  I agreed to learn something I thought he might be interested in – cricket – in return for him learning our product – a database for attorneys and other legal professionals to store and review legal documents.  I made him a deal: build me a database (using our product) of documents about cricket.  He learns the product, I learn about cricket – same database. He said yes and that it was a fine idea and smiled. 

I asked the other tester to do the same.  He reacted flatly.  Then I caught myself. 

Ummm, maybe not ALL Indian testers like cricket…! 

So I asked him. “That is, if you’re interested in cricket.”

He said he was not, but that he would do it anyway. As I walked away with the first guy (the one who complied), I said “I guess I blew it there.  I should not assume everyone likes cricket.” 

“Oh no,” he replied. “Anir loves cricket.  He was messing with you.”

I couldn’t believe it.  That little event was yet another key turned in a lock, showing me promise of a personality and productivity, and it happened in an instant.

That little idea started a chain of other small ideas. 

I had a room full of Indian testers who had just flew in the day before. It was 8:00 am in a new time zone. It was hard for *me* to get up early, much less think about flying across the world the day before.

So I put a 3 ft x 3 ft map of India on the wall so they could each tell me where they were from.  As the pushpins were going in, a magical thing happened.  I realized India was a BIG country. Next to it, I put a map of Washington. Then it dawned on me – most of Washington they would never see. Yakima, Wenatchee, Bellingham, Long Beach, Spokane, Moses Lake, Orcas Island, Mt. St. Helens. Politically, Washington is mostly a “red” state, mostly Republican. The Seattle population, however, skews it so that Washington is almost always considered a “blue” state (Democrat) in national elections.  They wouldn’t know that.

Then I thought of Seattle. There are parts of Seattle that are wealthier than others, that have different value systems.  Capitol Hill tends to be liberal. Beacon Hill is conservative, and they are a mere 3 miles from each other.

It stands to reason then, I thought as I looked at the map, that India must be the same way. Maybe a tester from the south is not the same as a tester from the north. Tamil Nadu in the southeast is conservative.  Coimbatore is less so. Maybe this collection of people and their personalities would come out in different ways, but maybe the key toward getting them to show that to me was the same – make it personal.

The next day in a training class I was hosting for them, I brought up Google Maps and projected it on the wall.  I zoomed in on Coimbatore where they were from and asked each to show me on what street they lived. That way, maybe they’d be less homesick, and I’d learn about their city. No testing got done in that two-hour session.  No training got done. Nothing business, nothing productive, nothing measurable.  But all personal.

What really got done in that session was me getting over myself.  I was building a team, accidentally, on purpose, and I was seeing smiles and jokes, and shyness fading.  The next session when we got into learning the product, the jokes carried forth – not always by me.  I set the tone that it was ok, and they slowly followed suit.  It began to be fun.

At the next session, the walls melted a bit more and we played one of the testing-thinking games me and my brother are famous for.

A week of this, and none of them were machines.  They were people just like me, just like my existing teams that were being replaced. 

I saw them thinking more and more above and beyond my expectations.  They were hungry and wanted to learn more.  While still polite, the veneer dropped despite the jet lag and the homesickness.  They learned on their own, as a team, after business hours.  They took pictures of me with them, shared their family pictures with me, shared the pictures they took when they explored Seattle that past weekend.  They went places (in MY city) that even I hadn’t gone yet.

 We got down to business, but it was personal.  That was the key.  They dove into their feature assignments just like my team did.  They loved exploring, were not shy, talked over each other, even gaggled like kindergarteners eager to show each other as if it was show-and-tell time.  It was amazing, and it was as easy as a key being turned in a lock, just like the instructor said would happen.

And, you know, I suddenly realized that I was the same manager I was with my existing staff. This was me, my style.  This is what I had done with my staff well before the Indians came in to be trained. The only difference was my perception that Indian testers were not as capable as my staff.  For that, I was just plain wrong.

So, India, consider me schooled.  I have some keys now that I didn’t have before and my perception is different.  Like a good tester, I ran a different set of tests on you that revealed new data well beyond the folklore. 

Still, let this be my apology.

I found a bug in the term “laid-off.”  It’s not binary or Boolean like I thought.

I was notified on May 8 that my job at LexisNexis is being cut.   I just started there last August, so it’s a bummer.  But the good news is, it’s not effective until October.

No doubt that I am a statistic, I’m just not sure what slice of the employed / laid-off pie chart I am in now.  Maybe there’s a “laid-off-but-still-employed” piece?

I’m also in a rare category because I saw it coming the day I was hired and I decided to chance it anyway.  HR did a great job of preparing us all for the news — we knew it would be a possibility, but none of us were sure what the real impact would be.  A lot of people were thinking: “Which is worse? Knowing that an asteroid is coming but you’re not sure when, or living in blissful ignorance until you learn an asteroid has suddenly hit?”

My take on it was to stay cool.  After all, maybe when the asteroid impacted, it would be the size of a grain of sand.

But the asteroid hit and it was noticeable.  Maybe the size of a two-pound rock? 

Covered in the ejecta blanket, my crew and I set our sights on how to take on our new role — training our Indian replacements for the next few weeks.  My staff has been well-behaved and professional so far, but it’s starting to sink in that we will not be around when this is over.

Range of emotions is now yielding to acceptance.  After all, every job I’ve ever had I’ve got by coincidence or happy accident — something I can’t predict or control.  All I can do is maximize the chance for it to happen — submit the resumes, fire up LinkedIn, send some emails, find out what I really want to do next, talk to people I trust who support and know me, update my blog…  🙂 

The economy is the economy.  I can’t control that either.  I CAN control my fear about it by examining what it is I’m afraid of, and the more I think about it, every time I’ve been afraid it was out of fear of being powerless, helpess, afraid.  And I finally get it — we have nothing to fear but fear itself.  Easy to say, harder to practice.  It helps when you have no choice.  Practice it, else be afraid.  I also now understand the maxim: Feel the fear and do it anyway.

In 1996, I quit my first job at Microsoft because I fell in love online to a girl in Virginia.  They told me at work that would be a bad move.  *No one* quits Microsot for such a reason.  “People leave girlfriends to *come* to Microsoft,” they said.  “Go home and watch Oprah and get over it,” they said.  “It won’t work out,” they said.  “Internet relationships don’t work in person.”  They told me I would never work at Microsoft again.

I felt torn apart.  My mind here, my heart there.  My brother James said I would crack if I didn’t follow my heart, and I believed him.  So I left for Richmond.  I quit and left.

But before I did, I started writing myself reminders — notes to myself to help me cope when the fear overcame me.

* Breathe

* Don’t swing at the pitch until it’s right in front of you

* What’s the worst that can happen?

* What would James / Rob / Dad / someone-I-respect do in this situation?

* Maybe you are on an adventure that will be a useful experience later on

* Check your expectations — maybe they are too high or you are too tough on yourself

* Someone will want what you have to offer

All of these worked for awhile, but it got lost in the shuffle when my girlfriend had an affair two months after I got there. 

So they were right.  It didn’t work out.  The “Survival Guide” was meaningless.

A year later, I came back to Seattle from Virginia, assuming that I would not be able to get a job at Microsoft, or anywhere because of the impulsiveness I showed in quitting. 

Wrong.  Microsoft (through Volt) hired me back.  My old *group* even wanted me back. I couldn’t understand that after all they said to me.

So here I am in 2009 — 13 years later, full of the same fear about what the future holds for me.  Why the amnesia at all the Universe has done for me in the past?  Why the lack of faith that it will give me something cool to do next?  Because maybe it was a fluke…

No, no, no… time to read that old guide and to add to it — to remember all of the cool things — coincidences — that have happened to me since then that have  given me opportunities to get better and better.

If you’ve been laid off, that’s my only piece of advice — that is, until I get a more recent unbelievable coincidence to make the Power of Coincidence more believeable.

Note: In the year 1999, I met another woman online — while at my desk after hours at Microsoft.  I followed my heart, we met that night in Seattle, we married a year later, and have been married ever since .  (They were wrong, Internet relationships do work in person.)

I’ve attended a lot of testing talks over the years and there are three things I’ve heard that really bug me.  If any of these statements are in your slides for your next talk, let me try to compel you to get rid of them because they may distract testers like me enough to cause us to tune out:

1) “Insanity is doing the same thing over and over and expecting a different result.”

Einstein allegedly said this and it’s used a lot by speakers who want to decry what appear to be silly pathologies of project management. 

But wait a second.  Let me summon you testers out there to help me examine this.

Have you ever done the same thing over and over, expected a different result and felt *more* sane because of it?

Have you ever done a series of key presses (like a “slot machine” test) and expected to uncover a possible buffer overflow any second?  Press Enter <no change>, Press Enter <no change>, Press Enter <no change>, Press Enter <BANG!>.  You’re expecting that BANG after many trials of doing the same thing.

This is insanity?  No more insane than people who exercise the same way every day and expect to get thinner than they were the day before.  No more insane than a fisherman’s wife looking hopefully out to the ocean every day to see the mast of her husband’s ship on the horizon.

Lesson:  Things change despite our routines.  In fact, it is our routines that catch new behavior from a system that changes underneath and around us.  Like a Build Verification Test is meant to be the same thing over and over, hoping to catch the new code doing something it shouldn’t today, routine can help us find bugs. 

Let me flip it around… it is a SANE thing to do something over and over and expect a different result. 

2) “The longer you wait to fix a bug, the more costly it is.”

I’ve had three experiences in my career where the opposite has been true.  Here’s one of them:

I worked on a project whose developer had a bug assigned and open to him for 183 days without any status other than “Yeah, I know about it, but will not be an easy fix …”  The pressure mounted week after week, and a few days after his latest one-line status report, the bug was fixed.

There was celebration in the triage committee.  After 190 days, it was closed at last! But people were dying to know, how did he do it?  Well it just so happened that the best outlook of a fix came in an recently released SDK.  He used an API that fixed the problem and the implementation took 30 minutes.  If he had jumped right on the bug the day it was opened and spent weeks fixing it, all of that time would have gone to waste. 

Lesson: Sometimes procrastination pays off.  Projects get cancelled, schedules get flipped, priorities get rearranged — all of this can result in re-work and wasted time.  Not always, but neither is it always the case where the sooner you find and fix a bug, the cheaper it is to fix. 

3) “When you “assume”, you make an “ass” out of “u” and “me”.

Do you know how many assumptions we make in one hour?  It has to be thousands!  I assume the sun will go down today, I assume I will still have a job in the next 60 seconds, I assume there will be livable oxygen to breathe by the time this sentence is written… 

I do not question these and I am not an ass because of it — and neither are “u”.

If we questioned every assumption, we’d go insane — or at least sound insane.

Like this:

“I assume that you are reading this sentence.  I assume you know that I am a human and that you do not think this sentence was generated by an electronic algorithm. Assuming that, let me now assume that you will allow me to make this next remark in these words that you are choosing to read of your own free will and volition and let me assume that I may have to define “volition” for some of you which I will do now, assuming that you care about such things…”

Lesson: I think the spirit behind the “ass out of u and me” remark can be restated like this:

“If we don’t examine the consequences of some assumptions, we run the risk of looking foolish and losing credibility in our community.” 

But which assumptions should be questioned?  

I don’t know, but I do have a triggering heuristic that helps me.  Whenever I’ve been stuck or frustrated or bored or confused or mad or off-center in some way, I’ve learned that those are good times to question assumptions.

I’ll try to list a few assumptions I have as I test and question one them before my next test and see what happens. 

I ran into a bug in a tool my brother and I wrote — a crazy bug since the tool had worked for years the same way and one day it stopped working.  I spent 3 hours investigating the problem.  No luck.  Somehow the tool just got corrupted.  I took a break and came back.  A heavy sigh later, I started at square one, questioning every step.  And there it was. 

I assumed I had Perl installed. 

No, I could have SWORN I had Perl installed.  I remembered installing it the night before.  But it turns out I had just downloaded it and never ran the EXE.  I never thought to question my memory.  Maybe that’s why a few times over the years when testing, I see the error dialog “This bug should never happen.” — a note put in by programmers who perhaps have made those kinds of simple assumptions and have felt the consequences of not questioning some of them.

So, if you’re going to use aphorisms like these in a testing talk, test them first.  I’m not annoyed at people who use these in their slides as much as I am annoyed at the people who nod and even laugh when the speaker says them.

Ugh.  C’mon, everyone, we’re testers!  I’m not suggesting we test *every little thing* that’s said at a talk, but whenever the speaker is trying to provoke or persuade you, it should be a trigger for you to learn why it is you are provoked or persuaded and to test the premise of the remark. 

Maybe all it takes to help with this is awareness — which they say is “half the battle.”

(pause)

(pause)

(pause)

Are you thinking “Well, Jon, what’s the *other* half of the battle?” and “Who is the *they* you’re referring to?” and “What does ‘half of a battle’ look like anyway?”

Cool.  Then I don’t have to say another word…

Just got back from the STAR West conference, where I was lucky enough to have been chosen to do a keynote.  As often happens when I do testing talks, I got an epiphany the night before — an anchoring idea to frame my talk and make it more memorable.

The conference was at the Disneyland Hotel.  They have their own series of TV channels there, one of which is the Fireworks Music Channel (channel 47 if you stay at the hotel).  I noticed this when flipping around the channels trying to find one of the many Disney stations so that my 2-year-old daughter Charlotte could get in some Mickey Mouse time before she met him in person.

I happened upon channel 47, which was a static image of the Magic Kingdom with a black background, with Disney soundtrack music playing softly.  That was it.  All day, all night, music playing softly with an image of the Magic Kingdom — perhaps for weary parents or children who need to wind down from being over-stimulated by rides and sugar.

Handy to know, but we had just arrived, so little Charlotte was ready to wind up, not wind down.

We found a channel with the Mickey Mouse Club and she was happy.

The next morning, Sunday morning, was quiet, and with Charlotte still asleep in the bed next to mine with my wife, I wanted to start my day quietly — no news, no Mickey Mouse Club, just quiet music.   I remembered Channel 47.

I flipped to it and saw this:

Nice!  Finding bugs is my business, but sometimes they find *me*.

I took a picture of the error to use in a testing class one day.

The next day, I was flipping through the channels, and saw this:

The story had unfolded a bit — two error dialogs which appear to say the same thing: “<unintelligble path” is not a valid win32 application” and I noticed the menu bar at the bottom with the system tray.  It was PowerPoint that was failing.

The next day:

That’s right… 3 error dialogs.  One per day?  Clearly, no one at the hotel is looking at this.

The next day was my keynote, titled “Telling Your Exploratory Story” and I knew I had my hook — a way to anchor my talk about how to describe the flow of thinking when there’s no test script to follow.  I would use this as an example that sometimes details slowly reveal themselves, and it’s the thinking about the new, emerging context (and how you react to it) that really underscores the art and craft of exploratory testing — telling your story of the dynamic things that happened in your testing and what you did about it.

Thinking that it was a date-driven bug — perhaps midnight being the trigger — I checked channel 47 one more time before going to bed just after midnight on Day 4.

I saw this:

Cool.  Four dialogs, four days.

The day of my keynote, I told the front desk.  After some trouble explaining that it was not my TV or my laptop, (and no, a technician does not need to be sent to my room) I felt that I had done my civic duty as a tester — reporting a problem in such a way that it had a likelihood of getting fixed.

I added the pictures to my keynote slides and kicked off my talk with them, saying that sometimes a bug story unfolds without us having to do anything but collect context.  It enhanced my talk, I think — got some good laughs and made my point.

A good keynote sets the tone for the conference — grounds the attendees to a meaningful social meme.  And sure enough, for the rest of the week, I had evidence that my talk did exactly that.  People came up to me the next day and asked me what was happening with Channel 47.  I told them it was fixed because I did not see any dialogs that next day.

But someone came up to me the day after that and said they saw the error return.  I checked and confirmed it.  One error dialog. But later that evening, well before midnight, there were two dialogs, blowing my theory that midnight was the driving event.

I mentioned this at a separate talk I was doing the next day.  Someone in the audience pointed out there is also a Disney site in Florida, not just California, and if the channel was hosted at Disney World in Orlando, it would be three hours ahead, meaning that it still could be driven by midnight!

But it was the final day of the conference that was the critical incident for me.  I was in the front row of Rob Sabourin‘s talk titled “Toward an Exploratory Testing Culture.”  He talked about ways testers could find things in common like how to add value to a project, how to be a bug advocate, how to represent their work in credible ways.  He invited discussion from the audience of about 250 people.  And then it hit me.  I had a two-word comment that to me, was an iconic example of an exploratory testing culture — something that grounded us that week, bonded the attendees into a common story, that got people out of their boxes and shells and compartments for just a little while to think about one common, curious, critical problem.

Channel 47.

“What’s going on with Channel 47 today, Jon?”

“I didn’t see the error today, Jon.  Did you?”

“I can’t get Channel 47 at all here at the hotel, I called the front desk to see what the deal was.”

“What do you think the invalid win32 application is, Jon?”

“I saw something similar in the hotel elevator — it appeared to be a digital test pattern underneath the floor indicator.”

“I like that theory that the server is based in Florida.”

“Why do you think the title bar doesn’t show until day two of the problem?”

It was these comments that made me feel connected to everyone else at the conference.  I was the just vehicle for the culture, which, like the bugs that exist in the software that’s delivered to us, was already there, waiting to be discovered.