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’m your host for today’s episode, Logan Lyles with Sweet Fish Media. I’m joined today by Aimee Bechtle as well as Cigniti speaker. Aimee, Cigniti speaker, welcome to the show. How are you both doing today?

Aimee: Doing well, thank you for having me!

Cigniti speaker: I am doing good Logan!

Logan: Awesome! Aimee, a brief intro on you for our guests.

Aimee Bechtle is the head of S&P global market intelligence, DevOps, and cloud platform engineering enablement group. Aimee has extensive experience from being a transformational change agent and has deep perspective on how to make technology and culture transformations actually successful. Aimee specializes in Agile-DevOps in the cloud in highly regulated financial environments where speed must be balanced with security and compliance.
Cigniti speaker, has been instrumental in enabling enterprises across diverse industries to effectively undertake business transformation initiatives with a key focus on quality engineering, assurance, and transformation.

Aimee, thank you so much for joining us today. Obviously, a wealth of knowledge that you bring to the show for listeners. In your experience from driving DevOps transformation, could you speak a little bit about some of the trends you’re seeing in the changes, the evolution of DevOps over the last few years?

Aimee: That’s a great question! I’m seeing more trends to applying what I call the DevOps principles or fundamentals of DevOps, where they’re driving development teams to have operational functions and own the product from cradle to grave, from code commit to operations or production, and seeing the team typologies change and moving beyond just implementing pipelines to changing the responsibility and accountabilities of the teams, and then moving architecture to being microservices, and really decoupling and slaying that model lift to allow them to go faster.

Logan: What would you say, Aimee, about the balance of going faster with security, especially in highly regulated environment? When you hear that, it kind of rolls off the tongue, but then deep work that goes into really balancing those two. What are you seeing there, because it kicks it to you on that point and I know that’s kind of a monster?

Aimee: I’m seeing an increase in tools and technologies that you can bake into a pipeline to stop builds and bad code from going into production. I’m seeing more coding practices and the focus on application security with secure code reviews and educational programs being put in place to train developers on that. And more focus on the Ransomware lately, especially in the cloud and what we’re doing in the cloud to protect ourselves from Ransomware.

Logan: Definitely a hot topic to discuss! You mentioned Aimee that many organizations moving from this monolithic to microservices applications architecture. How do you see this trend in microservices? Where do you see it growing and changing from here?

Aimee: Hopefully, they’re going to start to come out with more products and make it easier to migrate and break down the monolith and get into microservices because honestly there’s a lot of work and it’s a hard work. And if you have legacy systems that have been around for years and you’ve bought other companies and acquisitions, if you have the mixing bowl or spaghetti of systems, that makes it even harder. If somebody is working on that, please reach out to me. But I’m seeing more developing green field, target architecture, and a platform that will allow you to re-factor what you currently have with a plan to take three to five years to strangle out the legacy application, and remove them to the target state architecture.

Logan: Speaking of new tools, Cigniti speaker, I wanted to hear from you on this point, because my understanding is there are a number of IP-led tools and technologies that Cigniti has developed to streamline things. I would love for you to continue down this path of new tools that you see folks are using these days.

Cigniti speaker: I would say that test automation is especially a topic that is considered “nice to do” a few years back and the context of Agile and DevOps. Without actually having test automation into an overall plan, you simply can’t make those initiatives work because you are trying to deliver these incremental changes faster into production as quickly as possible. And to be able to do that, you need a mechanism to be able to test not only the changes that are introduced, but also the entire system. That’s where the whole test automation kicks in. What we’ve seen is in many of the large software projects that are being undertaken, test automation is very critical almost to the extent that without having test automation, you simply can’t deliver this project.
Cigniti actually has all of enterprise-wide or test automation framework that integrates with all those commercial, open-source CI/CD tools out there. So what it does is that it actually provides the base that is needed to build a very robust and easy to maintain automated regression test suite that can be developed by using multiple tools, that can be integrated with CI tools, and has the ability to support multiple programming languages. That’s exactly what we are doing Logan.

Logan: Makes sense! Cigniti speaker, I appreciate that insight.

Aimee I want to kick back over to you as we talk a little bit more about security. You know, a common challenge is setting your application security priorities so that you can eliminate the weakest links first because those are your biggest vulnerabilities. What advice do you have for other practitioners out there about setting those priorities so that you can start working that list from the top down?

Aimee: I think that’s a great question. I would set the priorities based on what our security scanner and something that fortify our white source of what you’re doing and been doing for dynamic security testing is coming back and telling you that you are at your highest risk vulnerabilities from your InfoSec group. That’s how I would set the priorities about what the likelihood is or consequence of that security vulnerability taking place. But you could still have WannaCry risks, vulnerabilities, like you would probably want to focus.

