Help! - To find the testing enthusiasm again

(Lauren) #1

I’m not sure where to turn so I thought the community can help.

I love testing - I always have and I hope I always will. However, recently I’m finding myself for the last 2 years on a team where QA and Testing is seen as the bad guy. It’s seen as the difficult option, the guy always giving bad news and forcing more work on the team.

I’m the only QA in the company and I’m the first QA in the company and I’m finding my passion dwindling. I’m finding myself more willing to let defects slide or not to thoroughly test and only do MVT (Minimum Viable Testing) because I don’t want the conflict. I know this is wrong and I try my hardest to not do it. Testing makes me very unpopular.

I’m wondering as I know others have been through projects and teams like this. How do people find the passion and the enthusiasm again to keep through the difficult time for so long? Any ideas and suggestions?

(David Shute) #2

My basic impression has grown into this.

If development is going well, then testing seems transparent. Much like when IT doesn’t have any serious problems people start wondering why they even need it in the first place.

Development is going poorly and testing is going poorly as well then things start exploding for customers. “What is testing actually doing?”

Development is going poorly and testing is effective, then testing is the bearer of bad news, constantly nitpicking at every single thing.

This isn’t true everywhere and speaks to specific environments. My experience has been this is true in environments where developers are expected to march hard on deadlines and don’t have a lot of separation between who they are as people and as who they are as developers. It’s difficult to separate yourself from your work. That makes receiving criticism, which bugs feels very much like, difficult to not take personal.

I would discuss expectations with your direct leader. You have legitimate frustrations. I would gently air those. Along with that, it’s worth considering what things you would change about your own work to improve the situation.

If you can go at it with a plan and an open mind on how to make things work it will tell you everything you need to know.

You’ll either get some forward traction, which will still require work on your behalf, and it’s time to start working toward improving relations and your daily work experience.

The other option is you get ambivalence, or worse, and it’ll be time start considering where to go next.

(Chris) #3

If the team culture is the problem then fixing the team culture is the solution. If it feels appropriate go to your line manager and ask for help. Its a management role, as far as I’m concerned, to see that the teams work well together.

The people who put you in the “bad guy” role have their reasons. These reasons fall into two general categories: hard to fix and less hard to fix.

Hard to fix reasons are things like inculcated prejudice. People who, for whatever reason, don’t like you or your role and refuse to see otherwise under any circumstances. These people are horrible to work with, and finding common ground can be really hard work. If a company hires many of these people it can cause a company to collapse under its own misery and refusal of teamwork. Then you get siloed waterfall. People are generally insecure. This can cause some people to blame and others to bond.

Less hard to fix reasons are things like misunderstanding of testing. People who don’t know what you do and assume you’re there to gatekeep the project and point out their mistakes.

First thing to do is put yourself in the position of offering a service with your testing. Your team are (some of) your clients, and you’re there to provide them with the help they need, catching those rogue problems before the customers see them, guiding them with helpful insights to make their job easier and take away their stress. One approach is to ask them individually (or as a group, if you have that sort of team) what the problem is. Something like “I feel that something’s wrong with the way we do things. Is there something I can do to make things better? Is there anything I do that annoys you?”. The rule is: never, ever blame anyone. Blame yourself, blame the process, blame the context, blame the alignment of the stars, but if you blame a teammate you have an adversary no matter how right you are.

This isn’t so that you then go and do everything they say, it’s so that you can see why they feel that way. I sometimes find this question gives the answer “no, nothing, everything’s fine” which could be an indication that you’ve misread the situation (I’ve done this before, and talking it out proved to me that I just felt targeted but actually everyone was fine with the way we work and it was me that was my problem). Sometimes this requires a “so why do we fight over bugs?” type follow-up question to get the full story.

When you know why they feel that way you can offer to do something differently (if you feel it’s appropriate), offer an explanation of why your role is supportive and negotiate your way to a better working relationship, etc.

Sometimes it’s the process’ fault and because you’re the end of a process you get labelled the bad guy. You could offer the process as a “to improve” and question how you might do things better. Maybe getting the product earlier, pair testing, being involved with design up front, etc could help reduce your bugs. Maybe clearer, shorted bug reports might help. People over process.

Also make sure you’re not doing something that you don’t need to do: gatekeeping quality, holding up builds, deliberately (or accidentally) wasting the team’s time, raising bugs nobody will fix, raising bugs people cannot read or in a way that they can’t understand (ask them what they want in a bug report), insisting that bugs be fixed rather than offering compelling reasons why then leaving the decision to others, that sort of thing.

