“Every team member is responsible for software quality”: interview with Head of QA at worldwide media resource

In the last decade, the pace of QA has shifted strongly. Now, large companies onboard an army of QA engineers and train their engineers how to care about quality.

However, this leads to an increased time to market. Why? How can we make QA more efficient?

We took up the above-mentioned topics with Dileep Marway, a passionate QA engineer in the past and the Head of QA at the ‘Economist Group’, – our long-term partner providing analysis on international business and world affairs globally – who has been eagerly contributing to the QA community for over 13 years.

Get prepared for the journey called “Shifting QA left.”

At present, companies with software products introduce QA services to the agile lifecycle. From your point of view, what is the main mistake that organizations make while adopting QA practices?

To the present, the software industry is changing at a breakneck pace, so delivering a flawless product is becoming more crucial. This is why companies understand that introducing QA practices to their business strategies is not the wish – it is the need.

In my view, companies make one core mistake – they depend solely on the QA team for assuring quality. Quality assurance should be the responsibility of the whole team, and we should advice engineers how to care about quality. The bottom line is to change the mindset of IT representatives (and C-level being among them) to understand the importance of having time and care when quality comes to mind.

Your opinion: why hasn’t test automation replaced manual testing for 100%?

I’m not sure that it should. It goes without saying that there are several cases when manual testing simply cannot be replaced by automation (while conducting UX usability tests, UI testing, and many more). But I want to highlight another crucial juncture.

I do not actually separate manual testers from test automation engineers. Let me explain why.

If you are specializing in performance or test automation, that’s your specialism, but you are still an engineer who understands the code. This fact is also about the team members and their willingness to grow professionally, develop their skills, and become more rounded in their roles. A squad should contribute to a goal, and there should not be silos in the team, which mean that we cannot release a product, as we are dependent on a particular skillset.

Another step is to clear up that there is no value in automating everything. The challenge now is to do it correctly and wisely to give the most value.

Who is the last one to be responsible for software quality in the company? Why?

Each and every member of the project team or squad is in charge of quality. All team players have to be on the same page and care about the one paramount thing – delivering a top-notch product to the market.

This irreversibly results in more calm and friendly social and psychological climate in the crew. Being respectful to each other, being humorous and proactive – all these qualities help everyone in the team contribute tremendously to the outcome.

How has Agile methodology changed the attitude of IT representatives to the QA process?

Agile development practices have provoked to shift testing left and significantly changed the world of QA. Some time ago, software products weren’t even shipped to the end users until the business need was validated for years.

Agile drives long-drawn-out processes towards continuous delivery while QA helps build strong-quality products in the conditions at an extremely high speed.

What is behind the term “shift-left testing”? Emphasize the benefits it can bring to the product and business in general as well as its main challenges.

Shift-left testing possesses countless advantages, but let me highlight the one that is clearly allocated: the delivery speed won’t be constrained by mistakes slipped up earlier in the lifecycle if you begin conducting checks as soon as possible.

Nevertheless, you shouldn’t forget about the challenging nature of this concept: it is of high importance to meticulously plan all testing and development activities as well as prepare your Dev team to add QA to their skillset. This includes better unit testing and actually contributing to the automation product.

Please name a few tips on how companies can leverage from CT to enhance the quality and speed of delivery.

By adopting test automation at each development lifecycle stage, CT can easily define the business risks concerning each potential release version. Due to that, bugs are fixed at the right time.

Tests should conduct smart checks and use modern technologies to get better automation benefits. They should also be supported, revisited, and updated so that each team player will understand: if the tests showed 100% passed entries, the build can go live; if there is a failed check – a defect needs to be fixed. This allows us to continually release and makes quality at the heart of every role in the team.

What similarities and differences can you name between the approaches of CT and shift-left testing?

To my mind, these concepts share more commonalities than differences. Both of them are considered to be vital approaches in the world of QA.

Continuous testing entails all processes starting from shift-left testing, so they do not exclude each other. When implemented properly, they can help launch a strong product several times faster.

They offer some differences, though: shift-left testing spotlights on checks conducted at the earliest opportunity when the engineer is creating the product. CT contends with a more refined software version and can be carried out at every SDLC stage.

Hence, the issues unearthed while performing continuous testing and shift-left testing can be very different.

How can the company bring these concepts together to test continuously and shift the testing processes left?

To combine them effectively, one should first realize why they should be merged and then identify the main goal. Try to coach engineers on quality processes at code level, put the engineer back into QA engineer, and get the whole team to contribute to the automation product.

Dileep, thanks for sharing your opinion with us!