Let’s face it: Sometimes being a tester can feel like being the bad guy. Much of your time consists of telling people when something hasn’t worked or when something needs improvement. When you’re the one consistently bringing up flaws, “staying positive” doesn’t always seem to fit the job description.
But QA team members are not hired just to contribute negative energy! In fact, QA should be the ones saving the day by helping prevent bugs from reaching customers.
Here are some ideas of how we, as testers, can become the heroes for our teams, not the villains. These tips and examples will be through the lens of a QA team member, but hopefully they will prove useful for anyone who feels they often bear the burden of sharing bad news with their team.
Have a ‘shift-left’ mentality
The idea of a ‘shift left’ mentality is getting testers involved from the start of the process, usually in the initial planning of a new feature. The first mistake a tester can make is assuming that their work begins once the product is built. Instead, a tester needs to take responsibility for their role in the planning and preparation that goes into the product. Depending on your tech background, planning meetings may appear intimidating or irrelevant to your work. When I first transitioned into Quality Assurance, it was easy to surrender to “imposter syndrome,” feeling out of place and unqualified to contribute. But this is EXACTLY where you need to start to become a team hero.
In planning meetings, speak up! Ask questions! Don’t leave the room until you fully understand what is being discussed. A QA specialist’s job is to help identify flaws, weaknesses, and complexities that others might not recognize. You are as responsible as the developers are for the creation of a successful product.
By being actively involved in the planning process, you’ll know what to expect from the product, which makes the development and testing process much smoother. Imagine the amount of work you’ll save the whole team if you can identify issues from the beginning, rather than waiting until a deadline is looming.
Example questions
- Ask your team about the risks associated with releasing a new feature. How can those risks be minimized by using A/B tests or releasing the feature gradually rather than in large chunks?
- What is the plan in case of an emergency? Can this code be reverted? Are there complications involved in reverting? Will the feature be backwards compatible?
- What other unrelated parts of the code could potentially be impacted?
- Discuss the amount of manual regression work that will be added for QA as a result of this new feature. What plans can be made for automated testing/unit tests in the future?
- As the team estimates how much time and effort will go into writing the code, offer suggestions as to how complex your testing experience will be. They may expect a feature to be released within hours of the code being completed, but you may anticipate several days of needed testing. Include your portion of the work as part of the team’s estimates.
Team heroes start at the beginning by getting involved in the team process from DAY ONE. Team villains hide in the shadows until a deadline is imminent.
Take responsibility for feeling included
Here at Lucid, we work on scrum teams with one QA member per team of 4-5 developers rather than one large, separate QA team. As a new team member, I once had a team leader pull me aside to check if I felt like an included member of my scrum team. While this colleague was doing their best to make sure I felt fully integrated with the team, I realized that the only true separation between my team and me (aside from our job descriptions) was myself! If you are the only QA representative on your team, that doesn’t make you an outsider. Your unique role means you are essential to your team.
To feel more included, bridge the gaps between your development team and other customer-facing roles. Our role is to provide “quality assurance,” which means we need to be aware of the areas of the product that will cause friction with customers. Seek better understanding so you can share knowledge with your team and be prepared to test from a customer’s viewpoint
You can also feel more like part of the team by being open about expectations up-front. It can be difficult to feel like you belong if your teammates’ expectations and your expectations conflict. Communicate to your team those expectations placed on you by QA management and your other responsibilities within the company. Your job likely involves tasks and meetings that are in addition to the work you do with your scrum team. Discussing those responsibilities from the beginning will help you and your team better respect one another’s time so you and your team can schedule time more effectively.
Practical applications
- Set up meetings with Customer Support and/or other teams in the company to better understand the viewpoint of the customer.
- Don’t wait to speak up! Give yourself a voice in the conversation.
- Help your team understand your other responsibilities within the company, and work together to find the best schedule for testing their features.
- Take pride in your participation and what you contribute to the team.
- Get to know your team members better, especially their humor and the way they handle criticism.
You are not just a tester; you are a team member. Team heroes bring groups together. Team villains wallow in feelings of self-pity and inferiority, and they exclude themselves from the group.
Understand effective forms of communication
The essence of a team hero comes down to how you communicate. According to the writers of the award-winning book Crucial Conversations, successful communicators are not those who avoid giving negative feedback but those who know how to communicate both honesty and respect in tough situations. As testers, it’s part of our job to communicate the errors we find, but we have control over HOW we do it. Integrating a few key concepts can significantly improve your communication with your team.
Power in pair testing
If you and a developer are not agreeing on specific behaviors in the product, sit down and walk through the change together. With a developer at your side, think out loud to give them a sense of what you are looking for as a tester. Observe behavior together and discuss what the experience is like for you as a hypothetical user/customer. Begin pair testings with an open mindset rather than just preparing to show someone how they are wrong. This way you can both learn from the experience.
Take responsibility for things you have missed
When things get really bad, avoid a mindset and vocabulary that puts all the blame on your developers. The work accomplished should be a team effort, and when mistakes are made, repairs will also require team effort. If something slipped through the cracks that you could have caught with more thorough testing, take responsibility for those slip-ups. In your retrospective meetings, verbally express what work you are proud of and how you could have done better with your team. It may be a relief to the developers to know that you are not only outwardly critical but inwardly as well. It helps to level the playing ground when you can openly acknowledge your faults to your team, expressing that none of you are exempt from mistakes.
Handle conflict gracefully
If conflict overwhelms you, QA might not be the right job for you. Handling problems and bringing them to light is what a tester does on a daily basis. You will start to fall into the villain category if you retain difficult information because you want to avoid conflict with your team members. You could also fall into the villain category if you are are too focused on blame. Your team deserves an appropriate amount of time to fix what was broken, and deserves to hear it respectfully. .. It is not your job to just throw problems back into the faces of the developers (at least no testing hero would do so). Provide encouragement for progress made, and be alert for ways in which your ideas can provide an answer.
Use humor
One great way to deal with conflict is through humor. Sharing something lighthearted with your team from time to time will prove you don’t look at all of life through scrutinizing tester goggles. Laugh with your team; get to know them on a deeper level. Breaking the ice with humor can make handling the conflicts a little smoother. Also, be aware that people may have different senses of humor. Get to know the individuals on your team to know what interaction works best for them. Some may love jokes, whereas others may not appreciate them.
Team heroes know how to give criticism without giving offense. A hero speaks their mind but first fills it with knowledge of effective speaking and the topic at hand. Team villains create additional conflict through blame and avoidance.
Wrap-up
When it comes down to it, becoming a team hero is really about being a proactive team member and an effective communicator. That involves:
- Adopting a ‘shift left’ mentality to get involved from the beginning of the process
- Being a force for inclusion, for yourself and other team members
- Learning how to communicate openly and respectfully
Remember, being a team hero means stepping up to the plate and bringing groups together. No one wants to be a team villain; being a team hero is all about working together towards the same goal.
I agree 100% A+++++++++++++++