In many companies, anyone classified as a “tester” is a second-class citizen on the dev team. If you don’t code, you have another strike against you. But we’ve all experienced that point on a team when suddenly the development team requested you be present in a meeting or claimed to have missed your help while you were on holiday. What are those events during the early months of your time on a team that help you build credibility?
First of all I really hope that you are not experiencing the “tester” being second hand, second class citizen situation, been there, done that, and it is not nice.
I can only give you some pointers that I would do in such a situation
-
Use the stand ups to their maximum potential - listen to others, express your concerns, express your points. Have an attitude that shows the team your are a valuable part of the team.
-
Bugs - write the bugs as clear as possible and as technical as possible.
-
Feature testing- ask for developer sessions before testing a feature, so that you show the team that you want to understand the feature, that you are asking the right and the wrong questions
and they will see the value believe me -
Sprint presentations - always be eager to present the work done in the sprint. From experience I can say that not a lot of developers like to do these kind of presentations, so you can get some extra points there.
-
Communication outside work - Use the coffe maschine time, the lunch, the ciggare pause to get to know the team. In this way you might find out that you have common hobbies, interests and you can also use the time to discuss some work/tech related subjects. Again point for you.
Hope this helps.
3 Likes
Hi Jennifer,
Everyone wants to be happy. If the testers are causing the developers grief then you are going to be treated like a second class citizen. Now I’m sure few testers are thinking, “How can I make developer’s lives difficult?”
Everyone on the team whats to do a good job. But developers could take it personally if you are always pointing out what they are doing wrong. Blaming someone is different than constructive criticism. So how you bring problems with the software to the attention to the developers can change how they see you.
I was taught that people tend to assume the worse. If left to my own devices without enough information, I will tend to assume the worse. The solution is communication. If you give the developers more information it is harder for them to assume the worse. I’m not talking about information about the defect; I’m talking about information about you and your motivation.
Additionally, if you are communicating with the developers, you will learn how you can help them.
If the developers see you as someone trying to help them, when you go away on vacation they will miss you. If they see you as just causing them grief, they will be happy when you go on vacation. Long term, they might be unhappy if the application ships with defects but short term, they will feel better if they don’t feel blamed for defects.
Essentially, figure out what you can do that will improve the application in a way that helps the developer.
Finding defects, providing minimal information and move on. That is not helping the developer find and fix the defect. Talk to the developer (maybe pair with them) and find out what information they need to solve it faster.
Pair with the developer (even if you don’t code) and ask questions to make sure they are handling all the edge cases. This will prevent defects and help the developer be a better tester. I, literally, try to put myself out of a job making developers be better testers. It happens. Then I move on and start helping another developer. Oddly, there are more developers than testers. So I never seem to finish. 
Bottom line, make their job easier. Make them better developers. They will like you. They will miss you. The software will get better.
3 Likes