Best practices for a smooth implementation of “Shift Left” approach
Josh Galde: Hello, everyone. Welcome to Infostretch’s webinar entitled What is Shift Left and Why you Need it now. My name is Josh Galde and I am the Director of Marketing here at Infostretch and I will be your host today. Today’s presenters include two excellent presenters from within Infostretch. First we have Disha Thakkar. She is a Senior Business Analyst with Infostretch. She has adept at analyzing client’s business needs and translating them to functional project requirements.
Prior to Infostretch, Disha held various IT and management roles in the banking and engineering industries with experience in business requirement documentation, issue logging, and tracking. She holds an MBA in Information Technology Project Management and a Bachelor’s of Engineering degree in Computer Science.
We also have Harshal Vora. Harshal has more than six years of experience planning, executing, and delivering on-time quality of end-to-end solutions in mobile development in roles including automation engineer, business analyst, technical project manager, and QA manager.
A few housekeeping requirements we need to review: first, this webcast is being recorded today and will be distributed via email to you allowing you to share it with your internal teams or watch it again later. We will send this out to you following this webcast. Second, your line is currently muted so please feel free to provide any questions in the Q&A panel, which you can find in the center part of your webex screen at the very top. It looks just like this. At this time I’m going to go ahead and pass it over to Disha and she will take it from here.
Disha Thakkar: Thank you, Josh for that introduction and hello to everyone. And thank you again, everyone for joining us. So in this webinar we are going to cover some of the quality challenges that are based or that are offered in this presentation: what is Shift Left and how you can resolve some of the quality challenges that we’ll discuss in first point. Firstly, what are some of the value benefits or what are many of the benefits of following the Shift Left approach and lastly followed by understanding what are the tools which you can use for the Shift Left automation framework.
So, before we move to what exactly is Shift Left, let’s look into some of the quality challenges offered in the field’s spacing. We’re moving on to the end of our direction and we’ll start with this environment and exactly with the Requirement stage. So, in this slide what we have tried to do is we have highlighted the very high-level of stages of all the ANP projects, starting from requirement to development to the build packaging, testing, and finally we’ll deploy this into production and type.
So, we’ll highlight some of the challenges at each and every stage. Starting with the requirement stage, into this world everybody is facing the evaluative problem of development and the meat of what will be addressed during development. The main problem that all the developers and all the testers face the ever-changing requirements that comes from the customer’s mix.
The customers are always coming in with this requirement and they will try to keep on adding newer and newer features in terms of new user stories. When we are talking about all of these requirement changes what happens is you cannot define it at all and then you cannot define all that will be related in this O.
Also, when we started the management team, when the development team is approached with such misunderstanding in this Requirement we know that your developers will try to assume so many on their own. So, there will be lots and lots of implicit requirements and this implicit requirement will lead to very short term methods required to develop this product.
Now, when you have applied all of the short-term methods and variables and applied them online to this product, which is depending on what client is working or what customer they’re needing at this point it doesn’t result in a very good quality product. Notice that it can also lead to failure in some of the cases. And now the developers are ready with some of the bits and pieces and that will inform – suppose our developers is ready with one eventually. When this developer will push on this user’s history and that developer as well, onto the SCM server, which is proper conflagration management server.
As this stage, these spaces will be built and then they will be packaged and then they are deployed. Now, this developer is going to deploy this package or this forwards it onto the testing server for the testers to test. Into this scenario, normally this whole process is mostly present with many organizations, but the problem happens when this process is manual. At this stage, not many of this organization is following this methodology of making it continuous or on making it automated.
During the deployment process if it is not automated, then it becomes very inter-dependent of very heavy variables on each of those. So now your testers have gone onto their testing server. What happens in this case is the common mindset or the common notion with which the people or the agile teams are even working on it is that is a meaningful, but should be under development.
So, the development team originates from the very first case of the Requirement in terms of the way they are involved with the Requirement understanding. They are also involved with the clients’ interactions, but what is missing in this case is the testers. The testers are not involved from the very first case. In this case, the people or the product management teams claim that the fee is just an overhead and they need to just get rid of it as soon as possible. So that’s why they try to do the testing at the very end.
When you try to squeeze in the testing at the end it becomes somewhat of a bottleneck and rather than finding the problem what happens is that the testing team ends up moving it very faster and compromising the quality of the product at each and every stage.
Lastly, when we are talking about these stage servers or the production server – this is the main task that will come from the operations team: not to omit any of the servers, whether it is your testing server or your production server or your case server. With respect to teams and the waste that comes from waiting on the development makes a bigger task for the operations team. We have seen in many of the examples that the majority of the teams have to waste a lot more time just to wait for all of these environments to be available and to be ready for them to deploy their solution on that.
Lastly, if I had to just summarize what I have to give you the biggest challenge that everybody faces and that is the communication gap that happens at each and every level or at each and every stage, starting from Requirement to Development to testing to define the production and finally deliver it to the client. What happens in this case is that when you have got explicit requirements, in that case you try to mis-communicate; or the product management team mis-communicates with the development team and with the testing team. This leads to lots and lots of emotion.
When you talk about the implicit requirements but then all you are talking about is the explicit requirements, but when you talk about the implicit requirements, a lot of times your developers will eschew so much on their goal that there will be a lot of misinterpretation of the client’s requirements and your client’s needs. Also, when you have this agile project development in place, at that time there are lots and lots of complicated business requirements that will come from the customer’s side. Now, to make this complicated – the business requirements – is to make it very simplified and then everything moves, all the developers, and all the testers are also part of the biggest challenge.
So, according to us, this gap which happens between each and every one of the stages is one of the major challenges that limits your results. What happens when your product or when your project development life cycle is faced with so many different challenges at so many different levels? At this stage right from the requirements where you have miscommunication or there’s a misunderstanding that happens, right from that very first stage your bugs start to come in or are creeping into your production development.
Now, when your bugs start to come in right from the very first development requirement stage, then we move on to the next development level. Those bugs keep on multiplying all of the time and that too makes each and every stage and detail of this product – these bugs will multiply in many forms. So, what happens in this case is by the time your testers have got a product for testing this product is overwhelmed with lots and lots of bugs and your testers will just give it all – they will try to squeeze this test in and then a poorly qualified product reaches the customer or it will hamper your faster time-to-market goals.
Now looking more in depth at the bugs: so, from where exactly are these bugs coming or where exactly will you find these bugs in larger proportions? First you can see here that this is something that we have found from our experience that the majority of the bugs will start from the Requirement space itself – 56 percent – and where the rest come in is the Design phase. Now, if we talk about any traditional model what happens is our testing team comes into the picture only during a certain part of the development; that is the code phase that we have shown here.
That is when the coding starts, so by the time your testers have got the product to test, 83 percent of the bugs are already present in that product. In that case what will happen is your testers are trying to move very fast, so they will try to ignore the majority of these bugs. Now, when they to ignore the majority of these bugs, these bugs will definitely come in once you have provided or you have posted your product onto these production server sites, which is accessible to the customer.
So, what do these bugs do when they come into it at such large numbers at each and every stage? In terms of cost, what this number is that we have showcased here and defined is when a bug is found out at the Requirement stage, so the unit amount of time that it will take to resolve this bug at this requirement stage is one, but if you find the same bug at the SIT level, that is the systemic integration testing level, then it is 25 and when you find the same bug at the Production Support site, the unit amount of time that it takes to resolve this bug will be 150.
Looking at the other sites; that is in terms of cost, what is the impact that this bug will do to your product development life cycle? So, when you find the bug at the requirement and design stage as you can see here it is very less costly and it is even negligible in terms of the amount of cost that it takes when you find a bug at the Production Support site. But as we have seen previously, what we are doing is we are focusing our testing on the latest stages. That is the system integration testing or at the UAT phases or at the Production Support time.
And when we are focusing at such a huge level, then there is so much increasing time and so much increasing cost to resolve this bug at these stages. Also, when we have found this bug is this many amounts at the later stages what happens is there will be frequent re-testing. Now, this frequent retesting will, first of all it will hamper your cost of time-to-market that you had wanted to achieve. It will also, in terms of cost as you can see in this slide here the testing costs will trace in the wrong direction, giving you lots of late product.
Your customers will experience so many of these same effects that you will never be able to satisfy your customer in terms of the product quality. Moving on to our solution, that’s how Shift Left can help you to resolve all of these things. So, first of all let’s see what exactly the Shift Left Approach is. First, I have to explain in very layman’s terms in just one line that Shift Left suggests that your testing shouldn’t be held until the very last few days before you need it. The usual test should start early and you should always find the defects early. This is the easiest and the simplest way of explaining what Shift Left’s strategy or approach is.
So, currently in many organizations what is happening is you are testing your applications and this testing takes place between this level of the development phase, it peaks at the testing phase, and finally ending at the Production Support phase. In this case when happens is your testing team is waiting for some of the descent pieces of your application to be developed and for your application to be deployed onto this testing server.
Now, when your team is waiting for this test to come, it is not a very good utilization of their time. It often causes delays when you resolve your defects at the very later stages. This is adding risk to your project in terms of it can fail horribly at the end or the Production Support site. When you are trying to find the problems and when you are trying to fix the problems at the very later stages that is when, as we have seen earlier, this becomes very expensive in terms of time and cost to fix it.
Also, in this conventional or in this traditional concept what happens is that as you can see here, 50 percent to 60 percent of your main focus goes on to your end-to-end data UI interface testing and you give your minimal effort that is zero to 10 percent on your unit testing. Now, this unit testing is the testing that is being run by a developer and this unit testing comes off as very powerful and useable as well as very powerful and automated; sometimes in some cases it is automated except in step cases.
So this is the very wrong approach of conducting your tests. This leads to very poor cost efficiency and limited test coverage because you have got very limited ability to the system. So now what we suggest through the Shift Left strategy is that once you involve your testing team as well as your automation team very early in the project commencement, so your testers should be the ones who should be able to join the Requirement session to completely understand what or how the project is going to work and what are the client’s expectations and needs.
Your testers need to join the design sessions and understand that how your customer is working and why so many changes will come into this agile project development. Also, when you have your testers ready with the back-end developers those testers along with the back-end developers, they can stick together and they can understand the what-if scenarios and they can clear the test area.
Also, some of the testers were free, then they can also join in the API developers and while the API developers are creating new services and creating new APIs at the same time your testers can also test these APIs while they are still in development. You can also pair some of your testers with your User Interface team so that these testers can test something on their own machines before the User Interface developers have also put some of the builds onto the production server or onto the testing server.
By suggesting this approach works, what we are saying is this approach will try to fix or it will try to avoid whatever retesting that will happen if your bugs are found at the later stages. Shift Left will try to avoid all the delays that would occur when a major defect is found during the production server or during the later stages of this project development.
The main aim of this approach is to avoid any of the later-found issues while you are still conducting the testing if and when your code is being delivered and deployed. From our experience from most of the projects that we have implemented we have found that by implementing this strategy what we are doing is you are not putting the testing at the end, but you are sprinkling your testing over each and every step and over each and every iteration, so what happens is this case is your test execution is very smaller and your test execution is very faster because you have been able to encompass and you have been able to resolve most of the defects even before the development has started.
At Infostretch we have picked up the three main goals for Shift Left. The first is that we want to increase the quality of the product along with the speed. The second is there should be by applying this strategy we need to have a very faster time-to-market. And then the third one is we want to reduce as many unpleasant surprises as is possible that we could find in the Production or that we could have found at the later development cycles.
Also when you are applying or when you are following the Shift Left strategy automatically your main focus happens to have all the automated test cases and all the automated unit acceptance testing that the developers are creating. In this case your graphical user interface testing is still there, but that counts only if you don’t look at equipment in which you will be testing the display on the screen.
So, moving on to the next one what exactly are we shifting left? In this I’ll try to focus on mainly five major points and out of the five the first one is the testing. As we have explained in Shift Left strategy, the testers have to be involved in this product development life cycle from the very beginning. So the testers need to test and need to create the test cases, identify those test cases, and they will have to begin the test execution very early. Your testers need to plan, create, and automate all the test cases very well in advance.
So, this is what we have defined internally within our team, that for any successful agile team building we’ll have two types of resources in our team. One type of resource would be to find the test engineers who are technically – who can adapt very, very technically – and who know the business domain knowledge very well. This kind of tester can help in identification of the test. They can create the test. They can perform manual testing too for this case.
Now, on this type of test engineers, which we’ll call Automation Test Engineers, these test engineers will be technically very strong and they will only be doing coding in and out and they will be involved in the development of the automated test script. Now, this automation test engineer can perform or review – they can analyze the software with automation, so along with the manual tester they will form a very good combination of the testing team.
Now, once the testers are going to provide their feedback to the coding or the development team, your coding teams need to conduct the very high-level first step. Your first step could be for following the Shift Left you prioritize all the feedback for all the defects that the testing team is throwing at you. So, whenever you are getting so many percentage of the defect, that you are getting at the coding stage, the development team needs to prioritize based on the importance of the client’s needs. They need to process and finally they need to resolve based on the priority of whatever they have set all the defects and the feedback.
But this can be successful only if this coding team can finish their work on the feedback in a very spirited amount of time. Now, in terms of resource allocation the resource manager should be very well aware of what exactly they and what we want to achieve through this Shift Left strategy. So, based on that the allocation could be in such a way that there is a particular amount of time – any particular time – that our result is we’ll be able to give feedback very quickly to the development team and the developers are able to act on this provided feedback by the testers.
In terms of deployment, it is a very good practice or if you want your Shift Left strategy to work successfully you should have or you should automate this whole deployment process. And by automating the deployment process what we mean is first of all there should be an automated drop that could result, or that could deploy on a virtual set of machines. Then they could install the interface and then it could provide the automation. So this whole process, this whole three-step process could be automated so that your deployment becomes very fast.
Now, if we want to take one example let’s take an example of conducting of a coding automation. So, you could have an automated job. Now, this automated job would revert a set of virtual services needed for this coding automation. They would install the latest build and lastly they would regard its performance automation.
To add to this, that could be the fourth step that will gather all the performance-related data. It will be short as the deploying at the dashboard site and it would always highlight that would be one of the potential risks or what are the risky areas, getting your development team all in unity with this. This automated deployment will speed up your whole process and it will try to achieve that faster time-to-market goal of yours.
Lastly, it’s the infrastructure. Now, in terms of infrastructure what one needs to do is, your development team along with and combined with your operations team, they need to plan, they need to automate, and they need to deploy the components all your applications feature in such a way that you have an ability of your servers at each and every time. Now, take one example. Suppose we need to develop a mobile application along with its package. So in this case, there is a very high possibility that there will be multiple teams that will be working in developing this mobile application.
Now, when we talk about this, there will be one team who will be working only on the mobile side, and there would be another team who will be working or who will be responsible for developing the whole back-end services. Now jointly this back-end team is responsible for creating any new services or any new APIs that are needed for the communication between servers and your mobile application. This mobile, front-end development is a small job so your mobile front-end team will definitely finish much faster the development before even the back-end team has completed it.
So, what will you do in that case? Your front-end team just cannot wait for your back-end team to complete their coding and then start testing. There will be a lot of waiting time and a lot of misuse of the resources. So, to handle this kind of situation what we suggest is have the test virtualization to handle the differences in feed and to handle those differences in providing the services. Now, what this test virtualization will do is that this test virtualization will enable your mobile front-end team to simulate the pieces that are needed for them to test with the back end.
At the same time your back end team can also keep on continuing the code changes and these code changes will directly be reflected on this testing virtualization. So your whole front-end team is still able to run the testing without hampering of the cost or having any interference from the back-end team and this will lead to your cost and your time savings to a major extent.
So now when we are talking about these five major pieces of the Shift Left strategy the most important are the one thing that governs this major parameter is the amount of time in which you finish each of these steps. So if you want your Shift Left strategy to be successful, it is of paramount importance that you have to complete your testing, you have to complete your coding, your allocation, your deployment, infrastructure – everything within that stipulated amount of time.
If you are able to do that, what Shift Left will enable for you is it will help you to move your defects to go to the very left side. It will help to reduce the issues that you have will have found very later and it will help to reduce and resolve those defects even before your development has started. By deployment you will be able to achieve very, very early automation which will enable you to have a very stable product.
So now let’s look into some of the very high-level activities that one needs to follow when we are talking of the Shift Left concept. First and foremost is your testing team should be involved from the very start of the project. Along with your development team, along with your product management team, and even when you are talking about the customer’s involvement, your testing team should be a part of all of those meetings that are being conducted to understand the design and architecture of how this product is going to be looking like. It has to be ensured that everybody on your team – that is the testers, automation engineers, developers – everybody understands the requirement.
Now, your automation in this case what happens is when we are talking about the agile projects it is bound to happen that there will be lots and lots or Requirement changes coming from the client. Now, the automation team has developed an automation framework. If and when your requirement changes or if and when the customers keep on changing the requirements it is possible that your automation team has to very frequently change their automation scheme and their automation strategy.
So, just to avoid having the usual time on just changing or omitting automation frameworks it is better to have what a customer is able to have as an automation framework in place. There are many tools in the market and ones that are straight to the automation framework. It will enable the automation team engineers to have that kind of flexibility to use customer’s enabled objects and items which could helpful to them. Whenever there is change in the requirements, then the automation team engineers would then get the minimal changes, and automate the changes.
After this there are lots and lots of previous defects and then answers that have been provided by this automation team as well as the manual testing team. So, this defect announces me to be discussed purely in the status report. That needs to varied in a meeting as with the developers and when this kind of meeting takes place, your development team and the testing team can bring thoughts and they can discuss and be aware of symptoms and solutions of these defects.
Now these defects, along with the resolutions and analysis, these defects can be stored as a Central Repository so that they could be used for any future implementation of the Shift Left based project. And once they’ve all been use a test management tool such as the QMetry and the other frameworks that are available in the market. Lastly, to monitor all of these points it is very important to have a continuous monitoring of these defects at each and every stage so that you don’t have defects at any particular stage over a certain limit.
Now, after understanding what Shift Left is and how you can achieve it, let’s look into some of the benefits that could come out of the numbers. So, in this slide as you can see this is a very traditional [inaudible] [00:34:27]; benefits Requirements, then benefits Design, and then benefits Development. And each development will be divided into Sprints. In one particular Sprint, let’s for example say that you have a Sprint of two weeks, so that will be in one Sprint two weeks of Application Development and finally we’ll also have to wait for the testing.
Now, if you have implemented this same project using the Shift Left strategy in that case what would have happened is, your testing team and your automation team are also involved in the Requirement stage. So, they have completely understood the product and they are very well aware. Now, immediately they can start on identification of the test cases based on the project; they can also identify the test cases which would be automated and based on that, when done the automation testing can create the test script and they can evaluate the test case.
In this case, when the development of this Sprint, a defined two-week Sprint starts, at that time your coding will definitely happen only for two weeks. That will be your application development, but during that particular time that will be the only test script execution based on your automation input, so you can achieve this execution in merely 1.5 weeks because you’ve already identified your defects very early and before development you have resolved them. You have already identified your test cases before even your development has started. And the only thing in terms of testing is this test script execution, which will be very fast and it will be very quick and very effective at the same time in finding these bugs.
So, in this kind of strategy we can say that there is already a 25 percent reduction in your testing cycle and it will give you a very much faster Time to Market. Also, as we have seen earlier, you are able to find 95 percent of your bugs through this Shift Left strategy by the time you have even started your Development phase. So this means that you are spending less time on your testing, you are spending less cost in terms of resolution of any bugs and at the same time you are ensuring that you have got a very high, top-notch quality product.
So, now moving on to some of the intangible benefits are that you are able to do the automation very quickly. One can find most of the defects by the time the development team has started to work on them so this is a very dramatic quality improvement in terms of the delivery pipeline. It ensures that once you have been able to find out the defects at the earliest stages before the development it means that you will find very less or even to some extent minimal defects when you are talking about the production site. That is, the customers will not be able to find many defects when they have their product on the production server side.
Also, all the members that is starting from your automation engineers to your product management people to your developers are definitely involved from the very first stage of the development life cycle – that is the Requirement phase – so even the testers can engage themselves in some of the development phase and some of the design phase and then some of the automation phase.
From our experience we have found that when you find the defects early in this project development life cycle it means that you can also resolve those defects very early. So, when you are able to resolve those defects early it means that by the time your product has reached the production service side or by the time your product has reached the customers, in terms of quality this product has matured on many levels. That’s why you are able to give your customers satisfaction in terms of the quality of their product.
To add to this also, your Shift Left is trying to focus a bit on automating your Build and your Deployment process. Now, when you try to automate your Build and Deployment process and you try to put all your builds onto the testing servers or onto UAT servers using this automated approach, it gives a very stable version of your product.
One of the major keys areas are that you are imposing only to some extent a bit of Regression of automation. Now, when you are automating your Regression test cases, you are either using cost or time to perform this regression as well as your integration testing. To some level you are automating your operation so that will give you a very faster deployment along with the readiness of your environment. Also, when you have gotten all of the defects found at the very early stage it means that you will be provided with the most stability of resolution and then it will try to eliminate anything here of the defects that would be found in your production site.
Lastly, we would like to just focus on virtualization, but it is also focusing on virtualization of the infrastructure. When you are trying to virtualize your infrastructure it means that it will enable only testing of the services or systems that would have been otherwise very costly or difficult to test out. So, before I hand over my presentation to my colleague I would like to just say that Shift Left is based on the three major pillars: that is your people, profit, and return. Now, this technology is particularly advanced, but we have got the right kind of tools in place. My colleague will explain one such diagnostic about that tool. What needs to be done is to work on the people and the process.
In terms of people, your developers and your testers should have that kind of a mindset to adapt to this kind of strategy wherein they can test very early and avoid that kind of defect. And in terms of process they should have that kind of process. With this, I would like to invite my colleague, Mr. Harshal Vora, to give understanding on a few of the automation frameworks.
Harshal Vora: Thank you, Disha. Good morning, good afternoon, good evening everyone. So, as Disha mentioned, the whole Shift Left methodology is not only about people and processes. It’s a good combination of people, processes, tools and technology. One such tool is QMetry Automation Framework, which is an open-source framework available for downloads for all the QA and QE engineers out there who can get their hands on it. It’s a very comprehensive framework built on top of Selenium and Appium to give you an Omni channel experience of doing your testing through automation, whether that’s a web application, a mobile application, or even toward the web servers we saw earlier, right?
So, it’s an all-in-one tool that enables us drive our automation and move more towards Shift Left or get the quality earlier in the life cycle so that we get that comprehensive test coverage over a period of time. And as we saw that curve that Disha was talking about, shifting the whole quality life cycle earlier in the product development, and how we enable that, right? So, one of the enablers is adopting the behavior during development or a BDD approach where we are trying to withhold the test case authoring, involve the product managers, involve the developers, involve the manual testers to write my test cases as soon as the design requirements are defined.
What that enables and that ability is a plain English-based test case is under which we are writing our automation based on my already-identified methods or classes. I am writing those automations, which are in plain English and anybody can write it and validate it early in the life cycle. The other thing is the whole idea of automation being brittle and ease of maintenance. So that’s we are enabling with the page object methodology. You have the whole idea of having your automation start early in the cycle and as my application evolves over Sprints or Sprints, my automation can become brittle.
We want to make it easier using the page object model that you don’t hard code your test data or your test assets in your automation code. You isolate those layers and if and when their application changes your application become more modular and portable to make those changes.
Also, the reporting and the test execution is an important part of the framework when we get the whole trending reports, so that enables us, from the quality perspective and with the predictive analytics it helps where we need to concentrate our quality efforts, whether it’s earlier in the life cycle, later in the life cycle or for what modules, whether it’s a login module, whether it’s a help module – what has been a problematic feature over a bit of time? So, those kinds of predictive analytics are part of the framework as well.
Next slide, please? This has the high-level benefits which I already talked about. It helps the Reusable Test Assets, so you can have your test assets that have carried over from one Sprint to another Sprint; you have your test assets carry over from one module to another module. So you don’t have to rewrite your test cases. You don’t have to rewrite you automation again and again. And also, increase collaboration: with BDD what it enables is that everyone pitches in for the quality of the product, rather than quality being the sole responsibility of the test engineering team.
And then the Unified Scripting across all the platforms, whether it’s web application, mobile application so you don’t have whichever between three or four different frameworks when you are writing your testing or your test automation. You have one framework from which you get everything. You don’t have to identify one test case for web service, one test case for a mobile application, one test case for a desktop application; you have one test case, and under them there are multiple implementations.
And last but not least is the data-driven testing. As I said automation becomes much more modular, much more dynamic with this data-driven approach where you have not hard-coded your test data. You have multiple data sets against your testing. That gives you more confidence in your Shift Left, helping the whole process of Shift Left, shifting the quality assurance team or quality engineering team more closer to the development team and accelerating the whole agile process. Those are the benefits of the QMetry Automation Framework.
Josh Galde: Excellent – thank you, Harshal. I think that wraps up our content and thanks again, Disha. That was really great. I wanted to give everyone an opportunity to submit questions. So, now is the time to do that. If you have a question that you have been itching to ask please go ahead and insert it and put it into the Q&A window and we will address it as they come in. It looks like we’re already getting a couple of questions here.
Let me read one over that we just got from Nancy. She says; what is the difference between Shift Left and QE? And I believe this is for Harshal.
Harshal Vora: Sure. That’s a very good question. When we talk about Shift Left and QE, they go hand-in-hand. QE is more of a term of Quality Engineering, which is more about skill sets and people and Shift Left is more of a process or a methodology. To enable the process or methodology we’ll need that skill set and expertise, which is Quality Engineering. That’s where they both merge together or join together, right? There is essentially not much difference. They both go hand-in-hand.
Josh Galde: Excellent. Thank you for that question. So, I’ve got another question here. Does QMetry support desktop application automation?
Harshal Vora: No. The QMetry does not support native desktop application.
Josh Galde: Okay, great – simple question – another question here from James: is Shift Left all about automation?
Harshal Vora: Not really. Yes, automation will definitely help us get to Shift Left earlier and faster, but Shift Left is not all about automation. Shift Left is about getting the right process into place, getting quality involved earlier in the life cycle, and yes – automation will definitely make that process faster. It is an accelerator and I would not say it’s an excess shell ingredient for that, Shift Left.
Josh Galde: Okay. And it looks like we’ve got another question here from Paul. It says; what is the role of CICD in the Shift Left process? I think they’re referring to how does CICD play into this? It’s obviously a popular term these days and a lot of people are looking for it to implement into their testing process and development.
Harshal Vora: Sure, and that’s a very good question. How Dev Ops and Shift Left can help quality engineering teams and that’s a challenge that has been faced by the QA teams or the QA community as a whole. It comes to Dev Ops and getting toward Shift Left, getting towards agile processors – how can the QA terms, the conventional QA teams adapt to this? One thing about Dev Ops is more with automation Dev Ops can become much more efficient and much more achievable.
With Shift Left in the mix as well, that will increase more collaboration the development and engineering teams and the Ops teams and that’s where all these merge together with Dev Ops and Shift Left, where everyone is involved to get the processes and tools and technologies in place to achieve the quality faster and get the time-to-market to shrink.
Josh Galde: Okay, great – thank you and it looks like we have another question here around QMetry. What programming language does it support? I think that’s specific to QAF. I know you mentioned it earlier. You might want to reiterate.
Harshal Vora: Sure. So, QAF supports – it is BDD, so Behavior During Development, so even if you don’t know any programming languages you can start writing your BDD or test cases. But if you want to write your programming then it supports Java, and as well it supports keyword-driven, where you have your keywords defined and based on those keywords you can start writing your test cases.
Josh Galde: Great – awesome. And it looks like we have time for one more question. We also want to keep sensitive to our time limit today. This question came in about Shift Left and I’m not sure if this is for Disha or Harshal, but how do you balance the workload for the QA team? We believe in the testing teams getting involved, but are frequently not available in the beginning because they are still working on a prior project. How do you balance that workload?
Harshal Vora: That’s again a very good question. That balancing act is a top-down approach. We have seen a lot of the time that the development screens and the QA screens are staggered by either a week or two weeks. What we want to achieve through Shift Left is to get the development team, development Sprints aligned with the QA Sprints. So as soon as my development starts I need to have my QA start as well from day one. When you have that kind of approach and with automation in place, even during your Regression cycle you have your Regression automation running against your bug fixes and all those enhancements. Whenever there are new developments the majority of the QA team is focused towards supporting those initiatives.
You don’t really need a full-fledged from the QA team from Sprint One itself and that’s where the balancing act comes into play.
Josh Galde: Okay, great and I’m sorry one last question just came in and it comes up to in regards to Shift Left: does infrastructure offer any sort of assessment or if my company wants to sit down with you can I do that to assess my practice?
Harshal Vora: Yes, sure. We can definitely arrange for an assessment session in terms of the processes, tools and technology, and we can definitely help organizations get to the whole maturity curve. We have the whole quality engineering maturity curve and we can help define where we are and where we want to be in a specific timeframe.
Josh Galde: Great. Thanks, everyone and thank you for joining us today. You will receive an email, probably in the next day or so – definitely by tomorrow – with a slide presentation and a link to the webcast replay. If you need to contact us sooner please feel free to reach out to us via our email, which is info@Infostretch.com and you can reach us by phone at 408-727-1100. Thank you so much for joining us today and we will see you next time. Take care.