You are listening to QA talks, a podcast for quality assurance executives implementing digital transformation in their organizations. In this show, we focus on the unique pitfalls inherent in quality assurance and quality engineering and how these executives are navigating them to position their organization for the future. Let’s get into the show. 

 Logan: Welcome back to QA talks. I am your host for today’s episode, Logan Lyles from Sweet Fish Media. I am joined today by Paul Trotter. He is the Deputy Chief Technology Officer over at Atom Bank, and also our co-presenter today, Nanda Padmaraju, the Senior VP at Cigniti Technologies. 

Gentlemen, how is it going today? 

Paul: Hi, thank you so much for having me on the show. It’s great to be here. Hey, Nanda.  

Nanda: Hi Logan. Thanks for having me. It’s a pleasure to be a co-presenter along with Paul on this podcast. Thank you. 

Logan: Absolutely. I am excited to chat with you guys today. For listeners, a little bit of background on Paul first. As we mentioned, Paul is currently the deputy CTO over at Atom Bank. He is accountable for service delivery and change including testing and DevOps. Prior to taking on his current role at Atom, he was responsible for the change in environments. He has also previously worked at Accenture and Capco. Outside of work, he lives in Preston in UK with his wife, two kids, and two dogs, most importantly there. 

And then, over to Nanda. Nanda Padmaraju is our co-speaker for this edition of the podcast. Nanda heads the UK and EU business unit for Cigniti. Nanda brings in 22 years of experience in consulting, advising, and helping global enterprises across domains in their quality assurance and quality engineering transformation.  

During today’s conversation, Nanda will be talking to us a little bit about Cigniti’s expertise, specifically in the banking sector and how his team has helped realize ROI and other benefits for Cigniti clients.  

So, guys now that we have got some introductions out of the way for some context, Paul, I would love to open up the conversation to you, specifically to kick things off here. 

You know, Atom has been one of the early adopters in the banking industry of cloud and thought machine. What are some of the critical factors, and I imagine, both technical and business factors are at play here that cost you guys to make the leap forward, ahead of some of your industry peers?  

Paul: Okay. So, thanks for the question in terms of why now, which is quite obviously an important thing because we’re only a young bank. We’ve only been there since 2014. So why would we go for very smart data centers and third parties in to the cloud. But effectively because, it’s so important, the flexibility it gives you. The regulations are now far more comfortable with it and with the speed of change. To get control about changes and get within the cloud is absolutely critical. So, you’re able to scale up and down based on customer demand. In the past, we have been hit by challenges around things like self-campaigns with few of the best banks. Why thought machine? Well, thought machine is cloud native. If you are going to move to the cloud, you don’t just want to move your data center. You need to move your products and your components to actually cloud native so you can then utilize the features as part of it. So that then you can work through the pace of change. But it’s really important under the market now that you’re nimble. So, before we build bigger and bigger offerings, the best thing for us to do, particularly for the regulators are now is to move into the cloud at our earliest opportunity and basically bring Atom bank back into our bank itself rather than being delivered through a number of third parties. 

Logan: Yeah, that makes a lot of sense about looking at your move to the cloud very holistically and you make a great point there about the business factors, the flexibility, and scalability that the cloud brings. So also, you know as and your current role as deputy CTO at Atom bank, Paul, can you tell us a little bit about your view of quality engineering across the software development life cycle. 

Paul: Yeah, absolutely. So, I mean, quality engineering is very important, particularly in a bank. Everything that goes live has to be stable. It has to be secured, number one, and has to work. So, in sort of the old world of data centers and everything else, culture, quality engineering, and the waterfall models meant that I had to pretty much work towards the end of the cycle and it was very difficult to move ahead. And now, we are utilizing the cloud, utilizing natural pipelines that I could build on to my DevOps team. Effectively, I can think of all tests not just earlier, but I can just make it continuous. So as soon as people integrate testbed, I can instantly start testing for that to be functional and non–functional testing. And it all went to that so that I can get defects out early and start proving and understanding actually what I meant when I wrote down those requirements. So, from a software development lifecycle perspective, we need to be careful about methodologies and what is really important. DevOps is part of the cloud. The environments that open up to as much as we’d like enables you to effectively shift left from both functional and non-functional perspective. So that you can truly do very short sprints, all the way through production rather than short spreads that then stop and then get formed into some big monster release. 

