Posts

Showing posts with the label Testing

A Testers Life

Image
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

To Process or not to Process

Image
A long time ago, there was a land lord who started the tradition of throwing a huge party for all of his town folk in his huge backyard once a year. Right before the party began, the land lord would get his men to catch his pet Cat and put her under a wicker basket and then put a brick on top of the basket. Right after this event, the party would begin. The landlord passed away and his eldest son took over the family house and the traditions. The eldest son did not have a pet cat. But every year at the time of the party he would instruct his men to get a cat. He would then put the cat under the wicker basket and then put a brick on top of the basket. This tradition was as important to this landlord’s family as having a real turkey or a fake tofurkey on Thanksgiving to most of us Americans. Nobody had any issues with this process, so they went on carrying out their practices. Now, let’s try and understand about why the landlord originally used to lock his cat right before t

Test the pencil

Image
(Not to be mistaken for the pencil test)  If the requirement for a pencil was to write 10 pages, and during testing the pencil ended up writing 12 pages. What should the testers do? Pass it or fail? Should the testers PASS the pencil test because the result was better than expected? Should the testers FAIL the pencil test because the result was not per spec? May the testers ask for more specs regarding the weight and thickness of the overall pencil? May the testers ask for more specs regarding the weight and thickness of the lead core? Should the testers re-test the darkness of the writing? Should the testers use other kinds of paper for executing re-testing? What would you do as a tester? Why should you do anything else besides testing and giving a pass or fail? Possible defects –  Longer pencil than mentioned in spec Thinner lead core than mentioned in spec; Possible concerns –  More money is being spent on the pencil Less return of investment may be the resul

QA in most companies is like Sex Ed in most schools

Image
The movie Mean Girls  has a sex Ed  class scene in it. The gym coach gets a bunch of teenagers into a room and explains about sex like – “at this age you will have urges to touch each other. If you do you will get pregnant and die. Don’t have sex. Guys promise you won’t do it!!” at the end of the class the coach brings out a bunch of contraceptives and offers to the students to make it look like they are serious about the "education". Companies have QA teams. The QA team is trained for a release as such - “at this time you will have urges to do boundary value analysis, top down testing. If you do it and find bugs, we do not have resources or permission to fix them. Guys just do testing and nothing more.” At the end of the project they throw in automated testing for regression tell themselves that they are serious about testing. This is (fortunately) not true with all companies. But if you are dealing with a situation similar, laugh out loud and do your best. You

Tool is only as good as the user

Image
As a SDET, I believe that the automation tools wrongly called testing tools, can do no testing. It is a tool that does what I tell it to do. I can tell it to go through all the pages and it will. I can tell it to pass a failed test and it will pass. I can tell it to fail the whole application and it will fail. Once again, it is a tool that does what I tell it to do. Kind of like this story -  Once upon a time there was a King who owned a device that worked like a lie detector. The device had a pointer that would point to the left when a person wearing it lied, and to the right when the person spoke the truth. The king was very happy that he found a device that will help him in judging people rightfully. The minister was concerned though. He did not believe the device was of such great use. He also feared, if would cause harm in certain cases. One day the cops brought in a farmer who killed his landlord.  The cops put the device ("lie detector") around the farmer&#

If testing was like sex

Image
No wonder most Software out there is f...ed up and violated!! According to Freud - the unconscious mind and the primary motivation for all things in life is sex. So, I am comparing software testing  behavior to making love during my leisure (bored out of mind) time. One more reason for doing this - both these subjects are kind of taboo even in the most open minded culture. A first time virgin tester does their best, completes the job as their instincts tell them and from all the documentation (videos) they had learnt from. But they know there is more to it than just completing the task. In a stress free environment, the tester is enthusiastic and wants to give their best because the application deserves the best (in order to improve the product, make it bug free). So, they get the book  that contains all the various techniques for completing the task. They learn and apply all that they learnt. During the process they understand there is no way in hell they can go through some te