Vanilla Ice Cream caused General motors to not start

Vanilla Ice Cream that puzzled General motors’!!!!

An Interesting Story

Never underestimate your Clients' Complaint, no matter how funny it might seem!

This is a real story that happened between the customer of General Motors and its Customer-Care Executive. Pls read on.....

A complaint was received by the Pontiac Division of General Motors:

'This is the second time I have written to you, and I don't blame you for not answering me, because I sounded crazy, but it is a fact that we have a tradition in our family of Ice-Cream for dessert after dinner each night, but the kind of ice cream varies so, every night, after we've eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It's also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem.....

You see, every time I buy a vanilla ice-cream, when I start back from the store my car won't start. If I get any other kind of ice cream, the car starts just fine. I want you to know I'm serious about this question, no matter how silly it sounds "What is there about a Pontiac that makes it not start when I get vanilla ice cream, and easy to start whenever I get any other kind?" The Pontiac President was understandably skeptical about the letter, but sent an Engineer to check it out anyway.

The latter was surprised to be greeted by a successful, obviously well educated man in a fine neighborhood. He had arranged to meet the man just after dinner time, so the two hopped into the car and drove to the ice cream store. It was vanilla ice cream that night and, sure enough, after they came back to the car, it wouldn't start.

The Engineer returned for three more nights. The first night, they got

chocolate. The car started. The second night, he got strawberry. The car started. The third night he ordered vanilla. The car failed to start.

Now the engineer, being a logical man, refused to believe that this man's car was allergic to vanilla ice cream. He arranged, therefore, to continue his visits for as long as it took to solve the problem. And toward this end he began to take notes: He jotted down all sorts of data: time of day, type of gas uses, time to drive back and forth etc.

In a short time, he had a clue: the man took less time to buy vanilla than any other flavor. Why? The answer was in the layout of the store. Vanilla, being the most popular flavor, was in a separate case at the front of the store for quick pickup. All the other flavors were kept in the back of the store at a different counter where it took considerably longer to check out the flavor.

Now, the question for the Engineer was why the car wouldn't start when it took less time. E..ureka - Time was now the problem - not the vanilla ice cream!!!!  The engineer quickly came up with the answer: "vapor lock".

It was happening every night; but the extra time taken to get the other flavors allowed the engine to cool down sufficiently to start. When the man got vanilla, the engine was still too hot for the vapor lock to dissipate.

Even crazy looking problems are sometimes real and all problems seem to be simple only when we find the solution, with cool thinking.

My sister shared this story on WhatsApp. I do not know the source of this story.

But it does remind me of the time, when one of my applications started throwing error even when using a valid account number. It turns out the Account type was not the issues, when the account was created was not the problem. The number of digits in the account number was the problem!!

Bugs you see Bugs you don't

The sight of fruit flies swarming over fruit is gross. the first thought that comes to the mind is get rid of the flies.

The sight of a burger with fries is mouth watering. The first though that comes to the mind is eat it. It looks good, it looks good even after a few months. No mold, no flies, and it is finger yummy.

Let's take a closer look. The fruit is organic and yummy. Of course the bugs want a piece of

something good. The organic fruit is not long lasting, it decays pretty fast.

The burger and its ingredients are over processed (probably with chemicals) to last a very long time and to withstand transportation and taste the same no matter where in the country (sorry world) it is made.

We view bugs as a bad thing. Too many bugs as a very bad thing. We are brainwashed to viewing bugs as a bad thing. If the product worked right, it should not have any bugs. But all bugs are not equal. Most are easy to fix (like a CSS alignment are harmless), especially the ones that are easy to spot with eyes wide shut.

But what about the bugs that are introduced unwittingly as features? There are features that cause serious issues relating to user experience (financial/ physical health) and security. They are not obvious on the first sight, they in fact look very good on paper. They do not cause damage on first use, they damage the insides slowly while a whole team stands by defending it.

Back Story - On one of the products  I worked on - I once came across a bug, where when I entered the wrong password for the username, the login page threw an error message but when I opened a new tab of the same homepage, it logged me in too. When I logged the bug, I was told, that - it is the result of the new re-arch (which authenticated the user based on the email address alone, something else, blah blah ) and hence the ticket was closed with the justification of  - "By Design"as well as the usual - "our users won't open a new tab".