Logan: Are there a few specific initiatives that you could possibly speak to, Paul, to bring this down to the very tactical level that others might be able to learn from – where you’ve helped drive adoption of the agile methodology, as well as you know, made quality an integral part throughout the process. Like you said, moving it earlier into your own processes. 

Paul: In terms of quality, it’s really around automation from a quality engineer. So, it’s a turn around the predictability. It’s about building the regression test early. It’s about actually being able to have a fifteen–minute test when you go and integrate it into the branch. It’s about going about taking the ten–hour test if you get it overnight. However, it’s more than that. It is about the fact that I’ll never have multiple environments that are not identical and built the same. That means I can then go on and execute multiple parallel items of testing that are functional and non–functional at the same time to go and prove to us that actually that change that’s made the right difference and no additional differences. So, it is really the key about it going forward, and it is how from a test predictive perspective. You could start using analysis and additional data points to then decide actually what really matters. . For your test you can do it in the right order rather than just saying I’m going to go and do a 200 tests. 

Logan: Paul that makes a lot of sense and I appreciate you sharing some very specific examples there. 

Nanda, if we could kick it over to you for a little bit from your perspective from the Cigniti side. You know Cigniti works with several well–known clients in the banking sector. I would love to hear your thoughts on the role that QA plays amid banks who are embracing digital transformation and move to the cloud and these other factors that are going on, as Paul has described a little bit within his organization. 

Nanda: Absolutely, Logan. Challenging banks like Atom, which is a digital-only bank are pushing the status quo and setting newer benchmarks in not only adopting the latest technologies but also accelerated time to market. So, this is forcing legacy banks to accelerate their own pace of digital transformation.  

So, as you know, every bank today has an app for its customers, both on iOS and Android. The customer is oblivious to the fact that there are legacy applications running with most of these banks, well–known banks and expects a superior customer experience for all his or her transactions. Customers have zero-tolerance these days and can quickly vent their anger on various social media platforms.  

In this backdrop, testing the functional and non-functional aspects thoroughly, and as Paul rightly said, embedding quality engineering early on in the lifecycle is extremely important and imperative for the banks to succeed in this digital age. So, QA and QE are the top order in terms of a CTO or a CIO level risk in today’s board-room meetings.  

Logan: I think you know whether you’re in the banking sector or any other industry you know the point that you make their Nanda about the expectation for a frictionless customer experience is there across continents across industries throughout our lives today. So, I love the connection that you’re making there between QA and QE and the customer experience and the very tail end of the process which obviously has major business implications no matter the size of your organization. I love what you’re talking about there Nanda. 

Paul, back over to you real quick. You know a lot of IT leaders are really faced with this conundrum and they feel like they either have to choose quality or time and they have to prioritize one or the other. From what I’m told you’re a strong believer in quality and speed. Can you elaborate on this a little bit further on the impact of embracing the reality that you can actually have quality and speed at the same time? 

Paul: Sure! So, in terms of actually quality over time in the legacy world of data centers, a limited number of environments, where it takes a long time to implement change, you have largely got no choice but to go with quality, because if you get it wrong, it takes such a long time to then go right, trying to fix it. Unless you are forced to go by time, you really have to purely go by quality, and it has to work the first time.  

The challenge then is, by the time it goes in, it is quite possibly irrelevant, or it is just everything else has moved. Quality at speed is really where we need to go and actually where we can go now with the cloud, with true agile, with DevOps, with quality engineering and the concept underneath it. Because we want something, and we don’t know exactly what it is going to be like. We know what it should feel like. We need space to go and implement that quickly, and then tailor it and then just keep on tuning it effectively. Rather than making changes which are big and cumbersome and takes too long to do and like it to be pro.  

If I can turn things, it would be far quicker in the best case. I can do them within a day. Best case or actually even in the worst case, I can do it in a 2-weeks expense. And every time we got some tangible benefits and then the customer can give me real feedback. So even if I thought about the best analysis requirements right at the beginning, actually, I now know for sure now I do. Even if they are not as fully documented because they are now fully tested and fully use tested by the customer, the client is going to touch this and use it on a day-to-day basis. So, quality at speed are only possible, though, if you’re actually confident around wherever the changes have been made what the impact of those changes are, and actually what the likelihood is if any issues are born, and the fact that if there was one, you can fix it instantly. And, that’s why it’s fair. 

