The agile working style is disrupting traditional approaches to delivering software quality, allowing organizations to keep up with the fast development pace, ensure business continuity, and improve operational efficiency. A specific role in this process is dedicated to quality assurance.

Through the mature culture of excellence, it’s easier for companies to ride the wave of innovation, accelerate time to market, and minimize production failure risks. But how to build this true culture of quality? How do we seamlessly embed QA practices into the Agile environment, and how can automation enhance testing capabilities?

To answer these and many other topical questions, we took an interview with Dileep Marway, an experienced QA engineer in the past and VP of Engineering and Quality at SHL ― a world-known developer of data-driven talent acquisition and talent management solutions that help businesses maximize their people’s potential by building agile, highly flexible teams.

With around 13 years of contributing to the QA field, Dileep regularly gives back to the IT community by writing content to show the value of QA for releasing sound software. This time he produced the series of articles “Agility and speed: Supercharging your business strategies with QA” for a1qa that we’ll talk about today and share with you all very soon!

Dileep, please tell our audience some words about yourself and how you got to the position you are in today.

I’ve worked in a multitude of roles, and quality assurance is where I started. Essentially, I’ve been doing digital transformations at different scales, and a lot of that has had quality at the heart of everything that we do. Making sure that customers are getting the right type of quality and what they expect has been vital.

If I look at my journey in my previous role, I accomplished digital transformation for a startup-type team in central Birmingham, UK, and most recently, I’m doing a digital transformation for an enterprise-type organization at SHL.

Thank you for introducing yourself. Why did you choose to contribute to the quality assurance field?

I started as a graduate tester, and the main reason for that was generally I was very structured in my approach. I initially studied pharmacy at university, then I moved to Computer Science. I always go back to that structured scientific approach, as it has suited the quality assurance realm well.

I was very passionate about quality when I first joined, but for me, to be more rounded as a QA engineer, I needed to understand the other areas of the software development life cycle.

In my career, I have worked in production support, in product, in delivery, and I was Head of DevSecOps. As a QA engineer, it’s good to understand the other areas very well because it’s good to collaborate and improve processes as a whole.

Quality cannot be achieved just by one person; quality has to be reached by a team.

We know that you give back to the IT community and write content to raise the awareness of QA value for the business. Could you, please, briefly introduce the series of blog posts for a1qa that you’re working on right now?

Sure. Luckily a1qa gave me this opportunity, and it’s very kind of them. I enjoy blogging, writing, and helping others. I’d like people to help each other because that’s how we all level up ― and everyone can get to their destination.

The first blog that I did was on Agile QA. And this is a very important subject because everybody wants to go fast. But essentially, it’s key that we go at a speed and follow users’ expectations. As an example, if a client wants a car and they want it to be red, they expect the car to be red at the end of the week, not for it to be blue. In this article, I’ll share tips and good ways of working that a QA member can contribute to being Agile and contribute to the output in a team.

The second article was about the culture of happiness. Why is this important? It’s key in any type of digital transformation, whether it’s quality, engineering, or DevSecOps, culture should be at the heart of everything that you do. I always say: “If you are in a happy team, you have a good output of work.” And if somebody wants to go to work, they are happy and will be doing a good job.

And then the last blog is on automation. This is essentially talking about automation, what is the value, why people automate, and also what aspects you need to do before you jump into automation.

What I’ve seen in my experience is that everybody wanted to automate but wasn’t quite ready. There are certain things that they need to do before starting to automate because otherwise, once you do, it’s a bit like if you buy a house that has leaky plumbing. And you are just trying to fix the pipes all the time, whereas you should be checking them before you buy the house in the first place. So, that’s a nice analogy that I like to use. And in the article, I’ll be covering that.

Good examples. Thank you! In your opinion, why should companies go for independent software testing instead of in-house?

My experience is that firstly, it depends on the type of journey the team is on. Initially, it’s good to know where you are in the transformation. Are they experienced or not in their QA practices? Is there a collaboration between engineering quality and product?

For me, where you’ve got a team, which is performing poorly, it’s great to bring in experts, learn from them, and say: “Look, I’m monitoring this team, but I’ve got bias because I’ve been looking after them for so long.”

That’s where I found great value in getting independent services. The experts can come in and independently review your company, provide an unbiased view, and make recommendations on what they would do because they know best practices and worked with other companies, maybe in a similar area.

In addition to telling you what is right, they can also say, “We can give you expertise in this area, which can fill that gap.” Whereas recruiting yourselves in-house, you have to go through a transition of training. Even before recruiting, find the right candidates, and then actually go through a transition. Maybe, if the time is there, it’s good to do both in parallel.

So, work with a testing partner, hire internally, and the two work together. But generally, where deadlines are short, stakeholder wants things quickly, stakeholder wants to see the value from the project quickly.

I think it’s a good idea to get specialists’ help – that’s where a testing partner really can excel.

Absolutely. As you’ve mentioned, one of the blogs is devoted to culture. In your opinion, how should the company train its employees to build a true culture of quality nowadays?

Firstly, there’s the culture on the people’s side, and that should be set throughout the company.

If you go to the top from bottom or bottom to top, everyone should have the same vision. They should talk to people with respect, give constructive, not destructive criticism, and respect your peers.