Logan: WannaCry…that’s something I haven’t heard that in a bit,I love that.
As we’ve talked a bit already Aimee, you specialize in working in highly regulated financial environments, so tell me what are some of the things that are just occurring day-to-day for you, where you’re able to find the right balance between them speed, compliance, and security? What are some of the tactical things that you’re doing on a day-to-day basis to make sure that you’re not leaning too heavy and you’re balancing the act between those three major priorities. What are some of the things that checks and balances you and put in place for yourself and for your team as you continue to just manage that balancing act, for lack of a better term?

Aimee: One of the first things we do is we make sure that in our backlogs we give time and budget to non-feature delivery work. That is number one. At least 20 to 30% of your backlog should be focused on enabling work security remediation. And in security, we really focus in our delivery pipelines on doing the static security analysis, the dynamic security scanning on our repositories, and our artefact management systems to make sure that there’s nothing in there that we would put out. We also are proactive with how we maintain container images and machine images to make sure that they are compliant. We patch regularly, we’re always looking at least privilege principles and making sure that we are giving role-based access, and really locking down production. I think one of the biggest things in DevOps and continuous delivery is adhering to the segregation of duties and SOX compliance. And that’s how it looks like with continues delivery or deployment where you don’t want to hand off to somebody for that approval to meet that requirement and looking at how we can use source control and gitops. Being familiar with gitops principles to meet segregation of duties and that merge approval with all of the evidence is considered segregation of duties.

Logan: Aimee, I really appreciate you getting into the day-to-day activities. I think we can talk about this balancing act all we want, but unless we share what’s going on behind the scenes, then we’re not really helping listeners out. So I appreciate you getting into the tactics and getting into the weeds a little bit there.
Cigniti speaker, similarly Cigniti has worked with clients in highly regulated environments where obviously compliance and security are of paramount importance. How does your QA offering really ensure that this balance between speed, compliance, and security is achieved, and what are you seeing your customers do to really achieve that balance on top of some of the tactics, and ongoing strategies that Aimee talked about in her response?

Cigniti speaker: Aimee provided some of the perspective, but I’d say that if you look at the whole compliance and security, we understand this as an organization at two levels. Number one is at the organization level. We are ISO 27001:2013 certified. We, as an organization, have a dedicated team that has actually laid out the standards to protect the intellectual property of the clients. And as a company, we are working with several healthcare companies, and we’re working with the banks, we’re working with the insurance companies, and we’re also working with the other industries where personally identifiable information like the PII and other sensitive information, people do have access. As I mentioned, we have certain rules so at each engagement that we do, depending on the nature of the engagement, we make sure that we implement multiple layers of security. We have projects that are highly sensitive where the whole network is segregated, which means that nobody from outside or the ones within the network can communicate with each other so there is no transmission of information that can happen. Also in some cases, even the physical environment is segregated, meaning that only people that have an access card can have access to that room or the floor. And in some of the very sensitive areas that we are working with, we do not allow people to carry any devices with them that can record or transmit information like mobile devices. So they have to leave them outside of those project areas and do whatever they have to do, and then pick it up once they come back. In addition to that, we also have constant surveillance cameras that are running so they’re constantly being taped and to make sure that there’s nothing that’s happening which can cause any harm to the IP of the clients.
Once you set up those best practices in place, you are actually preventing people to do anything that they’re not supposed to do. One of the other aspects is that of data. In many large organizations, you simply make a copy of your production when they’re done and then use it in the test data. Which is okay, but in the heavily regulated environments, it’s a complete no-no.
So then you have to have a mechanism like products or utilities that you have to build so that you mock the data in a way that it still has the overall structure of the production data, but then you can’t pinpoint to a particular person or a transaction and things like that.
So those are some of the things that we do. And once we do those things, then you don’t have to compromise on the speed at which you do things because you are not now doing things at an individual level but at an organizational level and at an engagement level. Those are some of the practices that we follow.

Logan: Loved it Cigniti speaker, the way you wrap that up there, pointing out the specific tactics, but then what’s the common thread there. These are organizational things that you have in place that allow you to stay secure, but continue moving quickly.

Aimee, you were kind of nodding your head at multiple points where Cigniti speaker was talking about making sure areas where you have a PII and especially sensitive data available. Are there any kind of common mis-steps that you see without naming anybody, some security best practices where you see people kind of making an easy mis-step and it’s somewhat repeated? Are there some easy tweaks that you think some organizations could make to fortify themselves from a security perspective without a whole lot of effort if they just take a little bit of time to review and make a few of these organizational tweaks, like Cigniti speaker was talking about?

