In developers we Trust. The rest we Test.

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 resul

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 th

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

The old school philosophy of testing is "Break the software". I used to think this way and be driven this way. Then I realized something, when my focus is on breaking something, my approach is attack mode..... If I want to break a glass vase, I throw it down and it breaks. If I want to break my software, I find vulnerable spots and take a jab at it. Then what? I report, "hey, its broken" and probably feel proud that "Hey, I broke it!!" Then what? I don't know.  I am not sure if this approach every worked for me. I usually fall in love with most products I work on. They are my babies. I want the best for them. I want them to evolve and improve. I want them to co-exist with their sibling applications. I want them to have a unique name in the software industries. I want to give them the best opportunities I can provide with my team. It takes a village It take a village to raise a kid. It takes a team to create a prod

I am often asked about how I deal with my programmers on a day to day basis. The question means well, I am giving them bad news about their work. It is only natural for anyone to doubt - how this paid relationship works!? There is this joke / story I heard a while ago that could explain the tension between a developer and the QA. Here the Wife is the Developer and the Husband is the QA. Wife : (puts on a new pair of jeans) Does this make my butt look big? Husband : (just stares, if he tells her the truth, she might get mad. If she does not her friends will tell her the truth and she will still get mad) Wife : Honey, you can tell me. I won’t get mad. Husband : You say that now…. Wife : I promise I won’t get mad. You can tell me anything. We should be able to tell each other anything. Husband : OK, here it goes. I slept with your sister. That is how I typically roll. I gain their trust and then give them a bunch of bugs I found. It is not my job to make sure ever

“Working so hard” “There is a lot of work to do” “Such a big application” “So many bugs”  "Too much work load"  "Not enough time" What should it really mean to the person hearing it? – Nothing. I have seen members take loads of work and not bat an eye and do it with ease. I have also seen members take little work and make it look big and stress out and stress others out. I have also seen organizations that plan and work smart. I have seen organizations that plan to work really, really hard. I am not here to explain the right way of doing things. Whatever floats your boat!! Lol But, when people talk about a lot of work, it reminds me of the Woody Allen movie – Annie Hall There is a scene in the movie with a psychiatrist. The conversation goes like this - Alvy's psychiatrist : How often do you sleep together? Annie's psychiatrist : Do you have sex often? Alvy Singer : Hardly ever. Maybe three times a week.