Logan: Yeah, that makes a lot of sense Paul. You know as we’ve been talking about, not just with Atom though, but banks are finally embracing and moving to the cloud. Atom has successfully migrated to Google cloud platform. HSBC is another major bank that has started its migration started migrating its workloads over to GCP as well. Can you tell us a little bit how this is helping you from a quality engineering perspective? 

Paul: Sure. So, from a quality engineering perspective, what really helps in the non–functional perspective and in the actual ability to run things in parallel, because historically environments take a long time to stand out and not likely bringing clarity between them. So, you can get different test results in each one and the cost of running an environment that’s parallel to production from the non–functional perspective. So, you do scaling, because it just makes it not realistic and because it’s sitting there for such a long period time when it’s not being used. So, given the benefits of going to Google cloud and everything else around it in terms of the tools of such services and everything else is you can instantly standup up an environment. So, depending on its own component you can do it very much in less than an hour. And the full environment end-to-end before we turn to end connectivity to third-parties as well as the components that can build the whole bank in match with 3 to 5 days depending on the complexity around it. But In terms of actually what that really means I can now triage defects quicker and do more parallel activity. I can do more programs in parallel. I cannot be just trying things and hope that they are going to work. We’ll see if they’re going to work. There is constant expense of time and effort. People often goes emotionally attached to it. So, there’s lots of benefits for such as the flexibility only with ourselves. We’re no longer having conversations with a third party and say I’d like you to do that for us, document it. And then they’ll to come back right after. You’ll argue it’s a fill up. Then eventually they’ll do well to schedule some people to go and find to it. And then it comes through at the other end and turmoil that’s happened, which we can be months to three months post. And that’s what kills, that just kills the business because actually they’re not working in technology to that extent. We utilize the technology to grow an end result to that to the customer. 

Logan: I love the way that you ended that there Paul, talking about using technology to provide the end result to the customer. And, you pointed out a lot of things along the way there that are affected when you’re able to do, as you say quality at speed. Nanda, could you talk on this topic of speed a little bit? I would love for you to elaborate a little bit on Cigniti’s test automation framework that helps clients, specifically in the banking industry. Maybe a few examples on how it’s helped to jump–start testing events and deliver solutions more quickly?  

Nanda: Sure Logan, as Agile and DevOps become mainstream, test automation is a foundational pillar, as alluded by Paul earlier. That acts as an enabler to achieve the end objectives. Cigniti has harnessed its experience and expertise of serving clients across banking and financial services sector into reusable assets such as test automation frameworks, test environment health check kits, test data generators, white level testing harnesses. And, all these come as value adds to our customers at the help avoiding reinventing the wheel. 

The IP and the reusable framework that we bring to the table significantly lower the break even point in test automation and enhance the ROI over the life cycle for our customers. And particularly for banking as Paul alluded earlier, moving to the cloud helps them to achieve speed and agility. And without test automation, you would become the roadblock or the dead-end for customers. So, test automation is foundational and Cigniti’s strength is in test automation.  

Logan: Thanks for that Nanda. Paul do you have some thoughts on the tools used for test automation that you want to add here. 

Paul: Some of the tools that we talk about to test in a way where you’re likely to find defects. It also goes from that dev into the ops touch. You know, have you got consistent tools in and does it go feed automatically through that too? So, if you’re going to use things like Jira and confluent within the development lifecycle, then you also if you’re go to use service now or something similar or the products are available within the production world, then it’s kind of how those two areas talk. But, also how they feed back into the test automation and the scope of everything else in your test predicting because you might think you’re doing amazing testing and you only tend to hear about ones and twos in production. But there’s lots of other things that are taking place and noise that you can just go and quickly fix. You need to have our data feeding through that data–driven world. And test is by far the most important things around that data because it allows you to a if you want to be testing whether the customer would use it and also enables you to focus your testing in the areas that are key to everybody or where you think it’s best for them. 

Logan: Yeah, Paul spoke to a lot of the things they can get in the way and slow your progress. Nanda, as you’ve worked with organizations across the banking industry are there a few keys, a few specific benefits that you’re seeing your banking industry customers who have really been able to realize in their QA transformation journey by partnering with Cigniti and what you guys have been able to do for them. 

