Quality Assistant

-


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 every bug I logged is fixed and is accepted. It is  team decision to fix a bug now or to backlog it or reject it. It is not my decision or the developer's decision. (Although this is old school thinking from 1997).

Thanks to this notion, many organizations maintain their teams working against each other while working for the same goal (like “frenemies”). But there are teams where developers and their testers work together to build not just a product, but something great. In the later the A in QA means Assistance. Not assurance!

I mean what are we assuring? What can we assure? We are assistants. We are quality assistants to the developers. We assist them in doing a better job. We are not finding faults. Together we build a better product.


I have not met a developer who did not care about the quality of their work or their
product. So, they care. They don’t just code and sit back for the QA to find issues and work on putting them down. They do their part of testing to make sure their code works. It is my job to make sure the product as a whole makes sense and it sensible (Yeah , yeah, bug free, what ever that means).

I prefer to make my application better by continuously exploring it, learning about it and respecting it. I dont believe in breaking it or trying to break it. (Again 1997??)

Comments

Post a Comment

Popular posts from this blog

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 ...
Read more

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...
Read more

Why you should not delete Tickets

-
Image
I am old school. Back in the day, logging a ticket was not everybody’s job. Prioritizing and removing tickets from the queue was also handled by a coveted few. Limitations on data (storage) also contributed to further bottle neck ticket creation, prioritization and maintenance. Every ticket was precious.   Then came agile and coincidentally data (storage data) also became bigger and cheaper. Everyone was allowed to log a ticket for ideas, issues, needs and wants. No topic was taboo (as long as it was within the scope of a project of course)   Tickets gave an opportunity for every team member to use their voice. And this WAS very important in Agile, people over processes. I say WAS because since last 4 years I have seen a trend of deleting tickets for the silliest of reasons in the name of Agile and keeping the backlog lean!! Not just at one company or team but in multiple teams. I also happen to observe that the people who do this are new to IT.   Some of the justificatio...
Read more