Dear Agony Ant,
I feel like an outsider in my Agile team, with my role as a tester being downplayed.
How do I assert my importance without stepping on toes?
Dear Agony Ant,
I feel like an outsider in my Agile team, with my role as a tester being downplayed.
How do I assert my importance without stepping on toes?
Try to show what modern testing is all about - not just about testing, try to get involved and try to be proactive, take an interest in what others are doing.
Also, getting to know people better and getting closer to them (over time) will make people more fond of you and therefore more pleasant to work with.
Firstly ask the question, are you actually important to the team?
Is your role being down played because you are not adding enough or because you have a different understanding than them regarding testing value?
I have dropped out of some teams before, the way they were working I was not going to add much value and felt there would be other teams where I could add more value.
The idea of asserting importance you have to be careful with, are you making it about you which could then create larger distance between team and expectations.
Find alignment of understanding and expectations of the role of the tester is likely the starting point. What is important to the team, what are their expectations, how differently do you see your role from what they expect.
Sometimes I have found teams with very old expectations of testing like I am just checking their work, other times some teams wanted to pass over the things they did not enjoy documentation, test cases, automation. Some even wanted to hand over quality to me and release signoff responsibility was another one, yep they wanted someone to take the blame at times.
I usually start by explaining my usual role and where I usually add the most value to teams but that I am flexible to adapt to what is important to the team if we agree it makes sense.
Find out what is important to the team, make sure they understand your view of testing value, compare it to their view and find a balance.
Your importance will come not through assertion but through showing that value every day through your testing.
In the past I have created and presented a testing strategy, using the RST heuristics approach. It serves as a great platform to discuss how your role as a tester could fit into the development process. Also, like Mirza says, get involved with what the devs are doing. Often times they will let you know how a tester can help with the process by talking through what they up to.
I find doing my job good, bringing actual problems in the product on the table, let people discuss them instead the value of testing.
Show (them your value), don’t tell (so much).
And when you don’t find (many) problems, you can assure people that the product is good and shine a light on the developers.
I find this not being stepping on toes.
Also maybe some people need to get comfortable with the situation. Be patient and give them time.
I don’t know how your are doing things. I invite my teammates regularly to my test planning and review, discussing potential coverage, risks, impact and findings. Typically top-down, starting at more general points and slowly going into details.
Without bothering them with a test case management tool.
I would try to focus less on you being important as an individual (although you certainly are!) and more on your contribution being important, and the impact that has on the team. Sadly, it seems that just doing a good job isn’t enough. It’s similar to quality in general - people don’t say anything when it’s good, but you’ll notice when it’s bad! So that means you need to work to make your contributions visible. Perhaps start trying to quantify / measure your impact in an objective fashion and bring those up as “things that went well” in retros, or mention in the daily how your plan for today will positively affect such areas.
Just don’t. Take good notes of all the work you do, write up plans before each block of works starts, and then refer to those plans again in the retros. And like @cassandrahl points out above, reflect, be humble and be objective.
QA is often a big topic and responsibility to cover in a retro, but be sure to come with solutions, and be sure to talk about past experiments (the ones you documented in your test plan) that worked or did not work.
DeadAnt-DeadAnt, DeadAnt, DeadAnt-DeadAnt-DeadAnt-DeadAnt-DeadAaaaant (sung to the pink panther theme tune)
anonymous18, do you understand who your clients are?
Do you understand what information they expect from you?
You can not establish your value if you do not understand what you deliver and for whom.
What is your version of modern testing? If I don’t do exactly that, but something else, what am I?
Well, you have to be keeping up with the changing times, the pace of development has increased and testing is no longer an afterthought - at least for the last decade and more. I meant more old-fashing testing where the QA teams is separated and often don’t know what’s happening in a timely manner.