In part three of our series, Technical Director, Dan Webb and Spartan, Jacob Stoneman, discuss finding your voice in a team of professionals. This blog highlights the challenges and responsibilities Jacob faces in his role as a Test Automation Engineer, and how collaboration can enhance efficiency. Read below to find out more…
DW: Have you ever had a situation where you’ve known there’s a problem, but you haven’t quite been able to find it, and you’ve struggled to get the team to listen to you?
JS: Yeah, this week! There was a ticket that didn’t fall under my responsibility, but I read it as it was deployed and didn’t think it made sense. Unfortunately, my hunch was right, and everything broke.
DW: So, you had a gut feeling that something wasn’t right? There’s a fear about crying wolf, isn’t there? I think it takes a while to build that trust and credibility in a team. A year in, do you feel that you’ve still got work to do there, or do your team listen to you?
JS: I’m getting there. I still raise a lot of defects where I’ve missed something or the fix wasn’t immediately obvious to me, but that’s a part of the process. I’m not a backend dev, or a frontend dev or a platform dev – I don’t always have the full context of everything.
DW: At some point as a Test Automation Engineer, you’ll find a problem and you’ll know how to fix it. How do you stand on the idea that a tester might find a problem and fix it themselves?
JS: It happens, and I consider it a good thing – you can detail it out in the defect and then there’s no ambiguity over what needs to be done to resolve it.
DW: Do you think a team where you can find, fix a bug, and raise a pull request is a healthy way of working? I think a lot of people see a division of responsibility, where the person finding a bug shouldn’t also be the person fixing it, and vice versa. If you think about where we’re going to be in five to ten years’ time, do you think that division of responsibility is the right thing or not?
JS: I think it comes down to how the team works together. On my project, for example, it wouldn’t work very well – we need to communicate constantly, based on who has context.
DW: You were recently nominated at your client for embodying one of their values – daring – for being bold and making an impact with your work. How did you go from being a beginner in the role to finding your voice and having the guts to speak up?
JS: It came with experience, I guess. Understanding the greater context of the project has built my confidence in my own knowledge of how things work.
DW: What’s the most challenging part of the job?
JS: That’s a tough question. Maybe keeping track of everything that’s in flight, especially when you have work that crosses over multiple releases. The big thing is making sure nothing is missed - it’s important that nothing goes in untested – and keeping track of that can be challenging.
DW: Do you feel a great sense of responsibility in that respect?
JS: Definitely. Whenever a defect is raised that didn’t come from our team, I always wonder why it wasn’t detected by us. Usually it’s environment-specific to whoever’s raised it, but sometimes it happens, and we update our tests to try and catch it next time.
Click here to find out more about Sparta's Test Engineering roles.