Home » True Stories
Category Archives: True Stories
I’m not stupid. But sometimes I feel like a complete moron. Usually it is something to do with a tool download that humbles me. I have been using Fitnesse for years and I really thought I knew what I was doing. Luckily I have had really good developer support to do the heavy lifting. So I got a little cocky and signed up to do a couple of presentations on Fitnesse at the local software testing conference. I wanted to demonstrate a simple test using the fixtures in the Fixture Gallery. Sounds pretty simple right – cue the brick wall.
So I scour the web and the Fitnesse.org site for simple easy instructions. I find the fixture gallery zip file, download it, and unzip it. It seems to include a completely new installation of Fitnesse. I’m confused – let’s consult the documentation. Well I would if I could find any – i can’t!
Maybe there are books available? Nope! Well there are, sorta, but I’ll save that for another post.
I’m not giving up. Once I get this solved I’m going to write the Idiot’s Guide to Using Fitnesse.
If anyone can help and walk me through this, please contact me at firstname.lastname@example.org.
I just found out that the company that I was contracting for is looking for 3 contract testers on my old team. I absolutely loved it there, loved the project, loved the company, etc. The open positions are apparently to replace me – the exact same job I spent almost 2 years building – using a test architecture that I built from the ground up. I could be immediately productive. Literally hit the ground running. You’d think I’d be a shoe-in to return. Think again! I just heard that I’m basically not qualified to be me and that I won’t be considered for the open positions. Needless to say, I’m livid. Have you met me? I’m a Golden Test God!…lol. Oh well. No need to dwell on it. It’s their loss! As Jimmy Buffett says – “Breathe In, Breathe Out, Move On”!
I recently worked on a project that was off-shored. For the most part things ran pretty smoothly but there were a number of issues that were insanely simple (from my perspective) yet became overly complex over time. The primary cause, I believe, was cultural differences between testers here in the U.S. and the off-shore development group. Three simple things that took weeks to resolve: currency formats, sorting of dates, and phone number formats. I know what you’re thinking. How complicated can it be. Trust me, I lost a lot of hair over these three seemingly simple concepts.
The first one had to do with formatting U.S. currency values – specifically negative values. The application dealt with currency values on a number of pages. The customer was a U.S. state, so nothing other than U.S. currency values was involved. There were a couple of different formats depending on the page you were looking at. Pages displayed one of two different formats for negative currency values: -$1234.56 and $-1234.56. Which is correct? Common usage will tell you the first one is correct. Unfortunately, there was no specific requirement on formatting currency. So instead we looked to Microsoft Excel for the answer. The answer was example 1: -$1234.56 (actually the default was (1234.56) but that’s another story). We asked them to change it – they did with no argument.
Second – date sorting. Again not specified in the requirements because according to the Business Analyst: “Everyone knows this.” Apparently not. So if we wanted to sort table data by date we have two options: ascending and descending. That’s where the problems started. We had different definitions of what those words meant. With alpha characters or numbers – not an issue. With dates, not so much. The requirement stated only that records would be displayed, by default, in descending order, by date. To me, that meant the most recent record first through the oldest record. When the application was delivered to test we got the opposite – oldest records first, newest records last. So I wrote it up. In the bug triage meeting there was a huge argument over the concept of ascending vs. descending. To our off-shore partners descending order by date meant oldest records first, newest records last. They had a pretty good argument. Again, Bill Gates to the rescue. ”What would Microsoft do?” We finally agreed that descending order by date meant most recent records first and oldest records last. It only took an entire afternoon to resolve it. Once again we asked for a specific requirement. We were denied because requirements shouldn’t address “common sense” issues. Whatever.
The third issue – phone number formatting – was not so easy. This time we had a requirement. Vague – but a requirement none the less. The requirement basically stated that system would display 10 digit phone numbers using a dash and pair of parentheses. Well that is exactly what we got. A phone number was displayed as (5)55-5555555. Does it meet the requirement? Absolutely! Was it a valid U.S. phone number? Not a chance. So I wrote it up. The off shore contractor fought this one for almost a week. They swore that this was correct and in accordance with the requirements. They refused to change it. We found out later that they were penalized if the defect count got too high. So we figured we would reword the requirement to be more specific. Easy fix right? Wrong? The Business Analysts fought changing it again citing the “common sense” doctrine. A week later, after a lot of arguing, the requirement was changed and the format fixed.
In looking back, I feel that this whole mess came down to a difference in culture. First of all, the off-shore vendor was a third world country and had no clue how this type of application should work, look, etc. Also, their culture does not condone “mistakes.” Defects made them “lose face” so they fought each and every defect we found. (The defect penalty in the contract didn’t help). Lastly, this was a culture that prides itself on “doing things right.” What is right? In this case the requirements defined right and wrong. It was either black or white. ”Doing the right thing,” on the other hand is a gray area. Harder to define. You know it when you see it. It’s sometimes hard to define.
The lesson learned: when dealing with other cultures, common sense may not be so common.
Time for another war story. When I was in the Air Force…..
I worked for a Wing Commander, who’s mantra was “push people”. He felt it was OK that you could make crews work overtime or work weekends etc. Of course we never pushed the aircraft. The machines were always given appropriate down time for maintenance, refueling, reloading, etc. The commander had “stars” in his eyes (in this case general’s stars). It was an accident waiting to happen. Unfortunately it did happen – taking 6 lives including a high-ranking government official. It wasn’t until the accident investigation that his “management style” was revealed and ultimately identified as a major contributing factor – crew fatigue. It took an accident investigation and the lives of 6 people for the “leadership” to see there was a problem. They could have asked me 3 months before the crash.
Sometime later I read an article on productivity. I wish I would have saved it because it has had a huge impact on me ever since. Essentially, the article stated that people can only be pushed so far before productivity begins to suffer. When you push them beyond their full capacity, you will see some short-term gains in productivity, but over the long haul productivity will decline – significantly. So if you have air crews and maintenance crews working 3, 8-hour shifts, you will see some short-term gains when going to 2, 12-hours shifts. At some point, however, things begin to break down. Maintenance gets sloppy, minor (but necessary) procedures will get over looked, and accidents happen. We saw it every time we would go into any long-term or frequent war game, or as we called them – exercise.
We used to practice going to war all the time. There would typically be one or two “exercises” a year. However in the event of a pending major inspection – the exercise schedule would be increased. Colonels become Generals based on these exercise results. So twice a year became once a month. By the time the actual inspection arrived we were exhausted. We made stupid mistakes – mostly minor – but mistakes none the less. We passed – barely. Oh – and we were responsible for handling nuclear weapons.
Back to the article. The author studied and tracked productivity as workers were stretched from full capacity to beyond full capacity. The study found that in the short-term, productivity levels did increase – slightly. Then as time went by productivity dropped dramatically to levels below full capacity. The bottom line – crews were more productive, over the long-term, if allowed to work normally. Well not more productive exactly, but productivity did not decrease. I showed the article to the new commander but he blew me off. Never confuse a military leader with facts!
In addition to the loss in productivity, there were other negative factors. The most obvious (now anyway, we didn’t see it at the time) was that personal quality evaluation (Task Evaluation) scores began to decrease. Periodically, Quality Control inspectors would watch various crew members perform their daily job tasks and complete an evaluation of their performance. When pushed beyond capacity – they made mistakes – which were ultimately reflected in the evaluation results. Maintenance crews would take short cuts, not follow instructions, read an indicator incorrectly, etc. They were tired and exhausted.
There were other indirect signs as well. Domestic violence incidents increased. Alcohol related incidents increased. There were more driving violations. Family members were getting in trouble – the list goes on.
Sadly, we’re seeing this today. Military troops are being pushed way beyond capacity and we’re seeing the results. Minimum tours have been increased from 12 to 15 months. Enlistments have been involuntarily extended. Troops may get to spend a year with their families before being deployed for another 15 months. The result: Drinking and drug use are on the rise. Domestic violence has increased. Divorce rates among troops is up. Worst of all – suicide rates for military members is at an all time high. Is it worth it?
So when you are estimating project length – keep all of this in mind. You can only push people so far. Will it be as drastic as I described…probably not. But there is a downside. You can’t push people. They will break!
Why did I become a Software Tester? It was an epiphany really.
Ever since I was a wee lad, I wanted to be a Maine fisherman. I’m actually from a small island off the coast of Maine. Well technically it’s not an island anymore since they built a road to it.
My father, born and raised on the island, would always fill me with romantic stories of growing up on the island and working on the boats. He enlisted in the Air Force after graduating from high school. He married my Mom and a year later I was born. During his 20-something year career, we moved around a lot. Typically far from Maine. We would go home every now and then for “Old Home Week” – the island’s week-long Fourth of July celebration. I followed in my Dad’s footsteps and enlisted in the Air Force right after high school. My dream, after I retired from the Air Force, was to return home to Maine and be a fisherman. Deep sea fishing.
For our “honeymoon” I took my new blushing bride home to Maine for the Forth. I remember it like it was yesterday. As we approached the “island” from the mainland, the fog was just lifting, the setting sun glowed orange off of the old white houses on the hillside (shacks really). It was picture perfect. Like a picture in a calendar. The following morning we would be on the fishing boat – I was down right giddy!
We got up really early the next morning. Even though it was July, the air was crisp and cool. Steam was gently rising off of my freshly brewed cup of coffee. There was a thick blanket of fog on the water. You could hear seagulls somewhere in the distance. It was perfect! I boarded the boat ready to experience what my future held.
Reality set in about the time the coffee ran out. The fog lifted after about an hour and it was hot and muggy. The lifting fog also released the stench of dead fish. The seagulls were starting to get annoying. They smelled the dead herring and were circling the boat looking for food. We were dodging seagull poop. The tide was out adding a special aroma to the mix. We were gagging on diesel smoke. I spent the first hour or so helping my Dad bait the novice fishermen’s hooks with dead, rotting, slimy herring. My clothes reeked. And there was still 4 hours to go!
The only thing we caught after 5 of the longest hours of my life was a squid. My new wife caught it. She didn’t really catch it. It had the misfortune of swimming by just as she was reeling in her line. She just kinda snagged its head. The girls all screamed. No one wanted to touch it. So my Dad (who I swear was the model for the Gorton’s fisherman) volunteered to unhook it. It wrapped its tentacles around his arm and used its sticky sucker-thingys to hang on to him for dear life. He eventually peeled it off and returned it to the bay. Somewhat traumatized by the ordeal, and with the exception of having once had a huge fishing hook in its head, the squid was pretty much unharmed.
After the squid ordeal, I looked up as we slowly sailed past the island. I found myself jealous of the lucky islanders in their cozy cottages up on the hill, eating a nice hot breakfast. I longed to be back in my nice soft bed, snuggled up against my new wife, or sprawled out on the couch watching television with the smell of sizzling bacon wafting through the house. I have no clue who would have been cooking it, but that’s not important right now.
I couldn’t wait to get off that stupid boat! Needless to say, that was my last fishing trip.
A week later we returned to Colorado. On the flight home I pondered my future career aspirations. Whatever I decided to do was going to be indoors, temperature controlled, and not reek of fish. I hate fish I don’t even want an aquarium! It’s been almost thirty years and I haven’t been fishing since.
So here I am – a Software Tester. I couldn’t be happier!
I had a stroke 4-1/2 years ago (minor – I’m 100% recovered) I have to go see my doctor once a month to have my blood tested to monitor my blood and hopefully prevent another stroke. They prick my finger. I bleed into this little receptical. The receptical is inserted into a hand-held blood reader thingy and -Viola – after about 5 minutes we have the results. Based on what the hand-held blood reader thingy says, my medication may or may not be adjusted. About 50% of the time the test fails – it reads high. My doctor, skeptical of the test results, has my blood drawn and sends it to the lab where the test passes everytime.
As I was sitting in the doctor’s office yesterday awaiting my test results I was pondering comments I made recently about Exploratory Testing and Agile. I started to wonder – who tested this machine and the software that runs it. If it was tested, a key test was over-looked.
The part that really scares me – if it reads “correctly” (within range), my doctor trusts the results. If it reads incorrectly (out of range) she doesn’t trust the results and does the lab work.
The tester in me is concerned. If you can’t trust the bad results, what makes you believe the good results are valid. I explained my concerns to the doctor. She gave me a perscription for Valium. Look at all the pretty colors!
Is there a risk to not adequately testing….maybe we should ask the FAA!