As a QE, we should dispel the myths that we need to prove our value. Our values should be very prominent and eminent with the things that we do. 

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. 

Ralph: Welcome to another edition of QA talks. Hi, I am your host Ralph Miranda and today, we are joined by Melissa Tondi. She is involved in quality engineering leadership. She has over 15 years experience in software quality engineering and process engineering. And of course, I am joined by one of my co-host, Cigniti. 

Melissa, welcome to QA talks.  

Melissa: Thank you. I am delighted to be here.  

Ralph: We are glad to have you here. And Cigniti, welcome to you as always.  

Cigniti Speaker: Yeah, thank you, Ralph.  

Ralph: Melissa, I am going to start with you, and I am going to ask you, you obviously have lots of experience in the field of quality engineering and quality assurance and quality testing. Tell us a little bit about your background and how you became involved in the QA QE space? 

Melissa: So, as you mentioned, over 15 years now and I am probably closer approaching twenty years counting in this space. I started out, typically as many of us do, as a software tester on a contract position. I really fell in love with that role of working with product and business analysts and developers and project managers at that time. And over the years, took more and more lead and management positions and over the last 7 or 8 years or so, I really focused my career on the concept of quality engineering. So, kind of moving from an individual contributor software tester into quality assurance, and now, recently the quality engineering leadership. And, naturally, kind of where all of this the scene of when I speak or I write, have really been focused on components & characteristics of quality engineering and how that differs from quality assurance. 

Ralph: And that’s a good point. And I am going to pyramid off that last point of yours. Define for us and for those who might be listening. We hear quality assurance and quality engineering – give us your concept of the difference and how you get from one to the other.  

Melissa: That’s a great question and I love being able to talk about that. 

So, a lot of times people just assume that moving from quality assurance into quality engineering is just a name change. Right? Just remove assurance and add engineering and voila! You are a quality engineer. 

The best way I kind of define what a quality engineer is again like when I am working with companies to transform into quality engineering, it is really this role embodies the technical acumen and user advocacy so that they are influential in building up the software before the software has been built. So, you can kind of take that concept where a lot of times we hear the terms, “throw it over the fence” or we can bring QA in later, but right now we just want to make sure that we code these stories up or we code these requirements up.  

Really, the quality engineer embodies, again, the technical acumen where they are not only adopters of tools and technology, but they are embracers of those tools and technology. They use those tools and technology to make sure that they are efficient in the implementation of those tools and technology. So that they can spend time doing what they are doing best, which is really being able to consult with Dev and products and other members of the Agile project teams or the delivery team to help build testing and overall quality in and the way that we do that is we shift that quality engineers so that they are participating in the very low level, sometimes very technical discussions with their project team counterparts. So, they can start influencing the building of that code, as I mentioned, before that code is even built. That’s probably the biggest disruptors between quality assurance and quality engineers.  

Ralph: I will go to you now. You just heard Melissa’s definition and how she thinks about quality assurance and quality engineering. Give me your take on it and how you have been involved in the marriage of those two related fields.  

Cigniti Speaker: Absolutely, Ralph. So, the way that I look at it is I definitely agree with the views of Melissa here. So, quality engineering is an evolution from quality assurance; where actually the test teams are contributing and playing a critical role in building quality into the product right from day one, as opposed to sort of trying to build quality by testing the systems later on in the life cycle. And one more thing that I have also seen is that quality engineering is all about how do we shift the testing activities early in the life cycle and get engaged very early from the moment of the overall planning, requirements, as opposed to getting late in the life cycle. Quality engineering is all about defect prevention and also early defect detection. Also, one more thing that we are seeing what we are experiencing as a company is that the quality engineering sort of – there are two aspects of it. Actually, the technology skills that are required to be able to play this role very effectively is much higher compared to your traditional QA role. 

Ralph: Melissa, obviously many companies you know, they are at different levels in their quality process, for the lack of a better way to say it. And I know we talked a little bit on a previous call about implementing different types of testing programs. So, talk a little bit, if you would, on what factors that you find are most important when a company is ready to either implement a testing program or maybe, upgrade a testing program that they already have in place. 

Melissa: I think one of the greatest components of that is to make sure that the engineering leadership understands that not only is quality or quality engineers or testers are required role within the organization but that provides value. In some cases, you may be in a highly regulated industry or field, where it is required to have a separate team that’s testing and ensuring that the requirements are met for an audit or some sort of compliance. 

But mostly, I found that leaders who have seen the value that QA or QE provides in the past and they understand what a good QE team looks like – they are the ones that are our biggest advocates for that. So, when you go in to a company where QA is may be viewed as a second thought, or not having an equal seat at the table, those tends to be organizations that are much harder to implement what I would consider a full successful testing program and certainly as we transform from quality assurance into a more modern quality engineering mindset, that becomes a little bit tricky when the value of QA is not perceived as to be equal as other members of the delivery team. 

