A Q&A with Jonathan Ross, Israel's Head of QA at Just Eat Takeaway: from kibbutz farmer to QA in the metaverse

This week we talked to Jonathan Ross, Head of QA at Just Eat Takeaway. His path to QA is wild: from Kibbutz farmer, to leading QA in the metaverse, to now running a QA team at Just Eat Takeaway, the leading global online food delivery marketplace.

So, what’s it like being Israel's Head of QA at Just Eat Takeaway?

The way I describe Just Eat Takeaway is that we are the AWS for food deliveries. We power the behind the scenes of food delivery apps across the world.

As Head of QA, I help support all our Israel site QA, train them, and make sure they have the right tools. I also help all our QA teams get to the same standardized processes and to resolve anything that's blocking them during their work.

How did you get into QA?

My first experience with QA was when I was a farmer on a Kibbutz. I broke a Leatherman folding plier, fixed it, retested the break and tested irrigation software. Being a farmer is not just sitting on the tractor!

Then I worked at Ben-Gurion airport on the Ben-Gurion 2000 expansion. I had a boss who said to me, “I'm going to Canada for a month. Here's the software that's been built for us. When I come back, I want you to tell me if it works or if it doesn't.” That got me into the idea that testing was a formal profession and introduced me to the discipline of testing. I got very interested and started reading up on it.

The most important thing however was that around that time, I met my wife. She was in QA, and she helped me get into QA at startups. So she was probably the biggest influence. It was a start-up romance story. What can I say?

What's one thing you swear by in your work as in QA?

Soft skills like negotiation. My friend who is a recruiter said to me, "I just placed someone as a QA lead. What book should I get them?" So I sent him the FBI's hostage negotiation manual link. He was like, "Why did you send me that?"

It’s because the hardest skill they're going to have to learn is to negotiate. In QA, you’re going to have developers saying it doesn't reproduce on my machine. You're going to have Product saying this isn't a priority now. And everything that we do as QA Leads or even testers is very negotiation oriented, basically marketing why we need to fix things.And learning how to do that from a positive place is super important.

I am also a big believer in the whole idea of Shift Left: getting QA involved as early as possible. The idea is to have QA on the ground floor of every project, so no feature arrives at QA without QA knowing what to expect, and already having created a test plan based on requirements, reviewing documentation and designs. That helps teams move fast and not break things.

What is the key to a productive QA team?

Communication and collaboration, and not just within the team, with the developers and the product team as well. Having matched expectations of what you're going to do and when you're going to deliver it.

What are some tools you’ve discovered that you can't imagine doing QA without?

When it comes to API testing, you've got to have Postman and Swagger. You can probably manage with just one or the other. I'm a big fan of Postman. Postman has something called the Postman Interceptor for your browser that allows you to capture web session traffic that you can then replay back in Postman and use to build your tests.

Another great QA tool is Testim.io It’s an amazing tool. It's low code/no code for web automated testing. I just had a tester on my team who just started using Testim.io, and it has motivated them to learn Javascript to start writing custom test code next. That’s great to see. Testim is definitely a gateway to automated testing, because it sucks you in to want to learn more and see what its limits are.

For QA testers reading this who want to learn Javascript and get into automated testing, is there a course you recommend?

It's very much whatever speaks to your learning style. Some people prefer to watch YouTube videos. Other people like to read an actual book. Other people like sites where you learn a bit, and then you do an exercise. So do what works for you, there's no shortage of courses out there. One recommendation is if you go to the Applitools site, they have something called Test Automation University that has great courses.

How do you think about QA <> developer collaboration?

I'm a big fan of working in pairs and encouraging developers to give us feedback about whether the bugs we are sending are useful to them.

Different developers prefer different ways to receive bug reports. Some want to watch a video, some want to run the tests themselves, and others just want bullet points with steps to reproduce. Developers and QA can find a good system that works better for them if they work together and give feedback.

Sometimes QA will have an idea but will need to teach the developers how to use the new way. One time a tester on my team introduced a developer to HAR files so they could debug network requests — once they did that, the two of them could talk about and solve bugs much faster.

QA is very much about providing a service. You have to figure out how to provide that service in a way that has the most value.

What’s one tip for how to write a better bug report?

Bug reports shouldn’t be as long as War and Peace.

One time a tester on my team was writing very long descriptions of bugs. So as an exercise, we had him use Twitter to craft his bug report descriptions to keep it under 140 characters. It made a huge difference. There’s no point in writing so much if it’s too much for someone to read. If it has to be so long, it’s probably not just one bug, it’s probably a block of bugs.

What was it like to be QA lead at MagicLeap, the AR headset company?

I worked with the computer vision team in Israel. It was incredible. Augmented reality is the nearest thing we have to magic.

We had robots that would simulate motion and rotation of people's heads to do basic tests, but to actually run advanced scripted automated tests in the headset wasn't possible then, so I had to do very manual testing. One of the things that I did to test persistence and sharing between devices was create a virtual gallery of a lot of artwork and videos inside our 2 floors of office space in Sarona Tower.

I ended up being the person who spent the most hours of the day in the company wearing the MagicLeap headset. So much so that Health and Safety contacted me.

It was very different than other QA roles I’d had. I found myself working with people that have PhDs in computer vision, machine learning, material science, you name it. Before then, I didn't have much experience with PhDs. The first bug review meeting I had, we were going through the bugs, and they were asking me to justify them, like how PhDs have to justify their doctorate. If they asked me how bad a bug was, I needed to quantify it. I learned to gather data on every bug. Sometimes we spent a month deep diving and researching just one major bug.

One funny thing I discovered hiring a QA team for an AR/VR company is that about 10% of people get nausea from being in VR. I had to ask that in the interview process. But after hiring a new tester who felt ill on his first day from being in VR, we did some research and it turns out that MIT discovered that it's because you don't see your nose in VR which skews depth perception. So we had the artists add a virtual nose for our QA team to see if it would help. It didn't help a hundred percent, but it was definitely better.

What else might people not expect about doing QA in the metaverse?

The idea is that this is eventually going to be our primary device. People don't always think in that frame of reference, they think, oh, this is very cool, but it's going to be for gaming. The goal is to get to a point where we have this within glasses.

This technology still has evolution to do, but this is a moment where a lot of people are trying things. At one end, you have Snap with their glasses, and the mini drone. Imagination is the limit.

There are still so many questions about what this all means. But in QA, that's our job to ask questions. For example, what are the ethics? Like, if you have an augmented reality art gallery and someone comes in and leaves rude comments in AR, can you moderate?  

When we test, one of the things that we should be testing for is not just pure functional performance, but also the real world ramifications: how it impacts people.

That's it! Hope you discovered a new tool or some inspiration. You can follow Jonathan and his work on LinkedIn or Twitter.