Aimee: There’s certainly always room for reviewing your current practices and making improvement. That is what I think a DevOps principle is about continuous improvement. I think automation scanning for data that should be encrypted. That’s not data that’s in a lower environment. That’s not masked…just some of the low hanging fruits.

Logan: Aimee, I also wanted to ask you, continuous testing and automation are allowing QA to gain a seat at the table and become a higher priority. Do you think that there’s still a long way to go for QA to be a high enough priority as it should be within most organizations?

Aimee: So that’s kind of a tricky question for me because I actually have a different view of QA. And I think, based on my experience and working with multi-discipline full stack product development teams, QA is baked into the function of that team and not a separate function. And if you’re continuously testing, you’re continuously delivering. So we wouldn’t be calling out continuous testing as a separate process. It would be inherent in the way that they’re working. And we wouldn’t even have a separate QA environment. Everything has shifted left, and you’re not even merging your code into master or trunk, unless it is releasable. And now you are more so with microservices where you have very small, very independent apps running them. We don’t even need to test anymore because you can test with service virtualization and test backwards and forward compatibility. So I think that that landscape is evolving as we change our architecture and we change our product team.

Logan: I really appreciate the thoughtful response to that question.
Cigniti speaker, Aimee and I were talking a little bit about microservices earlier and I failed to kick it over to you to get some input there. Can you talk about some of the best practices that Cigniti has developed around testing microservices applications?

Cigniti speaker: If you look at a lot of test strategies that generally people make, they’re very well suited for monolithic applications because as you see the evolution, basically all these are apps that are made of a monolithic architecture, they’re relatively easy to test. And if you look at microservices architecture, it is all about a combination of different services coming together dynamically and offering functionality to the end user. And these different services have to be well coordinated in real time. What it means is that every different microservice that you have, they’re standalone by nature, meaning that they accept certain inputs, and then they provide certain inputs. So it is less about what is in them, but then it is more about what they can provide to the consumer of these services. So each and every service has to be tested in isolation as if it is one big software program. And that many times the owner of the microservice probably can’t even imagine how this service is going to be used by the consumer of the service. There are a lot of tests that need to be done, in terms of what the service can do, but also checking work it shouldn’t be doing and building in these failure scenarios is very important.
I think that’s where the test automation will come into play and the ability to test these multiple different services in different combinations plays a huge role. And also sometimes not all these services are available to you in real time, that’s when you have to do some mock-ups for these different services, because you still want to verify the entire business process functionality even though the service is not available to you. Those are some of the things that we do

Aimee: Do you offer AB testing and like being able to test in live production, you know, some of the things I think you’ve described? I would even want to even put it out there for the users to do real testing versus have a QA or a whole organization dedicated to that.

Cigniti speaker: Absolutely Aimee, with all this containerization and ability to expose a certain new functionality to a certain target number of users, and then getting feedback from those users before rolling it down to you full scale is one technique that several mobile and web developers, especially for the ones facing a large amount of consumers, that’s an extremely good technique.

Logan: I love it! Aimee, we have touched on a number of different things today. I appreciate your input as our featured guest today. If there are tech leaders out there listening to this, of all the things we’ve talked about, different trends, the balance between security and speed, the rise of microservices, if there’s one thing that leaders out there you want them to take away from this episode, what do you think that would be today?

Aimee: I would say, I’d want them to start if they’re not already starting down this path, to start. And to not worry about where you’re starting, or how you’re starting, and just to pick a place and start, and do it and learn. You’re never, ever going to hit the perfect timing or situation to make it happen!

Logan: Absolutely! I think that’s true in a number of different things in, in both business and in life. That if you wait for that perfect time, you’re just never going to get started. Go execute, get started, and then you’ll figure it out. You can fall forward.
I saw a great quote the other day that said, “even if you’re on the right track, if you’re standing still, you’re going to get run over.” And I just thought that was so applicable in Marketing and in IT.
And in every function of the business, you can be pointed in the right direction and saying, yes, this is where we need to go, but you need to start moving…even if you’re not going as fast as you would like to go.
Coming back to our balance of speed and security, Aimee, if there’s anybody listening to this who is now aware, just like myself, and the Cigniti team, of how much expertise and knowledge you have to bring to other leaders, what’s the best way for them to stay connected with you after listening to this?

Aimee: I’m on LinkedIn as Aimee Bechtle!

Logan: That is always my go-to way as well, Aimee.

Logan: Anybody listening to this, go connect with  Aimee on LinkedIn, and as always, thank you so much for listening.

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 an episode, subscribe to the show in your favorite podcast player. Thank you so much for listening, until next time.