Ralph: And what’s your impression of that? I mean, obviously, you have worked for many organizations – some small by virtue of the volume of dollars or by virtue of people and some very large. So, what’s your take on the implementation of the different types of programs?  

Cigniti Speaker: What we have seen is that obviously at Cigniti we are the largest independent testing players in the North American market space. Right now, we are the testing partner for 50+ fortune 1000 companies. The way we look at things is that we try to understand the overall business objective of the organization and then how they are mapped to the overall IT objectives. From there we derive the overall vision and mission statement for the QA department, and then align all the activities that we are doing in terms of achieving that mission. And, the way that we go about doing as the company that are big on numbers, as there is a saying that, “what gets measured gets done” so we would like to convert the objectives as much as possible into numbers and then sort of convert that into the KPIs and use metrics to align to the KPIs and then continuously track. 

We, as an organization, also believe in continuous improvement. So, I would say that the QA organizations, the abilities of the QA organizations to translate the contribution that they are making, in terms of the business goals, would go a long way in terms of convincing the management team about the values that the QA teams are able to add.  

Ralph: Melissa, one of the things you had mentioned previously as well that is near and dear to your heart is that modernization of Quality Assurance. So, give me your take on what that exactly means and what factors are involved in that journey? 

Melissa: Sure! So, I think a part of it is truly the transformation in quality engineering, kind of. And then using that the original definition of being influential to the software before the software is being built. That is probably the biggest component of modernization of quality assurance into QE. But factors that I look at are generally kind of looking at the three main activities that we do as part of being a professional quality assurance or quality engineer. We sort of generally bucket things into how do we write and manage our tests from a scripted standpoint. And whether those are scripted in a more traditional testing management tool or an automated framework.  

We look at the test management. Are we writing the right test and are we making sure that those details are appropriate for the delivery team and are we making those test centralized and accessible by the entire product team? Because, one of the more antiquated approaches to QA and what quality engineering in the modern organization tends to address is that we assume that QA is responsible for all testing. That is simply not true. Especially for the delivery teams who are highly optimized, highly mature in their agile delivery or their approach, but one example of that is we tend to say that QA owns the regression testing and they are the sole owners of all of their regression testing. 

A modern approach to that would be to say that QA can advise and should be advising on the types of regression testing that should be involved because they are intimately involved in the changes of the code that their developer counterpart is making. So, we would be able to provide the ability to give the developers tests so that they can start implementing the regression testing on their own. Ideally, that’s in an automated fashion. But, when we see the comparison between a less modern organization what we see is that a regression cycle that happened, preparing for the deployment cycle, for example. So, you might see something like a one week, two weeks, three-week regression cycle where all of QA is simply ensuring that no other regression has been introduced from all of the codes for new feature developments that have happened on the said amount of time.  

Modernizing that would be to be consultative with the developer, provide them tests that they can run on their own so that we reduce that regression cycle that tends to fall completely on the shoulders of the QA team. So, that’s one component where I have found that where we look at ownership of regression testing is solely being QA’s responsibility, we can modernize that and actually make that much more of a team responsibility. Or, ideally, provide development the way to regression testers own their own code and ensure there has not introduced any negative behavior or anything that wouldn’t impact the user experience from a negative standpoint.  

Ralph: What’s your perspective on that modernization process and how does Cigniti approach that challenge? 

Cigniti Speaker: I would say that in terms of modernizing QA, especially towards quality engineering. First of all, what we see is that especially when you are trying to transform from the QA organizations as part of the large organizations is that it requires a tremendous amount of change management skills. 

And also, the ability to convert the change that you are making and articulate the business value, in terms of why such a change is required. And, what we see is that that is a hard part, among many other things. One more challenge that we see in large organizations is that everyone is reskilling people. Because, moving towards quality engineering, meaning that there is not only a shift that is required in the mindset, but we also need a shift in terms of the technology skill set as well. This means that people that were historically having some good business functionalized and they are probably sailing along in doing manual functional testing. However, once you sort of transform into quality engineering, you still need all those skills that you have. But then you need to be able to now work more closely with the development teams on a daily to daily basis. But also, you will be working a lot more intimately with the architecture and the codes and that requires upskilling in terms of technology and every day we use different tools and all. So, we see that that is another challenge organizations face. 

Another challenge that we have seen is that when we are trying to implement modernized and take towards quality engineering, typically the product requires some amount of decent relation of the QA teams because now the QA teams are part of the different parts and they are working with developers a lot more closely. That would also mean that some of the senior people in the QA team, their roles are changing from being a line manager to a more of somebody that is helping them and providing their governance to do this day-to-day job. So, you sort of move from being somebody who assigns tasks on a day to day basis and you take the role of a coach. Those are some of the challenges that we see.  

Ralph: Okay. Melissa, one of your areas of expertise is the implementation of the enterprise-wide automation strategy. So, talk to us a little bit about the pitfalls and of course important benchmarks undertaking such a venture.  

