{"id":70210,"date":"2020-01-05T15:55:53","date_gmt":"2020-01-05T15:55:53","guid":{"rendered":"https:\/\/coforge.site\/cigniti_new\/?post_type=product&p=70210"},"modified":"2024-10-18T13:18:26","modified_gmt":"2024-10-18T13:18:26","slug":"modernizing-qa-with-melissa-tondi","status":"publish","type":"product","link":"https:\/\/coforge.site\/cigniti_new\/resource\/podcasts\/modernizing-qa-with-melissa-tondi\/","title":{"rendered":"3 Essential Questions to Ask when Modernizing QA with Melissa Tondi"},"content":{"rendered":"

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.\u00a0<\/strong><\/p>\n

You are listening to QA\u00a0<\/span><\/i>Talks<\/span><\/i>. 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\u2019s get into the show.<\/span><\/i>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>Welcome to another edition of QA talks<\/span>. Hi,<\/span>\u00a0I am your host Ralph<\/span>\u00a0Miranda<\/span>\u00a0and today, we are joined by Melissa\u00a0Tondi. She is involved in quality engineering leadership<\/span>.<\/span>\u00a0<\/span>She\u00a0<\/span>has over 15\u00a0years experience\u00a0in software quality engineering and process engineering. And of course, I am joined by one of my\u00a0co-host<\/span>,\u00a0<\/span>Cigniti<\/span>.<\/span>\u00a0<\/span><\/p>\n

Melissa, welcome to QA talks.\u202f<\/span>\u00a0<\/span><\/p>\n

Melissa:\u00a0<\/span><\/b>Thank you.\u00a0<\/span>I am d<\/span>elighted to be here.\u202f<\/span>\u00a0<\/span><\/p>\n

R<\/span><\/b>alph<\/span><\/b>:\u00a0<\/span><\/b>We are glad to have you here. And\u00a0<\/span>Cigniti<\/span>, welcome to you as always.\u202f<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker<\/span><\/b>:\u00a0<\/span><\/b>Yeah, thank you, Ralph.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>Melissa, I am\u00a0<\/span>going to<\/span>\u00a0start with\u00a0<\/span>you,<\/span>\u00a0and I am\u00a0<\/span>going to<\/span>\u00a0ask you, you obviously have lots of experience in the field of quality engineering and quality assurance and quality testing<\/span>. Tell\u00a0<\/span>us a little bit about your background and how you became involved in the QA QE space?<\/span>\u00a0<\/span><\/p>\n

Melissa:\u00a0<\/span><\/b>So, as you mentioned, over 15 years now and I am probably closer approaching twenty years<\/span>\u00a0counting<\/span>\u00a0in this space. I started\u00a0<\/span>out,\u00a0<\/span>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,\u00a0<\/span>I really focused\u00a0<\/span>my career on the concept of quality engineering. So,\u00a0<\/span>kind of<\/span>\u00a0moving from an individual contributor software tester into quality assurance<\/span>,<\/span>\u00a0and now, recently the quality engineering leadership.\u00a0<\/span>And<\/span>,\u00a0<\/span>naturally,<\/span>\u00a0kind of where all of this the scene of when I speak or I\u00a0<\/span>write<\/span>,<\/span>\u00a0<\/span>have really been\u00a0<\/span>focused<\/span>\u00a0on\u00a0<\/span>components &<\/span>\u00a0characteristics of quality engineering and how that differs from quality assurance.<\/span>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>And that\u2019s a<\/span>\u00a0good point. And I am\u00a0<\/span>going to<\/span>\u00a0pyramid\u00a0<\/span>off\u00a0<\/span>th<\/span>at<\/span>\u00a0last 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.\u202f<\/span>\u00a0<\/span><\/p>\n

Melissa:\u00a0<\/span><\/b>That’s a great question and I love being able to talk about that.<\/span>\u00a0<\/span><\/p>\n

So, a lot of times people\u00a0<\/span>just assume\u00a0<\/span>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.<\/span>\u00a0<\/span><\/p>\n

The best way I\u00a0<\/span>kind of<\/span>\u00a0define what a quality engineer is again like when I am working with companies\u00a0<\/span>to transform<\/span>\u00a0into quality engineering, it is really this\u00a0<\/span>role\u00a0<\/span>embodies\u00a0<\/span>the<\/span>\u00a0techn<\/span>ical acumen and user advocacy s<\/span>o that they are influential in building up the software before the software has been built. So, you\u00a0<\/span>can\u00a0<\/span>kind of take that concept where\u00a0<\/span>a lot of<\/span>\u00a0times we hear the terms, \u201c<\/span>throw<\/span>\u00a0it over the fence<\/span><\/i>\u201d or we can bring QA in\u00a0<\/span>later<\/span>, but\u00a0<\/span>right\u00a0<\/span>now we just\u00a0<\/span>want to<\/span>\u00a0make sure that we\u00a0<\/span>code<\/span>\u00a0these stories up or we\u00a0<\/span>code<\/span>\u00a0these requirements up.\u202f<\/span>\u00a0<\/span><\/p>\n

Really, the quality engineer embodies, again, the technical acumen where they are not only adopters of tools and technology<\/span>,<\/span>\u00a0but they are embracers of th<\/span>ose<\/span>\u00a0tools and technology. They use\u00a0<\/span>those<\/span>\u00a0tools and technology to make sure that they are efficient in the implementation of\u00a0<\/span>those\u00a0<\/span>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\u00a0<\/span>Agile\u00a0<\/span>project team<\/span>s<\/span>\u00a0or 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<\/span>,<\/span>\u00a0they can start influencing the building of that code<\/span>, as I mentioned,<\/span>\u00a0before that code is even built. That\u2019s probably the biggest\u00a0<\/span>disruptors<\/span>\u00a0between quality assurance and quality engineers.\u202f<\/span>\u00a0<\/span><\/p>\n

Ral<\/span><\/b>p<\/span><\/b>h<\/span><\/b>: <\/span>I will go to you now. You just heard Melissa\u2019s definition and\u00a0<\/span>how<\/span>\u00a0she thinks about quality assurance<\/span>\u00a0and<\/span>\u00a0quality engineering. Give me your take on it and how you have been involved in the marriage of those two related fields.\u202f<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker<\/span><\/b>:\u00a0<\/span>Absolutely, Ralph. So, the way that I look at it is I definitely agree with the views of Melissa<\/span>\u00a0here.<\/span>\u00a0So, quality engineering is an evolution from quality assurance;\u00a0<\/span>where<\/span>\u00a0actually the test teams are contributing and playing a critical role in bui<\/span>lding quality into the product\u00a0<\/span>right\u00a0<\/span>from day one<\/span>, a<\/span>s opposed to sort of trying to build quality by testing the systems later on in the life cycle. And one more thing that I\u00a0<\/span>have\u00a0<\/span>also\u00a0<\/span>seen<\/span>\u00a0is 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\u00a0<\/span>moment<\/span>\u00a0of the overall planning, requirements, as opposed to getting late in the life\u00a0<\/span>cycle.\u00a0<\/span>Q<\/span>uality engineering is all about defect prevention and also early defect detection.\u202fAlso<\/span>,<\/span>\u00a0one 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.<\/span>\u00a0<\/span><\/p>\n

Ralph<\/span><\/b>:\u00a0<\/span>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\u00a0<\/span>about<\/span>\u00a0implementing different types of testing programs. So, talk a little bit, if you would, on what factors\u00a0<\/span>that<\/span>\u00a0you 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.<\/span>\u00a0<\/span><\/p>\n

Melissa<\/span><\/b>:\u00a0<\/span>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\u00a0<\/span>or<\/span>\u00a0testers a<\/span>re<\/span>\u00a0required role within the organization but that provides value. In some cases, you\u00a0<\/span>may<\/span>\u00a0be in a highly regulated<\/span>\u00a0industry or<\/span>\u00a0field, where it is required to have a separate team that\u2019s testing and ensuring that the requirements are met for\u00a0<\/span>an audit or some<\/span>\u00a0sort of compliance.<\/span>\u00a0<\/span><\/p>\n

But mostly, I found that leaders\u00a0<\/span>who<\/span>\u00a0have seen the value that QA or QE provides in the past and they understand what a good QE team looks like<\/span>\u00a0\u2013 t<\/span>hey are the ones that are our biggest advocates for that. So, when you go in to a company where QA\u00a0<\/span>is\u00a0<\/span>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\u00a0<\/span>to be\u00a0<\/span>equal as other members of the delivery team.<\/span>\u00a0<\/span><\/p>\n

Ralph<\/span><\/b>:\u00a0<\/span>And <\/span>what’s your impression\u00a0<\/span>of<\/span>\u00a0that? I mean, obviously, you have worked for many organizations<\/span>\u00a0\u2013 s<\/span>ome 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?\u202f<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker:<\/span><\/b>\u00a0<\/span>What we have seen is that obviously at\u00a0Cigniti\u00a0we are the largest independent testing players in the North American market space.\u00a0<\/span>Right<\/span>\u00a0now, we are the testing partner for 50+ fortune 1000 companies. The way we look at things is that we try to\u00a0<\/span>understand the overall business objective of the organization and then how they are mapped to the overall\u00a0<\/span>IT<\/span>\u00a0objectives. From there we derive the overall vision and mission statement for the QA department<\/span>,<\/span>\u00a0and\u00a0<\/span>then<\/span>\u00a0align all the activities that we are doing in terms of achieving that\u00a0<\/span>mission.\u00a0<\/span>And, the way that we go about doing\u00a0<\/span>as\u00a0<\/span>the company<\/span>\u00a0that<\/span>\u00a0are big on numbers,\u00a0<\/span>as there is a saying that<\/span>, \u201cwhat gets measured gets done\u201d so we would like to convert the objectives as much as possible into numbers and\u00a0<\/span>then\u00a0<\/span>sort of convert that into the KP<\/span>I<\/span>s and<\/span>\u00a0use metrics to align to the KPI<\/span>s and then continuously track.<\/span>\u00a0<\/span><\/p>\n

We, as an organization, also believe in continuous improvement. So<\/span>,<\/span>\u00a0I woul<\/span>d say that the QA organizations,\u00a0<\/span>the abilities of the QA organizations to translate the contribution that they are making, in terms of the business\u00a0<\/span>goals<\/span>,<\/span>\u00a0would go a long way in terms of convincing the management team about the values that the QA teams are able to add.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph<\/span><\/b>:\u00a0<\/span>Melissa, one of the things you had mentioned previously as well that is near and dear to your heart is that\u00a0modernization\u00a0of Quality Assurance. So, give me your take on what that exactly means and what factors are involved in that journey?<\/span>\u00a0<\/span><\/p>\n

Melissa<\/span><\/b>:\u00a0<\/span>Sure! So, I think a part of it is truly the transformation in quality engineering, kind of. And then\u00a0<\/span>using that<\/span>\u00a0the 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<\/span>.<\/span>\u00a0<\/span>But\u00a0<\/span>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\u00a0<\/span>or<\/span>\u00a0quality 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.\u202f<\/span>\u00a0<\/span><\/p>\n

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 th<\/span>os<\/span>e test centralized and accessible by the entire product\u00a0<\/span>team?<\/span>\u00a0<\/span>Because, o<\/span>ne of the more antiquated approaches to QA and what quality engineering in the modern organization tends to<\/span>\u00a0address<\/span>\u00a0is that we assume that QA is responsible for all testing. That is simply not true. Especially for the delivery team<\/span>s<\/span>\u00a0who 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\u00a0<\/span>the\u00a0<\/span>sole owners of all of their regression\u00a0<\/span>testing<\/span>.<\/span>\u00a0<\/span><\/p>\n

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\u2019s 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<\/span>, preparing for the deployment cycle, for example<\/span>. So, you might see\u00a0<\/span>something like a one week, two weeks, three-week regression cycle where all of QA is simply ensuring that no other regression<\/span>\u00a0has\u00a0<\/span>been introduced from all of the codes for new\u00a0<\/span>feature<\/span>\u00a0developments that have happened on the said amount of time.\u202f<\/span>\u00a0<\/span><\/p>\n

Modernizing that would be\u00a0<\/span>to be<\/span>\u00a0<\/span>consultative with the developer, provide them tests that they can run on their own so that we reduce that regression cycle<\/span>\u00a0that\u00a0<\/span>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\u2019s responsibility, we can modernize that and actually make that much more of<\/span>\u00a0a<\/span>\u00a0team responsibility. Or, ideally, provide development the way to regression test<\/span>ers own their<\/span>\u00a0own code and ensure there has not introduced any negative behavior or anything that wouldn\u2019t impact the user experience from a negative standpoint.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph<\/span><\/b>: W<\/span>hat\u2019s your perspective on that modernization process and how does\u00a0Cigniti\u00a0approach that challenge?<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker<\/b>: <\/span>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\u00a0<\/span>change<\/span>\u00a0management skills.<\/span>\u00a0<\/span><\/p>\n

And\u00a0<\/span>also,<\/span>\u00a0the ability to convert the change that you are making and\u00a0<\/span>articulate the<\/span>\u00a0business 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 organizat<\/span>ions is that everyone is res<\/span>kil<\/span>lin<\/span>g people. Because, moving towards quality engineering, meaning that there is not only a shift that is required in the\u00a0<\/span>mindset,<\/span>\u00a0but we also need a shift in terms of the technology skill set as well. This means that people that were<\/span>\u00a0historically<\/span>\u00a0having some good business functionalized and they are probably sailing along in doing manual functional testing.\u202fHowever, 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<\/span>\u00a0on a daily to daily basis<\/span>. But also, you will be working a lot more intimately with the architecture and\u00a0<\/span>the codes and that requires up<\/span>skilling in terms of technology and every day we use different tools and all. So, we see that that is another challenge\u00a0organizations\u00a0face.<\/span>\u00a0<\/span><\/p>\n

Another challenge that we have seen is that when we are trying to implement modernized and\u00a0<\/span>take towards<\/span>\u00a0quality 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\u00a0<\/span>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<\/span>\u00a0on a day to day basis<\/span>\u00a0and you take the role of a coach. Those are some of the challenges that we\u00a0<\/span>see<\/span>.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph:<\/span><\/b>\u00a0<\/span>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.\u202f<\/span>\u00a0<\/span><\/p>\n

Melissa:<\/span><\/b>\u00a0<\/span>Yea<\/span>h<\/span>, I love this topic. You know probably the biggest pitfall and even when I speak\u00a0<\/span>about<\/span>\u00a0this tonight, I have the opportunity when I am in a session, to pull the attendees and ask them\u00a0<\/span>a\u00a0<\/span>question of, you know, \u201chow many<\/span>\u00a0of you are being helped to a me<\/span>tric of either a certain percentage of test cases to be automated, or a certain number of test cases to be automated?\u201d<\/span>\u00a0<\/span><\/p>\n

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,\u00a0<\/span>I have seen much less\u00a0<\/span>success when we have a number or<\/span>\u00a0percentage of test cases that indicate a higher quality automation strategy. One way that we counterbalance<\/span>\u00a0that<\/span>\u00a0is 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.\u202f<\/span>\u00a0<\/span><\/p>\n

So, one way we do that is by quality engineering role where we\u00a0<\/span>kind of<\/span>\u00a0transform into quality engineering, really means that we are all quality engineers. Some of us may have specialties in test automation or performance engineering or<\/span>\u00a0a<\/span>\u00a0business acumen or a product or domain expertise. Th<\/span>e thing is that\u00a0<\/span>when we start embedding\u00a0<\/span>the quality engineers within the delivery team vs treating them as a matrix team where they are separate and they take their\u00a0<\/span>order<\/span>\u00a0and priority of work from another person that is sitting within the delivery team, we have increased the inefficiency of getting that work done.\u202f<\/span>\u00a0<\/span><\/p>\n

So, in this situation, a quality engineer would say, a test automation expertise<\/a> would be embedded within\u00a0<\/span>a<\/span>\u00a0delivery team and then they would be consulted this and not go off a test case automation.\u00a0<\/span>But<\/span>\u00a0they would simply look at the same work that those Dev and QA on that team would be working on. In most cases would be<\/span>\u00a0some<\/span>\u00a0kind of a user story, or requirement<\/span>\u00a0documentation<\/span>. 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\u00a0<\/span>of that<\/span>\u00a0work to the left to the point where they are working collaboratively with the other QA counterparts, who may be responsible for\u00a0<\/span>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.\u202f<\/span>\u00a0<\/span><\/p>\n

In some cases, that priority one of the\u00a0automation\u00a0may look like the acceptance criteria\u00a0<\/span>in a<\/span>\u00a0user story. And\u00a0<\/span>if you start concentrating work that makes the most value and sense to the delivery team, I found that you get much more buy<\/span>–<\/span>in and<\/span>\u00a0end<\/span>\u00a0support from the entire delivery team to support the\u00a0<\/span>efforts of\u00a0<\/span>test automation because it\u00a0<\/span>is tied to<\/span>\u00a0something that the entire delivery team is often tied to. In this case, the acceptance criteria.\u202f<\/span>\u00a0<\/span><\/p>\n

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\u00a0<\/span>&<\/span>\u00a0QE counterparts, who are also writing tests in a test management tool. I mean we see much greater ability to get that test automation in\u00a0<\/span>as<\/span>\u00a0tied to a shippable component of that story and you can see the value of that test automation real-time vs waiting\u00a0<\/span>until<\/span>\u00a0it gets further down the lines, because we can have\u00a0<\/span>not<\/span>\u00a0embedded them within the delivery team.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph:<\/span><\/b>\u00a0<\/span>Well said. F<\/span>rom\u00a0Cigniti\u2019s\u00a0perspective, give me your thoughts on\u00a0enterprise\u00a0wise wide automation strategy and how you all go about it?<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker: <\/span><\/b>Absolutely, Ralph. That\u2019s 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 d<\/span>ifferent types of publications by\u00a0<\/span>the technology stats and we also see, sometimes they are organized by the<\/span>\u00a0different<\/span>\u00a0businesses 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\u00a0<\/span>wheel<\/span>\u00a0across 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.\u202f<\/span>\u00a0<\/span><\/p>\n

It also has the ability to work with different methodologies. Be it Waterfall, DevOps, Agile, or some customization of agile practices. And\u00a0<\/span>also,<\/span>\u00a0that 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\u00a0<\/span>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.<\/span>\u00a0<\/span><\/p>\n

So, we sort of take a transforming approach for an enterprise like test automation where you build\u00a0<\/span>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,\u00a0<\/span>tools,<\/span>\u00a0and things like that.<\/span>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>Well, this has been an excellent discussion and Melissa, I am\u00a0<\/span>going to<\/span>\u00a0give you the final word. So, any final thoughts on the topics?<\/span>\u00a0<\/span><\/p>\n

Melissa:\u00a0<\/span><\/b>I would say that we, as an QE, we should dispel the myths that we need to prove our value.\u00a0<\/span>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.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>Well said, very well said. Well, I hope everyone has enjoyed this edition of QA talks. I am\u00a0<\/span>going to<\/span>\u00a0thank our guests today.\u202f<\/span>\u00a0<\/span><\/p>\n

Melissa\u00a0Tondi, involved in Quality Engineering leadership for as she said, twenty years of experience in software quality engineering<\/a> and process engineering. <\/span>Thank you for your time. I have enjoyed it and I appreciate your inputs.\u202f<\/span>\u00a0<\/span><\/p>\n

Melissa:\u00a0<\/span><\/b>Pleasure.\u202f<\/span>\u00a0<\/span><\/p>\n

Cigniti Speaker: <\/span><\/b>Thank you, Ralph.\u202f<\/span>\u00a0<\/span><\/p>\n

Ralph:\u00a0<\/span><\/b>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.\u202f<\/span>\u00a0<\/span><\/p>\n

Quality Assurance is vital to the success of an organization\u2019s digital transformation. Lack of control can quickly derail a company\u2019s technological presence, costing thousands. At\u00a0Cigniti, 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\u202f<\/span><\/i>www.cigniti.com<\/span><\/i><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Speakers:<\/strong>\u00a0<\/strong>Melissa Tondi<\/strong>, Quality Engineering Leadership Team at E*TRADE; Cigniti (A Coforge Company) Speaker<\/b>
\n<\/span>
\n