X

What led you to become a Tester?

I liked IT in High School, and when an Apprenticeship came up in it, I thought, basically, I don’t want to go to university because I don’t think I’m that kind of academic, so I wanted something to learn on the job.

I enjoyed IT and started off in a Developer Apprenticeship and then got asked to join a team doing some testing. And that’s basically where I started, from there.

What are the most common methods of testing that you use in your role?

Generally, User Acceptance Testing. That’s generally the most common.

So obviously, you use that – it’s been defined – precisely what the customer expects fundamentally. And then, as a Tester – you take those Use Case tests and break each of those down into positive and negative tests.

Your positive test will be exactly what’s written as the Use Case – that’s like a happy path. And then you’ve got to think, for each individual one, what’s an alternative way I can do this? What combination, or functionality part of that can I potentially do that a Developer might not have thought of, to potentially break that Use Case.

That’s the most common, Use Case Testing.

Also, there’s Regression Testing.

After all Use Case Testing is complete for your tickets - which come at the end of the sprint normally - you’ll execute targeted Regression.

So, changes that are made around, for instance, functionality ‘a’, ‘b’ and ‘c’, your targeted Regression will mainly be aimed towards all functionality that touches functionality ‘a’, ‘b’ and ‘c’ - so you don’t waste time testing functionality ‘z’, for example. If you’ve got the time, great, but it generally doesn’t work like that.

What are the most common issues you face?

As a Tester, communication probably.

It’s not necessarily about defects found per se; it fundamentally depends on the Developer.

It’s a three-way thing.

For example, in my experience, some Devs haven’t understood the Use Case in the same way the Tester might have. So, that can lead to them coding a certain way, and then the Tester comes along, thinking they will test it in a certain way. And that’s why communication between Dev and Tester and call it BA (Business Analyst) - who has written the Use Case, or the Jira ticket, whatever you use – is crucial.

That’s why, in my opinion, the Three Amigos is important – where a Dev, a Tester and a Business Analyst usually sit down together to make absolutely, abundantly clear what the change is and each Use Case. So yeah, I’d probably say that’s the more complicated bit.

What makes a good Tester in your opinion?

I would say the most important one is communication.

It’s not even necessarily your ability to find defects. Obviously, that’s crucial for you as a Tester, but fundamentally, a Tester is pretty much criticising a developer’s work or critiquing. Not maliciously - we’re looking for things Developers potentially haven’t thought of or if what they’ve produced is working as intended. How you handle that communication makes or breaks a Tester.

I’ve worked with Testers in the past, who are basically incredibly finite and detailed – they’ll think of every possible scenario of functionality – but how they take this information back to Developers can sometimes cause arguments. It creates an unpleasant atmosphere because if the critiquing side isn’t done correctly, the role’s communication aspect is undermined, impacting the overall progression.

So maybe, instead of just raising a defect and throwing it back to the Developer, going, ‘Right, it doesn’t work’, you maybe schedule a call to say, ‘This is the Use Case Testing. I will walk you through my steps to reproduce what I think is potentially a bug, and then you can then agree with me or not, checking if we’re on the same page here?’.

This is before you raise a defect because then you can generally agree on whether it is a defect. If you’re still at odds with the Dev still saying it’s not a defect and the Tester saying it is a defect - then you bring the BA – who’s written the original Use Case – and they can be the deciding factor, who says either, ‘you’ve tested it incorrectly’, or ‘yes it is a defect’. So, it’s all just about communication.

My next question was, ‘What helps you perform your role effectively’, but from your previous answer, I’m assuming that’s good communication?

Yeah, communication and trusting in your own knowledge and expertise, basically.

You know, with years of experience, you generally have an idea of what Developers potentially forget, if that makes sense? So, happy path stuff is easy – you rarely find a defect in happy path stuff.

However, it does depend on the Developer. It’s not about a Developer doing the Tester’s job for them; it’s a sanity check – to make sure what you’re giving to Testers is of a half-decent quality. So, yeah, sanity check – is this holding together? – ‘Yeah, great, I’m happy with that; I’ll give it to Testers’. Our job is to ensure the happy path, but then we must try and figure out all the negative tests around it.

How has testing changed throughout your career, whether for better or worse?

In all honesty, from my perspective, it hasn’t really changed. You get these periods where – so when Automation emerged or became prominent, everyone was excited about it. ‘It’s amazing, who needs Testers when you can just Automate everything and that’s all we need’. But it would help if you had that human element to resolve some of the issues we face as Testers.

Is there anything, from your broad experience, you would communicate with a Developers as a Tester?

Try and communicate at an earlier stage. The earlier you do stuff and sort stuff through communication – Dev, Test – it saves time, money and the overall process is better. And obviously, don’t throw stuff over the wall to the Tester that you’ve not even double-checked first.

In your career, how much of testing utilises automation – not necessarily just yours, just in your overall experience within the industry?

Well, in the ten years I’ve been around it, maybe two places have done it. And it was only in the form of Regression packs. And even then, I’d say the most I’ve ever had a split of automation to manual in any role is 20% automation, 80% manual.

What are your thoughts on the future of testing?

At one point, I thought if I didn’t learn automation, I would be out of a job. But I’ve been thinking that for ten years, and it just proves you’ll never remove the need for skilled, manual Testers.

Automation doesn’t give you the thought process behind positive, negative, boundary testing, skilled regression testing, and smoke testing. Automation is a tool to be used in an arsenal of testing, but it’s not the be-all and end-all. I think that’s what I’ve learned from my experience of what I thought it would be. It really hasn’t happened in my experience. And I don’t think it will to be quite honest.

Are your thoughts similar then, with the use of artificial intelligence in testing?

I have no opinion on it. It’s bad, I’m not up to date enough with it, I won’t lie to you.

So, in your personal experience, you’ve not had any experience of that so far?

It’s staggering, that what I assumed was basic, bog-standard testing practices during my apprenticeship is still not implemented at that level in most of the companies I have worked for previously.

So yeah, it’s staggering, really.

You think that everywhere will be ahead of the game, and it’s not.

In many places I’ve worked for, it’s like, right at the start of the whole process – trying to figure it out.