Melissa: Yeah, I love this topic. You know probably the biggest pitfall and even when I speak about this tonight, I have the opportunity when I am in a session, to pull the attendees and ask them a question of, you know, “how many of you are being helped to a metric of either a certain percentage of test cases to be automated, or a certain number of test cases to be automated?” 

And I am still always amazed at how many hands go up when I ask them of a certain number of the percentage that’s guiding their enterprise-wide strategy. We tend to call that the numbers team. And in my experience, I have seen much less success when we have a number or percentage of test cases that indicate a higher quality automation strategy. One way that we counterbalance that is to have these very specific criteria and guidelines for not only removing the numbers team from the equation but to make sure that we are all focusing on the right things to automate.  

So, one way we do that is by quality engineering role where we kind of transform into quality engineering, really means that we are all quality engineers. Some of us may have specialties in test automation or performance engineering or a business acumen or a product or domain expertise. The thing is that when we start embedding the quality engineers within the delivery team vs treating them as a matrix team where they are separate and they take their order and priority of work from another person that is sitting within the delivery team, we have increased the inefficiency of getting that work done.  

So, in this situation, a quality engineer would say, a test automation expertise would be embedded within a delivery team and then they would be consulted this and not go off a test case automation. But they would simply look at the same work that those Dev and QA on that team would be working on. In most cases would be some kind of a user story, or requirement documentation. Instead of getting their work again from perhaps another QA that has check marked something in the test management tool to say, okay automate this test case, they would come in and shift all of that work to the left to the point where they are working collaboratively with the other QA counterparts, who may be responsible for writing test cases in a traditional test management tool and they would be consultative with the developers on the team to say, this meets our automation criteria. I am going to automate this because this meets our priority one of automation.  

In some cases, that priority one of the automation may look like the acceptance criteria in a user story. And if you start concentrating work that makes the most value and sense to the delivery team, I found that you get much more buy–in and end support from the entire delivery team to support the efforts of test automation because it is tied to something that the entire delivery team is often tied to. In this case, the acceptance criteria.  

So, we flipped the switch and say instead of going through all the test cases that exist in a test management tool, and automating certain ones that are check-marked or that indicate something, we actually embed that quality engineer within the delivery team and their automating test alongside with their QA & QE counterparts, who are also writing tests in a test management tool. I mean we see much greater ability to get that test automation in as tied to a shippable component of that story and you can see the value of that test automation real-time vs waiting until it gets further down the lines, because we can have not embedded them within the delivery team.  

Ralph: Well said. From Cigniti’s perspective, give me your thoughts on enterprise wise wide automation strategy and how you all go about it? 

Cigniti Speaker: Absolutely, Ralph. That’s a great question. So, from where you get things is that what we see, especially in large organizations is that some of these organizations are sort of divided in terms of different types of publications by the technology stats and we also see, sometimes they are organized by the different businesses that they are serving and so they typically have these different business units and what we see is that, because of the way for these teams are organized, they end up with multiple different test automation frameworks. This is very often, there is a lot of redundancy, and not only redundancy, but there is also a constantly reinventing the wheel across different departments. So, as a company, what we have is an enterprise where test automation framework that sort of can work with multiple different test automation tools. Be it open source or commercial.  

It also has the ability to work with different methodologies. Be it Waterfall, DevOps, Agile, or some customization of agile practices. And also, that the way that we have built the framework is that you could actually use the entire framework as is, but you would also be able to borrow some of the components of the framework. This could be orchestrating the execution of your testing, the reporting components, or the everyday support of multiple different browsers and mobile devices and things like that. So, depending on the situation that you are dealing with, either you will be able to use the whole framework as is, or you will be able to leverage the different components that are part of the framework and embed it add it as per the existing framework. 

So, we sort of take a transforming approach for an enterprise like test automation where you build an enterprise test automation platform and using that platform you would be able to build test automation for multiple different applications so that spans across multiple technologies, tools, and things like that. 

Ralph: Well, this has been an excellent discussion and Melissa, I am going to give you the final word. So, any final thoughts on the topics? 

Melissa: I would say that we, as an QE, we should dispel the myths that we need to prove our value. Our values should be very prominent and eminent with the things that we do. So, hopefully the modernization of QA would move the fact that we need to constantly prove the values. Our values should go along with our ability to collaborate without a delivery team to show value as part of our normal day-to-day activities and ideally, we would no longer need to be using our platform to continue to prove the value of QA because we already have proven that in our work.  

Ralph: Well said, very well said. Well, I hope everyone has enjoyed this edition of QA talks. I am going to thank our guests today.  

Melissa Tondi, involved in Quality Engineering leadership for as she said, twenty years of experience in software quality engineering and process engineering. Thank you for your time. I have enjoyed it and I appreciate your inputs.  

Melissa: Pleasure.  

Cigniti Speaker: Thank you, Ralph.  

Ralph: Remember, you can find this podcast on your favorite podcast platform and of course on apple podcast as well. Make sure you stay tuned for the next edition of QA talks. I am Ralph and we appreciate you 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 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 www.cigniti.com