Realities of QA in Software Testing

1. I have seen in my experience till now that position of QA is least in most of the organizations.
2. No body is aware about QA. Nobody knows the value of QA. But they can take decisions on QA tasks/plans easily.
3. Everyone thinks that any person can perform QA tasks on any project.
4. QA always dances on the fingers of Developers.
5. Developers decides who will be the QA of their project.
6. Developers decides which bug should be address to the client because it can harm their positions.
7. When new comers come to any organization they do not want to become QA because of above points.
8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.

Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery.
And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.

Please forgive QAs and try to understand their feelings afterall they are also human beings.

Here are the valuable comments on invaluable article written above:

Yes! Rajiv,
you are very true!! Now a days nobody was have QA scene!
-Krish

Yes rajiv, it's really true
-Vaneeta

Yes..
That is 100 % correct
I am also agreeing with Rajeev
-Sarath

Totally agree, for a real QA there must be an active compromise from management leaders making sure that everyone is aware of QA, and protecting the space of QA within a company or project environment.
-Antonio

HI Rajiv and Guys!
I really appreciate your effort and feelings about QA position in the present industry.
Exactly I am in a same situation where u have explained the points. In my current project, DEV team did not fixed the bugs and repeatedly client reported bugs. My manager thinks that everybody can test an application to catch bugs.
But in my view, Testing of the application is not that much easy as people thinking.
Let me give one example: One developer will write the code to fulfill one requirement and not to break by a tester with maximum number of scenarios. But a tester has to think technically & realistically (as a end user) to break the application with more number of scenarios as a developer thinks and finally breaks the system.
Let me know if I wrote anything wrong.
Thanks
-Arif

Sad, but true :/
-LadyRoot

