Please rotate your device

Interview Mirjana Kolarov

Mirjana Kolarov is a Test Architect and Department Manager at Levi Nine. She is also Co-Founder of the first testing community in Serbia, called Test’RS Club. Mirjana was a speaker at the European Testing Conference in Amsterdam on 19-20 February. We spoke to her about the changing role of testing, what’s new and exciting in this area, and how it might develop in future.

What was the main topic you focused on during your talk at the European Test Conference?

I talked about my experience with monitoring in production. Believe it or not, just a few years ago I wasn’t really paying that much attention to what was going on after we released to production. Along the way, I realized that feedback from usage is crucial and it is important to get information about the system behaviour after the release. To the point where now I’m a part of a team that is actually keeping the whole platform stable, through constantly monitoring what is going on in production, after the release of new features.

Another thing I talked about was having a team that is diverse and encompasses different perspectives. I strongly believe that that enables you to find out more and test more. As testers, we’re curious by nature – we like finding bugs and problems – and seeking them out in production is actually even more exciting than during the development phase.

And especially now, when we want to release and develop something fast – because time to market is crucial – we don’t always have time to thoroughly test as much as we’d like. So releasing and then closely monitoring helps you to release faster overall and still take care of the product quality.

How did you end up being in your specific role and team?

I was part of a regular developer team that was about to release a new platform. Right before that, I had a feeling – what will we do after the release? Will it be okay or not? It made me realise that we needed to monitor more and better monitoring tools. And doing so after the product went live seemed like a natural evolution of what we do – having a dedicated team to keep taking care of it, like you would take care of your baby.

On that project, we started off with a team of four-three architects and one senior developer. Not just to monitor the production, but also to learn from it – from the tools we had in place. And also, to include improvements on performance and functionality of course, but also around the architecture itself.

Why was testing an interesting area for you?

I think it has to do with the fact that you’re dealing with the actual, raw, unfiltered feedback. In technology, we don’t necessarily deal with the users’ direct reactions – but with testing you can get as close as possible to that. And of course, when you create something, one of the most fascinating areas is monitoring how people are actually using it.

At the conference I just attended, someone spoke about motivating teams – and that if you wanted to inspire the people building a space rocket, you need to take them along to the launch. What we do is about as close as you can get to being there at lift off.

What would you say are your team’s most important goals and responsibilities?

Ultimately, our goal is to take care of the system architecture, and, when adding something, not jeopardising everything else. At the same time, our role is also to think about improvements – for instance, on our own platform we’ve managed to start doing releases without downtime, and during work hours – so we can release faster, and more regularly.

Of course, we have lots of ideas all the time – the main challenge is making them happen. And if we want to improve something from a technical point of view, first we have to convince the product owners, whose priority is the business. Somehow, we must explain to them the business value of a technical improvement – they’re not developers, after all.

We can’t make them understand technology better – but what we can do is try to understand the business better ourselves, talk to them about what we’re building and why. We can also research the market – to understand the whole business end to end. That’s how I believe we’ll get better at continually improving what we do.

Do you have any advice for others yet to adopt monitoring and testing in production?

On some projects, monitoring production might not be available. For instance, if you’re working on bank software, they’re not going to let you monitor transactions, etc. So it does depend to some extent on the project. But the bottom line is, if you have the option of setting it up, you should. And not just monitoring the application, but the infrastructure too.

If your team isn’t doing any of this, or there’s a lack of tools to do so, then whatever your role, if you think it’s important, my advice would be to sit down with your team, and say ‘I hear it’s useful, why don’t we use it’? If you’re not an expert in the field, it might seem tricky at first – but read up and maybe even try setting up discussion sessions.

For some, it’s part of a larger cultural change among ourselves and our clients.

How do you see the role of testing changing in future?

I’ve been in testing for 10 years now, so lots has changed already in that time. At first, we were just doing manual testing, not really in contact with either the business or users. The developers just threw it over the wall. Initially, it wasn’t that challenging. But since then, it has shifted to the left – now we’re there from the first line of code, with testers included in design phase, and everyone is more aware of the importance of what we do, even developers. Also, testers have become more focused on performance and security, so it’s not all purely functional either.

In future, I think what we do will shift more back to the right – without moving from the left – effectively, our function will stretch out. Sometimes we’ll just test on production, but we should be the ones to propose it, and find a way that we can access that functionality. In other words, building a continuous deployment pipeline. That is definitely something testers should be a part of.