Sometimes we are sacrificed on the altar of process, sometimes we genuinely are doing something wrong. If you go in with humility, and suppress your hulk rage (should you have any), and offer an improvement to the service you provide through education or process change, that’s how I generally get things to improve. Or I move companies.

To summarise:

  • You need to have an accurate picture of the situation. Maybe you’re the bad guy or maybe not. The only way to know for sure what’s wrong is to ask. It’s for everyone’s benefit that you work as a team.
  • You need to offer a service to your clients that they are happy with.
  • You need to be seen to be offering a service to your clients that they are happy with.
  • If they are unhappy with the process by being unhappy with you: make the process the focus of the team and band together over a common enemy… and change the process.
  • You need to be seen as competent, but in my experience being seen as empathetic and supportive is even better.
  • You need to write bug reports that your team can make easy use of. If they struggle with your bug reports then your bug reports are bad. Ask them what they want.
  • When you give your team what they want you’re more likely to get what you want (egs. coding testability into the product, test tools, patience)

I hope that’s helpful. Without specifics it’s really hard to fix something like this because it’s full of possibilities. Hopefully I’ve provided some inspiration for some approaches that might bring you closer to a fix to the problem. When that’s fixed you’ll very likely feel much better, because you’ll feel that you’re doing work that’s seen to be valuable.

(Wojciech) #4

You have already got great advice above. I think there is also one thing worth remembering when assessing your options if the other ones do not work:

“If you can’t change your organization, change your organization!” Martin Fowler

(Robert) #5

Two questions:

  1. Are you using any sort of bug tracking system that enables you to rank bugs for severity and impact? If you are, then that gives you the opportunity to say to developers “Hey, I’ve raised this bug, but it’s not the end of the world if it doesn’t get fixed right now” and for the record to show that. It gives developers a chance to see that some bugs are less important than others and so restores some sort of balance to the situation.

If you’re working in some flavour or other of Agile, you can arrange things so that less urgent bugs stay in the product backlog until they either become urgent to fix or until things are sufficiently relaxed for lower-priority bugs to be tackled. If you’re still using waterfall, then knowing which bugs prevent release and which can be left until a later version of the application (when they can be called “enhancements” and so make the devs look good for improving the product) will be helpful and contribute to massaging the developers’ egos.

  1. Conversely, have you ever found a bug that would have gotten developers sacked if it had got out into production? Finding such a bug and saving someone’s hide goes a long way towards changing attitudes (especially if a middle manager never finds out about it).

(Andrew) #6

It’s important that the entire team understands what testing is defined as, what a quality product means for the company, and how they fit into the overall business goals of the product.

I highly recommend bringing dev and test together during test planning sessions and while you are the driver of the meeting really letting dev go through what the risk is and where they think you should focus. This not only roots out any oversights that may have been made but provides ownership on both sides on what is being tested.

This was also already said but test should not be the gate keepers of quality. When we find a defect that has to be elevated we are taking data that we found turning it into information and allowing the business owner (product owner, project manager, business analyst, etc) make the call on if it is worthwhile to fix or not pending the release.

(John) #7

How do people find the passion and the enthusiasm again to keep through the difficult time for so long?
You could think about;
• You only find the faults of others.
• Some think that they don’t create faults.
• A discovered fault is usually due to a faulty process.
• Processes can be improved.
• Not only do you have to sell the sh*t sandwich, you also have to get folk to eat it.
• There is someone else who cares as much about quality as you do. You just need to find them.
• Sometimes our eagerness for quality, at the expense of pragmatism, can make us seem inflexible, arrogant and appear superior.
• No one comes to work to intentionally do a bad job.
• Should the team factor in extra time for rework?
• What would happen if you told the programmers exactly what you were going to test?
• It’s just a job.

(Kim) #9

Lauren, it sounds exhausting your current situation and I wish your situation was different.

Everyone on this page has given you excellent suggestions and I don’t have anything to add other than maybe join a meetup group in your area for testers. Or attend a testbash conference if your able, being with other like minded people helps in many ways. Definitely keep chatting here as you will find there are other experiencing or have experienced what you are going through.

I was in a similar situation to yourself once and my sanity was saved by meeting my now closest friend who is also a tester. She literally helped me get my waning confidence back by talking me through what was happening and confirming I had taken the right path or highlighting where I had gone off the right path. That was invaluable to me personally and professionally. Reach out anytime if you feel like a chat :smile: