Strategies to building up reputation as a software tester in a team

Question

It is important to maintain good and productive professional relationship with the management, stakeholders and development team. Many things may depend on that, but, for this question, let's focus on being trusted as an influential and credible source of feedback.

The more trust the development team have in you, the more motivated they would be to fix the bugs and issues you create. It is a known fact that the amount of attention a developer would pay to a newly created issue depends on who created the issue (among other things, of course)

This raises a question about, how to build that trust and a good reputation?

Answer 1

Without looking at the quality of your work, some of the techniques I've used successfully include:

• Be tactful. If I can, instead of simply creating a bug, I'll ask the developer what should be happening, and show them what I'm seeing. I'll often do this from the perspective of "what am I doing wrong?" or "what am I missing?".
• Ask questions. Particularly when I'm working with new feature development, I will ask developers if there are any places where I need to take extra care, or areas that they know of which will need strong regression.
• Add value. My personal rule is if I have to do it more than once, it needs to be written down and made available to the whole team. As a result, I currently maintain the database dictionaries for our applications as well as the regression notes. The latter are the most comprehensive documentation on cross-module impact in the organization.
• Describe customer impact. When writing up defects, make sure to include the likelihood of customers encountering the problem, as well as the probable impact to the customer. Your ability to estimate this will improve as you become more familiar with the software and the user base.
• Give clear reproduction steps with configuration settings. Exactly how much information you need will vary, but for desktop applications I have been known to attach the configuration files to the issue for developers to use because I have a knack for picking the most fragile settings without realizing what I'm doing. With web applications I will often give test login credentials to use for developer reproduction, especially if the problem is difficult to reproduce outside the original environment.
• Question early. If you can, it helps to ask questions about new developments before any code is written. That can help save everyone time and effort.

Answer 2

This question is by definition very broad and depends on so many human factors that are not necessarily related with quality of your work.

To disregard all human aspects of this question such as (your charisma, characters of people who are making those judgment, your look and style and even more trivial such as, your background and opinions you have).

From pure business side:

• Ability to find critical issues, details and knowledge you invest to pinpoint what causes the issue instead of only reporting that there is issue
  
• Your skill that you show while testing and being able to detect variety of issues, especially corner cases that can cause problems
  
• Professional attitude while performing tests, that means that you don't hide issues or favor somebody with less work, because it is everybody's job to fix issues
  
• Being thorough in every project and always perform regression and sanity tests without excuses so that you are able to help developers create proper end goal and not delivering faulty product
  
• Your knowledge and ability to speak with developers, managers about issues and your investment in helping to resolve those issues and in each case you can prioritize your work so that developers are focused on really important issues first
  
• Way you report the issues, details you provide and how you interact with your colleagues through the official channels
  
• Try to use official channels of communication as much as possible and of course avoid situations where you complain to project managers directly, everybody have their job to do, don't interfere unless situation is serious and requires intervention
  

Those are some random thoughts that first came to my mind and this can all lead to that goal and sometimes none of it will make difference. Simple answer is always do your job best you can and let that be your reference and human part will then come at second place.

Answer 3

I only have one thing to add to the very good answers so far. That is, don't cry wolf. As a developer, the people I have the hardest time taking seriously are the ones for whom every bug (or more often, feature request in disguise) is a showstopper. Especially if I later learn that they knew it wasn't a common customer request or issue, but often that's only come to light when a more experienced developer with more history with the product has chimed in on the issue. In one particular situation such a veteran literally commented on a "bug" report that "this sounds like what specialty product X we offered five years ago was for, but discontinued due to lack of orders. Therefore this does not seem like a common customer need and can be deferred".

Picking your battles will definitely help with being taken seriously. It may not directly build trust, but failing to do so can certainly erode trust and give you a bad reputation.