Ask yourself what were you hired to do?

Many times it feels like the people in the project don’t really understand what you are doing and why? It can go as far as feeling the testing team is the only one stopping the product from being released to the field. Have you ever wondered if this is right?
I read a nice post in TestingReflections by John McConda. John talks about the fact that testers provide a service to the team, and that many times we suffer what he calls “genius envy”, leading us to act as gatekeepers and/or play games of power with the rest of the project stakeholders.
I agree with him.
Not only that, but I can testify that I used to suffer of these “genius envy” attacks (I just love his definition) and was constantly looking for an escape route out of the testing Job misery I had gotten myself into.
After a while, as I started learning more about testing and how to do it right, I began perceiving the real value we could bring into the process.
I remember how my personal perspective changed; I was suddenly able to explain to my friends and family what I did for a living without feeling the need to apologize for being second best in the team.
But I want to take this to another point, the point where we should define our tasks as services and ourselves as service providers.
Think for a moment about another service provider in a different professional area, a tailor for example. Whenever a client comes to his shop, the tailor knows he needs to understand the needs, likes and constraints of his customer in order to design and make the correct garment.
Why should testing be different? We know that our customers want to use our testing abilities, but we need to understand what are their objectives, needs and constraints in order to provide the correct set of test and services.
At this point I want to introduce something that helps me provide a better service to my development “customers”, my personal view of the testing team’s objective.
Based on my experience I see the goal of the testing team as follows:

“To provide correct and timely visibility into the product and process, in order to help the organization make tactical and strategic decisions; and to do this as close as possible to the defined constraints of schedule, functionality and costs”.

The main components of this definition are:
1. Visibility – testing is not aimed at finding all the bugs, it needs to provide a clear view of the status of the application (bug numbers are only a small part of it!).
2. Correct and timely – the information should be right and corroborated (if possible backed by facts and not only gut feelings); and it needs to be provided when it matters and is still relevant to the stakeholders and the project.
3. Help the Organization make decisions – we are not gatekeepers in charge of stopping the application from reaching the field. We are in charge providing inputs about the product and process that will help the Company to act correctly; these actions will be based in part on our information but also on additional factors and inputs such as marketing considerations, sales objectives and deals, operations, etc.
4. Work based on constraints – this is where reality enters the scene and we need to do our best under the current project constraints.
All the points above provide us only with a framework. The concrete definition of our objectives and tasks will be dictated by the goals, needs and constraints of the project as defined by its stakeholders. The job of the Test Team Manager is then to understand what is needed, and to create and execute a plan that supplies these needs.
If we understand we are providing a service and we know who are customers are, then we can go to these customers and ask them what their needs are. If we know why they are “hiring” us we will know how to provide our service in the best possible way.
Just go and ask them why did they hire you?

http://qablog.practitest.com/2008/08/ask-yourself-what-were-you-hired-to-do/