This website uses cookies to offer you the best experience online. By continuing to use our website, you agree to the use of cookies. If you would like to know more about cookies and how to manage them please view our Privacy Policy & Cookies page.
A guide with practical steps and in-depth example
Beth Romanik: Hello and welcome to today’s web seminar, Shift to Quality Engineering to Better Test, Analyze, and Deliver Software, sponsored by Apexon. I’m your host and moderator, Beth Romanik. Thanks for joining us today. Before I hand it off to the speaker, let me explain the console.
The three panels on your screen can be moved around and resized to your liking. At the bottom of your console is the widget toolbar. Through the additional resources widget on the right, you can download a PDF of the speaker’s slides.
If you experience any technical issues at any time, please send us a note through the question field beneath the panel, and we’ll be on hand to help. This is also how you open the questions. There will be a Q and A session at the end, so feel free to ask questions throughout the presentation.
Finally, to optimize your bandwidth for the best viewing experience possible, please close any unnecessary applications you have running in the background.
This event is being recorded and will be made available to watch on demand. Once the recording is ready, you’ll get an email with instructions on how to access the presentation and slides. With that, I’d like to hand it over to Josh Galde, Associate Director of Marketing at Apexon, for a quick introduction.
Josh Galde: Great. Thanks, Beth, appreciate it. Welcome, everyone. We’re still loading the slides. Today’s webinar will specifically focus – we wanna give you a really direct guide on how to make the transition from QA to quality engineering. That’s the goal of today’s webinar.
We’re very excited to be presenting this topic to you, and we have some great content to show you that walks you through at a high level the process, as well as a nice case study from one of our customers.
Before I begin, I wanted to introduce Harshal Vora. He is our presenter today. He is our senior mobility solutions engineer at Apexon. He has more than six years of experience in planning, executing, and delivering on time quality end to end solutions in mobile development and testing as a automation engineer, business analyst, technical project manager, and QA manager here at Apexon.
Today’s agenda includes – we’ll go through a few things here. No. 1 is, obviously, the Agile and Mobile IoT Testing Complexities. We’ll cover an introduction to what we mean by quality engineering and shift left. We will also hear about a customer’s journey from QA to QE. We will learn about the Apexon QA to QE methodology, and we’ll conclude with some time to answer your questions.
If you have any questions along the way, as Beth mentioned, feel free to enter your questions in the Q and A panel, and we will address it at the end of the webinar during the Q and A period. At this time, I’ll go ahead and turn it over to Harshal and take it from there. Harshal, it’s up to you.
Harshal Vora: Okay, thank you, Josh. Good morning, good afternoon, good evening, everyone. I’m very excited to talk on this hot topic right now in the QA industry, or I should say it’s turning to QE industry now, how to shift from conventional QA methodologies to quality engineering practices.
Before we go and deep dive into it, I would like to talk on some of the drivers which is leading to this shift, why the whole industry is trying to move towards quality engineering.
Some of the drivers is adoption of Agile methodologies, and mobile and IoT technologies. With this adoption, there are a lot of testing complexities that needs to be encountered during this whole journey, and some of this complexity, as you can see here, when we started our direct to sale computers, which was just Microsoft devices, there were a limit number of devices in terms of hardware.
There was limited OS versions that that we need to encounter for, and there was, say, only Internet Explorer browser back then that we need to test on.
As time has progressed, and today, when we are talking about mobile and IoT, there is plethora of devices out there. There is multiple OS versions. OEM manufacturers are coming out with new devices every six months, and the combination is so harsh that the consumers are driving the whole industry.
As a consumer, I want a new device. I want a new OS version. I want something new every now and then, and which has led to the whole IoT revolution as well, where we have the smartwatches and smart homes.
The challenge for QA community is how do we keep up with this dynamic world, where we have multiple OS versions to test on, how we can test on both multiple OS versions, multiple devices, and as an organizations, I cannot keep on procuring those devices with multiple OS versions and keep track of everything.
As a software house, I cannot have an inventory of devices just to keep testing my actual software. These are the basic complexities that we are encountering right now. On top of it, adding different networks, when we are talking about global applications, we have multiple cellular networks, Wi-Fi networks, different complexity of networks.
How do we test on this? How QA can be smart enough to keep up with this, along with adopting the the agile processes when we are running with one or two weeks to match with the development of our engineering teams?
That’s where the whole complexity comes in. Why does it matter? Why does complexity matter when we are talking to different organizations? As the dynamic world progresses with mobile and IoT, the cycle time, the release time, for the software is very important, is very quintessential.
We don’t want testing or QA organization to be a bottleneck in the whole process. That’s where, as we have very limited time to define those test requirements from those user stories that our product teams are defining.
Coming up with shorter cycle times and release times is very important. Also, there is no way to incorporate a user feedback. Today, my applications live and breathe by app store reviews, and if I don’t have a mechanism to incorporate that feedback in my whole PLC, or product life cycle, then the organization is losing a lot of time as well as money and reputation that comes along with it.
What this leads to is low confidence on my quality of application that I’m releasing out to the app store or the market. I don’t want my application, just because I’m scrambling, I need to roll out certain features within a certain time period, I don’t want my quality team to just do a quick smoke test or regression, or skip the regression to roll out those features, and giving that quality a low confidence.
The last is limited targets for manual testing. As a manual tester, there isn’t much you can cover during the whole process. You don’t want to test on 50 devices with multiple OS versions, multiple carriers.
There are thousands of test cases or test scripts that you need to cover. As a manual tester, there is only so much you can cover during those fixed time constraints, and it’s very essential for conventional QA teams to move towards quality engineering where we want to introduce quality earlier in the life cycle and get automation in place.
What do experts suggest to overcome this? According to the recent World Quality Report, we need to refocus QA and testing more toward customer experience and product assurance and business assurance, moving towards more of a quality management office, rather than combining the PMO, the project management office, and QA teams, into one team.
Quality teams is leading the way to the whole product assurance, from project management, to the quality management, and defining the right processes.
It’s not only defining the right test methodologies, it’s defining the right processes and transforming the whole organization from the conventional center the excellences to more Agile and DevOps methodologies, making a continuous and automated testing is very important as part of the whole QE organization strategy. The quality engineering drives or breathes, live and breathe by automation.
If we can include automation as part of our quality strategy, then it becomes very a robust strategy for organizations. To achieve this, there needs to be a cultural change within the organization, so, expanding the testing team’s skills beyond manual testing, take it further. How may those manual testers can adopt to automation? How Open Source can help conventional QA teams translate themselves to QE, or translate themselves to quality engineering?
Last, but not least, involving analytics, the predictive analytics and continuous feedback loop as part of the whole QE strategy. All of the feedback that we get from our user base, we need to get it back to our quality strategy and incorporate the testing as part of it.