• It takes a special team to identify the real issue and take responsibility.
• It takes a special kind of developer to offer an effective solution.
• It takes a special kind of problem solving to not have a knee jerk reaction to fix something in a way that makes it fundamentally wrong.
• But mostly importantly, it takes common sense to find issue like this. (Trust me, the web is full of such bugs)

Tell me about crazy bugs you have encountered that were by design (cough bad design)

Tester vs Acceptance Criteria Checker

Tester	Acceptance Criteria Checker
Requirements
A tester knows that even if the product meets the requirement to the T, the product could totally suck. So, they do not rely too much on the requirement to measure product quality.	A checker is heavily reliant on showing the acceptance criteria is met. They won’t go into testing without a document.
Test Cases
A tester writes product based test cases. They ensure test case longevity with data set up and tear down info for fast execution	A checker checks the acceptance criteria. They do not know they need to plan for the future, they focus on the bare minimum.
BUGS
A tester works to find issues that wont show on the surface	A checker works to find issues inside and within the acceptance criteria.
Purpose
A tester explores the product and understands what it does and how is does it.	A checker checks the surface and within the boundaries of the requirements.
Focus
A tester contributes to making a product better	A checker tries to find where the product is broken
Product vs Project
A testers job never ends. A tester feels responsible to support the product through its life	A checkers job ends with the project
Test Data
A tester works to create, edit and maintain the data required for testing	A checker is dependent on the developer or the business to provide the data
Ex – Sign Off
A tester relies on product and architecture knowledge to understand the state and stability of the product and little on the regression tests	A checker relied on the PASS and FAIL test results.
Ex – Superman vs Clark Kent
A tester will go deep into what superman is all about, who are his parents, what is his real identify and all that jazz. They understand that Clark Kent and superman are the same person so focusing on clothes is literally scratching the surface.	A checker will only observe that obvious differences of the superman costume. Clark Kent – wears his underwear inside Super man – wears his underwear outside
Ex – Menus or drop-down lists options
A Tester will explore where this data is stored (in the database or hard coded into UI)	A checker will make sure the list of items shows up as listed in the requirements.
Ex - Authentication of the user
A Tester will find out where the registered user information is saved and make sure the passwords are salted too. A tester will also find out how the user session is authenticated and terminated in the browser	A checker will make sure the registered user is authenticated with valid credentials.

Can SCRUM save Shark projects

