The Tester with more than 1 hat…
Recently I’ve been reflecting on my role as a Tester. One of the things that came to mind was the breadth of the role and how many disciplines it spans across.
I’m seeing more and more topics around the relevance of Testers and “we have automation so why do we need someone to do testing”.
Well, have I got news for you! We don’t just do “manual testing”
I wanted to highlight those disciples so for those that don’t work closely with Testers, you can get an idea of how we can add value. There is less of a focus on the testing aspect and more on the disciplines the Testers role encompasses. This is not an exhaustive list, just some food for thought 🍖
Product
By product I mean: product managers, business analysts and UX/UI designers
- Working closely with product to help define requirements. As the Tester has arguably the 2nd most domain knowledge of the product, they can often be invaluable when it comes to requirements gathering and user story mapping. This works particularly well if the product manager is new to the team and doesn’t have the domain knowledge yet.
- Actively encourages collaboration between designers and developers through pairing
- Suggesting improvements to the UI and UX i.e. identify issues around text wrapping and image sizing
- By always thinking as the end user, you may come up with some ideas that the UX/UI designer hadn’t considered. For example, a specific component is changing but it wasn’t considered to update this across the app for consistencies sake.
- Encourages an accessibility first approach
- If we’re working on updating the UI for a specific part of the application, do we have the opportunity to roll out these changes to other parts at the same time. This will save us time in the future as we won’t need to create separate tickets for it.
Scrum master/Agile coach
- Identifying any dependencies on other teams in order to deliver work. Once these dependencies are identified, arrange a meeting with the relevant people but don’t go overboard! Only involve those that are directly impacted. You can always update the whole team on the activity during the daily standup.
- Ensure relationship between engineering and product team. Personally I see one of the roles as a Tester as the bridge between product and engineering. We’re technical enough to understand how acceptance criteria can be translated into working software but not so much that we get overwhelmed by the code.
- Encourages collaboration through communication. If you think that one of your colleagues would benefit from having some face time with another member of the team, encourage it! I’ve been in situations where I’m almost acting as proxy between developers and product. In most cases, we can resolve issues why communicating with one another.
- Facilitates collaboration and makes sure everyone has what they need in order to be successful. There’s a difference between hearing and listening and having conversations can quite easily uncover blockers that people hadn’t really considered. So next time you have a conversation with someone, listen to them as you may help uncover information that enables them to perform better
- One thing I’ve learned from the many meetings I have attended over the years, make sure that if you’re arranging something, that you know exactly what you want out of it afterwards, nobody likes the feeling of being a part of a wasted meeting! Likewise, try and encourage involvement and actions from participants
Whichever hat you wear, you will always be advocating for maintaining and improving quality standards. If you fit one of those roles, what is your perception of what a Quality Engineer does?