Nanda: Sure Logan, I’ll pick up four use cases and outline the benefits that some of our customers have derived. Cigniti has global patents and believes in intellectual property and put that intellectual property to use for our customers. The first one is something called CESTA, which is a part of our Blue Swan IP which helps in migrating test assets from one technology and tool landscape to another. Some of our banking customers have requested us to migrate their test assets from commercial toolsets to open–source toolsets. Cigniti is the only company that has this migration platform and we have put this platform to use for those migration customers. This is one benefit that our banking customers have realized.  

And the second one is something called the as sentiment analyzer, this is again an intellectual property that we have. So essentially, this tool that can crawl all the social media platforms, the apps store ratings, and comments by various end–users of these apps and come up with meaningful inferences that are actionable from the quality engineering standpoint.  

So essentially somebody would have rated four for an app on iOS and 3.5 on Android. But the number themselves does not make any meaning from the quality engineering perspective, unless you go through the comments the same person would have said that the app is rebooting itself for multiple times at this point of the journey, and which essentially takes the point of acknowledging it as a bug and putting it into the backlog in our product development life cycle.  

So, there sentiment analyzer significantly helps harness the actual feedback from the end–users into the quality engineering lifecycle for our customers. So that’s another IP that’s been put in use for our customers. And the third one is the faster time to market. So here, as customer and the technology are helping us embrace with a comprehensive test strategy that is tuned towards agile and DevOps and shifting left and shifting right. So, in the current age of DevOps, it’s no longer sufficient that you shift left but you also need to shift right to be able to do the proper handshake with the Ops team. So Cigniti has proven methodologies to embed shift left and shift right into the overall software test life cycle within the DevOps. 

Lastly, continuous testing – this is again something that Paul has cited in his earlier comments that continuous testing aided by test automation framework has significantly helped drive results and benefits for our customers, whether it is launching their app in record time or moving over or migrating from data center to cloud and so on and so forth. 

And the last one is, Cigniti being an independent testing organization, we have tool partnership with various commercial toolsets and we also are a big proponent of embracing open source technologies. So, customers have a significantly benefited from selecting the right tool of their choice at various points in their journey, which suit the underlying technology application and landscape and their own roadmap. So, these I think are the top four benefits that customers have realized after partnering with Cigniti in their journey. 

Logan: I really appreciate that input Nanda. You know a lot of folks when they’re looking for information, they’re looking for what are my peers able to accomplish, they’re looking for those sort of specific stories. So, I appreciate you unpacking those a little bit for folks and speaking to some of the specific use cases that you’ve seen as you work with banking industry customers.  

Paul, back over to you for a second. It seems like there’s been a recurring theme through this conversation about driving value to the end customers. We’ve talked a little bit about removing friction. Nanda was just speaking a little bit about more efficiently gathering sentiment and feedback from end–users and one of the things that you guys have done is implementing smart contracts. Can you speak to the benefit they are driving value for customers for Atom bank? 

Paul: Yeah, sure. So, in terms of a smart contact and to just explain that concept of the contract in terms of effect of a thought machine and our banking platform and it is not the only place where it exists within our stack. Essentially it is using thought machine banking platform than allowing us to do the actual development on top of it using the contract. It is a bit like using excel and then using the sheet yourself on your own formulas then and based on known excel formulas. So that then you can create your own products the massive benefits in terms of speed into how to utilize proven formulas underneath that are known to work and that you can adapt to your product quickly through your own coding which is really the key going forward. You can do that throughout the rest of the stack as well. You got to make sure you’re always protecting your data. But, beyond that you need to know is what you are going to be good at. You’re going to be good at designing the banking products, you don’t need to be good at everything else. You just need to know what how to utilize everything else so that you can go live with that product and compliant and everything else that goes with that. I’m trying to take what happens and test it all in the line of development early and change. I’m trying to make it there in the land of how does that then get affected by what happens in service production.  

Logan: All right. So, Paul, we’ve talked a little bit, you know from the very beginning of this conversation about moving ahead, adopting newer technologies. The cloud has been obviously a big part of this conversation. Can you share a little bit about your methodology through your experience in adopting your technologies but at the same time identifying potential risk and mitigating those risk as you move to newer technologies where you see the benefit to increase quality, increase speed, increase the customer experience as a whole? 