I just watched a movie called Shark Exorcist (It is a real movie, someone wrote a story and spent money on making it - http://www.imdb.com/title/tt3120314/). I was thinking about what could have made the movie better since a team of people worked on it, they must have had hopes for it. I mean when we make dinner, we want it to be really tasty! When we put on makeup, we want to look pretty! So, what could have been done to make this movie better?

Answer: Obviously, Not make the movie at all. 

I got to thinking - if the makers used the waterfall methodology to make this movie they may not have had a chance to look at the whole product till the very end, so they may not have known about the lameness of the movie. If they had used SCRUM methodology in the movie making, they might have realized they were just wasting money and might have scraped the project in its initial stages and my 5 minutes would have been used on another terrible shark movie. (watched in Fast Forward)

But is that how SCRUM teams work in real life?

I have personally never worked on a SCRUM team where a project was scraped off because the vision was so terrible (although SCRUM implies that you can catch issues early on). Because let’s face it, if the team actively acknowledged the vision was poor suggested to scrape the project, their jobs would be at stake. We will have less job security. 

So, we silently groom, point, develop, code review, test, release and do tasks without challenging the vision.

I have worked on SCRUM projects where all my team mates and I trusted each other (that takes time and bad ass people to self align themselves), and pushed back features and changed features drastically to make the product better or less defective. But that did not happen just by calling a methodology SCRUM. We were really a team and we were focused on the product not just what the business wanted.

For a project to be noteworthy or successful the vision is the most important thing. So, do not get hung up on methodology or its certification (I too spent money on the certification). Because the methodology does not make a project successful on its own. It is the people and their insight into the project that makes a great product and successful project.

Diapers and User Stories

Once upon a time disposable diapers just were invented for people as a substitute to washable

diapers. They added convenience for unplanned outings and emergencies. But when they were understood as the norm and taken for granted, the result was more landfills occupied with junk that takes more than 500 years to decompose.

Advantage – anyone could take care of the child and people were not tied to the child.

Disadvantage – babies who used to be potty-trained by 18 months take 36 + months now.

Once upon a time user stories were suggested in agile methodology for unplanned needs about which much was unclear but there was a need, an unplanned need, but a valid need. This enabled anyone to be able to write requirements and put them through the backlog. But when they were understood by the upper management as norm and taken for granted, the result is lots of user stories (most of them poorly written) that look the same and take longer to understand and implement and result in half-baked products that constantly break other logic.

Advantage - the business teams can pile up on wants with user stories in bits and pieces.

Disadvantages – Art of writing fully vetted technical requirements is forgotten leaving a lot to be improvised by the developer on the fly.

Diapers and User stories were meant for good purposes, but misuse and overuse made kids and IT inefficient. They both deal with a lot of Shit!!

Badass, Bad, Ass

Badass people do not need introduction. They are awesome by default. They are passionate in their
jobs. They know themselves. They respect others. They see potential. They see possibilities. They do not stick to sameness unless the sameness is also as badass as they are. They don't have impossible in their vocabulary. They won't be heros today, but they are Gods.

With badass people, I don't have to dumb myself down. I can be myself. I can even be a better me. I feel human.

Bad people are not characteristically bad. They are just morons. They are not even good at what they do. They fear even the slightest change. They are insecure. They hang on to legacy practices and technologies. They are slow as f....

It is sad to work these people. It is depressing. You can try and teach them new things or better things but they won't get it. In this case what does not kill you does not make you stronger. It just makes you crazy.

Ass people are characteristically like the bad people, but they have learnt to make noise. They are
oxymorons who impede progress. They make a lot of noise over things that matter most to them. They squash real issues impacting the quality of work just because it does not serve their purpose. They are back stabbers.

They put fear into others. They create self doubt. They do take credit for other's work shamelessly. They withhold information to look like heros. They will excel and fool people into thinking they are more than they really are.

A Testers Life

There is a plethora of examples explaining about a Developer's life. It is time to show the QA in the same "light". I am a QA and only some of these are my experiences. Which ones can you relate to?

This is what they think QA are like


This is what we wish QA could be like


My first day on the job - I am introduced.

Product training for QA

I am trying to find my way through SharePoint


It has always been like this. It's not a bug, don't log a ticket for it, the existing QA tell me. (Or maybe they do not want to admit that they missed a big fucking bug.)


This is how Devs are trained about the project.


This is how QAs are trained about the project

I finally get my build to test. It is 5:00 pm Friday

I am not given access to anything, but I am expected to test

Setting up Test Data


Smoke Testing (it usually never detects the fire or smoke till we get to production and a customer reports it. But it sounds good.)


Trying to catch a sporadic bug. Arrrrrgh!! 


I test on multiple environments. (One size does not fit all)


All paths do not lead to the destination

I test with all possible scenarios


I also test on IE. (!!Why are the Mac users sitting next to me!?!.)

With every test, I see bugs crawling towards me.


My bugs got closed without justification.


Dev Team meets me for the first time

One of the thingies is spinning. Dev tells me it met the specification!! (They close my bug)

They tell me it is a great space saving design "users" will be happy using it. (Again it is not a bug)

Dev asks me to redo every step that lead me to find the bug. I do it even though I know it is not relevant.


I reproduce the bug for the developers, the PM, the BA, other Stakeholders. (my keyboard is chaffing)

Testing the same thing over and over really feels like this. Dizzy!! (sorry regression testers.)


I really don't want the tests to Fail. But I have to do the right thing.

PM's reaction when I stop the release and Dev supported my decision

Revamped product looks modern. Team agrees it is modern and we are out of time and budget. What the heck, lets release it hope people won't notice it. 

Expected vs. Actual. 

They ask for MY opinion during retrospective. (My contract is often ended for being honest.)


They hate me for logging bugs and doing my job.

Product is released. I got Fired

They told me it's an edge case, none of our users can do that in Production. (deal with the upcoming law suite bitches!!)