I've seen a lot of agreement with Rajiv's observations, but I must say that it's not true in every company. In my experience it's been more true in the larger corporate environments, but I'm currently working with a small company where the QA department is greatly appreciated, the developers are eager to fix bugs, and they actually want the input from QA.
I would also like to point out that even in the large corporate environments I achieved a high level of success with the developers (managers were a completely different story). I used the principles from Cem Kaner's Defect Advocacy course and taught it to my entire team. While convincing management of our true value was never achieved, we had most of the developers wanting our testing and responding to our defects. A lot of how they react to our bug reports is dependent on how we approach them with the defects. Continuing to hold an attitude of "us vs. them" tends to make them put up defensive walls whereas an approach of helping them produce better code produces more of a teamwork atmosphere.
I'd highly recommend going through Cem's course (http://www.testingeducation.org/BBST/BBSTbugAdvocacy.htm) and applying what you learned to your environment. You can often change the environment by changing your approach.
-Thad Butterworth me too in the same situation

-Venkatesalu

1. I have seen in my experience till now that position of QA is least in most of the organizations.
Ravi: Its not in my Organization. I feel you have not seen much in your life.

2. No body is aware about QA. Nobody knows the value of QA. But they can take decisons on QA tasks/plans easily.
Ravi:
- No one will be aware of anything, unless its been proven.
- Prove yourself, test & expose the s/w in all ways.
- For all this you must be aware of the system like anyone else developing it, designing it.
- If you look at all projects like a user then you will be treated as common.

3. Everyone thinks that any person can perform QA tasks on any project.
5. Developers decides who will be the QA of their project.

Ravi:
- It may happen initially, but once your QA team gain some expertise then you can assign some person.
- If all of the team members are doing user level / black box testing then its obvious that anyone can do the job.

4. QA always dances on the fingers of Developers.
Ravi:
- Whomesoever doesn't have knowledge on system dance on other person fingers.
- Its applicable for another developer too, so learn about the system in much more details and expose s/w by all means.

6. Developers decides which bug should be address to the client. because it can harm their positions.

Ravi:
- If its might be a business decision.
- But keep a record of all the issues through mail and get their reply in specified time and save them so that at adverse time you can expose with details.

7. When new joinies come to any organization thay do not want to become QA because of above points.
Ravi:
You must be proud of yourself being a tester first, are you ??

8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.
Ravi:
I feel you must be aware of system / OS to be a better tester.

9. Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery. And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.
Ravi:
- This might be applicable for development team too by giving small time for development.
- You must have good managerial skill to tackle these kind of issues.
- Give your report specifying basic testing alone executed and details testing is not done due to lack of timing constrains.

10. Please forgive QAs and try to understand their feelings afterall they are also human beings.
Ravi:
- Don't plead for QA's, QA is in good position only. You need to improve your knowledge & other soft skills.

I aggree with Rajiv's points. Its true man!
Although it is not true in my current company but in my previous
company this was so very true.
-Mugen

A debate should remain healthy but I see points that can turn this into something else.
I am also working as a tester & I believe some of the points both you gentlemen (Ravi & Rajiv) are correct, Though I feel Ravi has better points.
At some point everyone remain unsatisfied whether he is developer or tester. And Rajiv, you would be agree that there are few companies where developer feel same as you wrote about testers. Tester is not any pitiful animal, he has his points & if management decides to disagree with his point of view it does not mean that he is worthless.
I refuse to accept my job on the points you wrote however some of them might be correct in your context.
People will feel pity for you only if you represent yourself as one helpless creature.
All in all, its up to me how I take & value my job & it does not need any debate to change my point of view. I value it, I know its worth & hence I am here.
Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals.
-Vikas

First of all, let's clarify what you are talking about. I've got a
feeling that you speak of testing rather than QA role.
It can be that testers are undervalued in some organization but it
isn't true for all organizations. As they say a fish starts getting
spoiled from the head. If top management sees testers like monkey,
like under qualified working force then others in organization are
most likely to share this vision.
Also, a lot is in hands of a test manager. His or her primary goal is
to provide quality working conditions to the performers. Treating like
pigeons by management or developers will hardly make team moral
better. Test team manager should keep defining comfortable working
atmosphere by loosing strain between testers and developers. I did it
many times in my career. The best way is to explain tester that this
is natural for developers to express their bad feeling about discovery
of an issue, so we need to learn how to politely ignore the first
expression and keep the voice of discussion down. On another hand I
kept preaching to developers that we are all in same boat, that
testers are just like them but simply doing another work, that this is
much better that we have found earlier than later.
So, this is frustrating to be undervalued, but you can do something
about it.
-Vladimir Trushkin

Hi Vikas,
Thanks for the beautiful reply. I know Ravi's points are better. I am also not facing these problems in my current organization.
But I have written this article on behalf of my friends who are working in different organizations. Also I have taken survey on this and found that more than 70 % people are facing these problems. I have written just the problems of those people who are working in different organizations and facing similar problems.
My motive is not to tell just the problem. I wanted to discuss the proper solution on these points.
We can do this only if we *all* agree on the points which I have written. We have to admit that many testers are facing these problems. If we will not going to admit this then we can not help them.
I am not satisfy with your comment i.e.
"Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals."
I think this Google group is not created for just to discuss theory part. We should also discuss these types of real time challenges which we face practically. And I do not want to create any minority group but I want to help people who belongs to my profession. Because..
I am proud of my testing profession.
So I request you all, first of all please agree with my points then provide your solutions. Otherwise this debate will be endless.
I am sorry in advance if anyone of you think that I am wrong.
-Rajiv

Hi all,
appart of my initial agreement with the initial message by Rajiv I would like to add the following as a paradigm in perharps many of these organisations where testing tasks are compromised and QA not managed as a whole. Let me know how many of you agree:
1 - Selling is the real constraint, no matters what is going to be sold.
2 - The product is not completelly specified normally so that the whole project is opened to any customer's request.
3 - Eventually any request may arrive for development without any analysis work done about feasibility or impact in the project's current state.
4 - If new requests impact is not taken into acount, milestones' deadlines may not be postponed accordingly.
5 - The project goes into a state in which there are more tasks to do than planned and there is less time for them than planned.
6 - Since development happens before than testing (obvious, I know), development takes integration and verification time.
7 - Hopefully testers just perform some sanity tests of a recently integrated product version before releasing the product.
My conclusion after all these comments: it is a must that management believes in QA and works for it, giving enough flexibility for selling but always allowing time for analysing, developping and verifying what is being done as a product.
All the best,
-Antonio



Related Testing Topics:
a. Black Box testing
b. Testing Experiences