Paul: Yeah, sure. So, in terms of actual technology and technology is so strange because it changes so quickly and particularly as Nanda mentioned, we are a digital-only bank, so we’ve only got the one channel which makes it really really important that it’s always available and got the right services coming off it. So, if any of our integral components change, it’s absolutely key that we can plug and play effectively, and we can utilize the cloud and utilize the services that are available where we work in the most efficient way. We don’t need to become expert at everything. We just need to be experts at the right things and then stay current so that actually the customers can feel and experience exactly as they would be expecting. So, know when you should be using the software and how to configure the software. There is no one you should be bringing a lot within the actual bank itself to ensure that we got the control.  

And, absolutely making certain that the data is used appropriately so that actually the service and the quality and experience for the customer is all improved as you go along. In terms of choosing components, that’s largely based on what’s the real benefit. If what I just made a simple notification service, I don’t need to go to town. If I need actually a far more rich than solution, that’s part of it that I need to look at that as well to. If I’m going to do that, the complexity that brings the whole lifecycle, what will that do to my quality all that due my time. Our houses are actually therefore to be mean to the end. Customer turns at the end to get upon the speed and somehow look and feel of that. 

Logan: I appreciate that breakdown, Paul. As we wrap up today, you know, another common concern for a lot of technology leaders is both recruiting and retaining tech talent. A little bit more tangent from our primary conversation today but I think it is worth hearing your perspective on this as a seasoned tech leader. Can you speak to the landscape and some of the things that you’ve seen effective in recruiting & retaining tech talent, especially as it relates to the culture of your organization & how that can influence either acquiring of new talent or retaining those folks once you’ve got them in your team? 

Paul: So, it turns out actually that the people need to bond to feel like they belong to a family. The whole culture is about actually feeling like you’re empowered and you’re able to talk and explain what you want and give ideas and some little respect. Some of them will help you understand how that works and feels against because we’ve got far more ideas that we’ve got time and money for. But as said in terms of recruitment, what that means is if someone doesn’t feel like they’re going to fit in for whatever reason as part of the interview process, which is really, really hard to do, then we go to the tech every single technology box. So then if they won’t command it, it’s because you need the family to feel like it’s still a family. You need to be able to go and deliver because there’s lots of choices out there, particularly the technology that we’re using. It’s leading edge. It’s interesting, not just within the financial services interests industry. It’s also interesting event. There are lots of other industries, including in the local area around here, there’s clothing manufacturers, there’s governments, there’s gambling, there’s lots of consulting companies that would like to want to take those people on, there are the financial companies.  

So, it is true that people feel they are valued and that they are rightly rewarded. But actually, they also feel like those that they’ve got a place there they can see a future with us. It’s a challenge to keep the more engaged, given all the ideas and think given the pace of change. But in terms of actually that’s for you on the best challenge of the whole on a daily basis, because, you know, there’s people that we at a bank for us, lots, and lots of times over. 

Logan: I love the way that we wrapped it up there, Paul, talking about, you know, the people that are implementing a lot of this technology as we talk about process and methodologies and bringing it back to the people that are involved in how you guys are building that culture at Atom. I appreciate that peek inside the organization a little bit there. If anybody listening to this, Paul, would like to reach out and ask any follow up questions or just stay connected or learn more about Atom Bank. What’s the best way that they could reach out or stay connected to reach out to me or stay connected? 

Paul: They can reach out to me at paul.trotter@atombank.co.uk or just on LinkedIn as Paul Trotter. 

Logan: Easy enough. Nanda, thank you so much for joining the conversation today as well. If anybody listening to this would like to ask any follow up questions or stay connected with you, what would be the best ways for them to reach out to you specifically? 

Nanda: Sure, Logan. Thanks for having me on this podcast. And just like Paul said, I’m active on my LinkedIn as well as on my email. My email is nanda@cigniti.com. And on LinkedIn, if you search for Nanda Padmaraju, you’ll be able to get hold of me. And I’m more than happy to answer questions and stay in touch with the tech community. 

Logan: Thank you. Great. Well, thank you both, gentlemen, for adding some great insights to the tech community today. That wraps it up for another episode of QA Talks. 

Paul: Thanks very much, thanks for having us. 

Quality assurance is vital to the success of an organization’s digital transformation. Lack of control can quickly derail a company’s technological presence, costing thousands. At Cigniti, our resolution is to build a better world with better quality software. Renowned for the global quality thought leadership in the industry, we draw expertise from over a decade of test engineering experience across verticals. To learn how we do it, visit cigniti.com.  

You have been listening to QA talks. To ensure that you never miss ay episode, subscribe to the show in your favorite podcast player. Thank you so much for listening, until next time.