And there should be a level of psychological safety. If you make a mistake, you can learn from this mistake. That’s the first side that is very important. From a quality perspective, engineering, QA, and those in product roles need to work as one team.

What I really like is that QA isn’t just owned by an isolated QA team. You can run your automation pack, you’ve got engineers who are following TDD and unit tests – and that gives time for QA to specialize. For instance, QA is very good at exploratory testing, and you can add this niche skill, and the team can work together.

In a good culture of QA, they would say: “As a team, we’ve dropped the ball, but to learn, we’ll do this better.” That’s what I mean when I say a culture of QA. It’s more of a collaborative team effort to get something right.

Thank you for such good points. If you speak about Agile, from your professional experience, does Agile need QA, or does QA need Agile to ensure high-quality software?

It goes both ways. To operate in a DevOps culture, you need quick feedback. But how can we get it? The answer is QA.

You need test automation, great performance, and security tests. There’s always going to be a quality need, and the team requires processes in place at speed so that they can move in an Agile way.

For me, when people say that to go fast, they don’t need QA, I’d say, “QA is as important as having engineering in Agile. You need all your key team members there to succeed.”

If you turn to digital transformations, can they be successful without an Agile approach today?

For me it depends on the organization type and its maturity.

For instance, I worked on major projects where you need such a structured approach that operating in an Agile way is quite hard to do if you haven’t got the skills, the team, the right architecture, and processes.

What I found recently is if the architecture has been created from scratch or the engineering has been built from the ground up, then you can go with Agile in mind. But when you have legacy systems, sometimes you have to take a more pragmatic view.

And your advice on how to embed QA in Agile to ensure confident and secure digital transformation?

I’d say you do want QA to be introduced as early as possible. What I find very important is how QA gets involved in Agile ceremonies, so is QA asking the right questions? Asking the “how,” asking the “what.”

What would I do if I was in a session? I’d ask what the impact analysis is. I sit with the engineer and say, “Can you show me, which other areas of the application are impacted by this change, how are you making the change at a code level?” At the same time, I’d start to run my test cases, and I’d think outside the box.

As an example, if I’ve got a username and password, would I just put the right username and password in? No, I’d put characters in the username, I’d put emojis in it, I’d probably put some SQL code injection in it. So, for me, it’s the initial mindset and the investment that you put at the start of the software development life cycle.

When you get to the part where you’re running, you can meet the Agile processes because you’ve thought further ahead of the game. Initially, it’s difficult because it’s still slow but once you start understanding what to test, and what’s a high priority, then you can start to use automation.

Automate the high-priority test cases that matter to a user first. And then run these test cases in an automated manner regularly. The more you run, the better, because you get fast feedback. You find out how flaky your tests are, and whether there are any false negatives in the tests. The same is with the code, the more regularly you run it, the better because you know that something is broken.

So, if you’re a part of a DevOps culture to your engineering and your QA processes, essentially, the team will start to move in an Agile manner.

What should companies consider before introducing test automation, and why does this accurate planning matter?

The mistakes I’ve seen in the past have been automation for the sake of automation.

• But why do you want to automate?
• What are you going to automate?
• What business value will this give to your customers?

First, assess what you are automating. In general, if you don’t have your test cases listed or you don’t know what they are and what your first priority test cases are, you’ll probably automate a piece of rubbish. And then you’ll just be maintaining that forever with no value. Once you know what you need to automate, collaborate with the product team.

They can help you and say: “I don’t think that’s important, why haven’t you thought about this?” Or “You put it as a priority three, and it’s actually a priority one.” So, collaboration is the key.

Now, when it comes to implementing automation, the framework and the programming language, for example, should be in your sweet spot. If there’s a unison of the language, then everyone in the team can contribute.

Multiple people engaged is crucial, because your automation pack should be seen as a product in its own way. If an engineer created it, it can still be of the same type as a QA engineer or automation engineer.

Once the programming language and framework are set up, there would be a roadmap to say, “I’m not going to implement this.” Then it’s important to run automation as frequently as possible to give you data to ascertain whether you’ve automated the right things, whether they’re giving you the right results, whether the tests are flaky, and whether they are finding any problems. It’s the initial transition.

What I normally find is people jump into that last step which is to write code. But people need to walk before they can run, which is what I would recommend.

As we know, test automation cannot fully replace manual testing. From your point of view, is it possible to determine the percentage of QA activities that should be automated?

I think it’s hard to put a percentage on it, mainly because it depends on the priority. If people are doing so, they would start to automate concepts that don’t add any value.

As an example, if we automate something and it takes 2 seconds to do it manually, why not test it manually as it takes far longer to automate it, and it will take longer to get the value back?

Or if we’ve got very complex functionality where a piece of code has dependencies in 20 other areas – if we automated it, what confidence would we have that it actually tests everything? That’s where the value of manual testing comes in. And the value of somebody doing this priority testing will come in.

I don’t really like to put a value on it. For me, it’s more for what you’ve automated, why have you automated that percentage, and why you’re not doing the other 40%. If somebody can answer those questions, I believe that’s the better way of answering it rather than just a value.

Dileep thank you very much for this interview!