 Welcome to the session, Business Impact Delivery Using Test Automation by Iran Barlov. We are really glad that they could join us today. And yeah, without further delay, over to you, Iran. Thank you so much. So, hey everyone. Good morning, good afternoon. Good evening. My name is Iran Barlov. I'm a software engineer for over 20 years now. And I'm currently working for Apple Tools. It's a visual testing tool, but we're not gonna talk about this today. We're gonna talk about the automation world and why it is important for every business to shift towards automation. But I would recommend looking into this tool after this talk or even we can chat about it later on in the Hangout Room. I founded the Canadian Software Testing Board, which is part of the ISTQB. I lived in Canada for 10 years. Now I'm based in California. Sorry, I didn't say that at the beginning. And my true passion is automation. I'm automating everything at work from web, mobile, desktop applications, all the way through home. My entire home is wired with every smart device I can talk to. I believe I'm very passionate about it, like I said. I think it makes our lives easier. And obviously it makes our work easier when we automate our processes, right? It improves our business outcomes. And that's the goal basically at the end of the day for our employers. So what we're gonna talk about today is why is it basically important and where do we start basically when we are looking at automation? So if we're looking back to the year 2000, since then more than 50% of Fortune 500 companies disappeared. The reason for that is that they didn't catch up with the digital world, we'll call it, or the technological shift. They needed to move rapidly and to catch up with the increasing demand from the end users, from their customers. And businesses that didn't catch up lost to competition that did automate processes and improve their digital footprint. So what is software test automation? It's basically a software testing method which uses other tools to test the software that you've built. We have expected results in mind and we are putting our system through this automated process that's normally time consuming. It's normally repetitive. And we're trying to automate everything that we're doing manually. So today a lot of companies are still doing a lot of manual testing. We've seen a major change obviously in the past few years where larger organizations move towards some extent of test automation, but they're not at the full coverage I would say. Of course, when you get to that high rate of coverage this is where you'll see most benefit of your test automation investment. Now, the traditional product lifecycle is constantly shrinking. Now, when I'm saying shrinking, I'm talking about where it used to be years or months to release a product update. We're now seeing that being shrunk two days or even sometimes hours. I used to work for a CICD provider a few years ago and the need there for constantly delivering the CICD concept means that they want to push things to market as soon as they're ready. So in order to achieve that they have to have all the moving pieces from the code through the testing, through the deployment, everything connected with zero friction. And testing was a big part of it because you don't wanna hit the publish button before you got your test coverage. And this is why QA was tend to be the bottleneck because we used to stop everything until we're done with our testing. So we don't wanna be that bottleneck and this is why the pressure is on us to basically automate our tests. Now the consumers, our customers, they demand for high degree of responsiveness. This means that our traditional go to market cycles has to be shorter like we mentioned earlier and we need to also be able to respond fast. The problem is if we do not respond fast our customers have so many alternatives today, right? I mean, if you go to a website and you try to buy something, sorry, it doesn't work. You don't give it a second chance anymore. You jump back to Google and you move to the next result or the next provider or there's, if for example in Amazon they don't deliver it the next day you'll just keep on looking until you find the vendor that does deliver the next day. So that's a lot of pressure on businesses and this is why we have to streamline the entire operation. Now it is so complex because our consumers are consuming our brand across everywhere. And what we're seeing here is basically not only our infrastructure, our system itself became complex with millions of microservices that we have internally, the complexity adds up and the permutations are becoming infinite in terms of what operating systems our end users are consuming us on. And speaking of operating systems, of course each of them has its own version. On top of that we have the browsers that everybody's using and this is just obviously a partial list and multiply that by the number of devices and screen sizes that they're consuming it all the way from an iWatch to your TV from Xbox to Switch from your iPhone to your PC like it's infinite and they're demanding the same service from your website through your mobile app through your phone application for example. And again, the pressure is on us on QA team because we need to automate all of that and to be able to give the thumbs up to go to production. There's another team member in that life cycle so there is the developers and there is the QA team but there's also the DevOps engineers. The DevOps are kind of like the glue that puts everyone together. It is obviously gaining high popularity in the software development world in the recent years and what they're doing is like I said they're connecting the dots between everyone making sure that this pipeline is streamlined perfectly from the build of the project from the testing of the project on staging and when all the systems are green all the thumbs are up, we're pushing to production. So there is also that piece of the puzzle. Now I mentioned earlier about investment and there is obviously a high upfront investment and the initial phase of the automation it will pay up for itself very quickly. The minute we start seeing time savings and not only that but also catching bugs that you and I cannot achieve by using manual testing because in manual testing we're limited to the number of hours and the number of resources that are assigned to a certain task but with test automation the machine can run over and over again without getting tired and without missing out on any small piece that's broken in the system. You and I will miss out a small icon missing at the footer of the page but the machine not. You and I will miss a typo but the machine won't. So when we need to put more focus on letting the machine test and try to give the machine more power to evaluate our software and we will orchestrate all of that. We will look at the test result, we will set the expected result and we will maintain it as we go along. Now a huge impact of the success of the whole process is by choosing the right tools. So instead of going shopping and choosing what tools we need to use we need to first look inside and understand what are we trying to solve here? On top of that we need to look at the team and understand what are their skills? What skills are in the market? You know, you don't wanna pick a niche tool that no one else uses and then it will be very hard to find team members who can operate that tool who can write scripts for it for example. I've seen a lot of cases where large organizations create their own flavor of open source tools and it's very hard for them to find people who wants to use it and then at some point sometimes open source projects are dead and then the enterprise is now kind of owning it because the community doesn't maintain it anymore but they base their entire test automation framework around it. So that's a huge risk. So it's very tricky and you have to like I said at the beginning you have to ask yourself what's my goal? What do I wanna test and what's the most commonly used tool in the market? It doesn't have to be open source and free of course it's ideal but sometimes you might want to go with the paid tool. There are advantages for that. I mean you get proper support you get constant updates coming out and the community won't drop the ball on it and then you'll be stranded with a tool that no one maintains and now it's up to you or you'll have to switch to another tool which is a headache by itself migrating from one tool to another. So tools is one, second is language, right? I mean these are the most popular languages in the software testing field I will say. JavaScript is on top, Python right after that Java and C sharp there is, you know there are more after that but these are the most commonly used languages. So make sure that your team is familiar with them and you know if not it's most of them are easy to pick up especially for test scripting capabilities. So the scope that we're going for you should never aim for 100% test automation. In many cases it's not even an ideal situation because there are you know parts of the application that has more impact on the business and other parts that have less. Some test cases might be better handled through manual testing and automation just add additional burden on those cases. Sometimes the effort you're putting on to test a certain component that's used maybe half a percent of your users is not worth it. So you have to understand even work with product to put priorities on where do you start and what coverage are you going for? Try to stay away from that 100% it's just I've never seen that actually happen or even the goal. Now once you implement your test framework it's not done it's not like a one-time effort I've seen companies make a mistake by asking R&D to set up the test framework for the QA team which was manual testers and just tell them okay prepare the test framework for the manual tester that all they need to do is hit the run button but it doesn't end there because the product keeps on changing so you need to keep changing or catching up with your test framework. So this means that you can't have all manual testers on your team that just click the run button. You have to have automation test automation engineers on your team that can edit and modify or add new scripts, new use cases or modify them when your website or application changes and keep up with that. Now in order to pick the right framework like I said you need to understand what you're looking at. So here's an example of frameworks and tools that are out there in the market. They're open source free and you can use them today. Obviously we're at the Appium Lite conference so Appium is one of them focused on mobile devices. Selenium is geared towards web testing. Robot framework is more of a keyword driven. You have like a table of fields where you can define the URL you're going to, the values you're going to send to certain fields and so on and so on. So it's kind of like an elaborated Excel sheet testing approach. And Cucumber is another tool. It's called the tool category. It's called BDD behavior driven design which means that you are writing the story of the test or the use case in literal words that we can understand such as user and their website and product to cart, check out product from cart, enter credit card login and so on and so on. You literally build a storyline and that story is translated into your scripts that someone has to write them behind the scenes. So all these at the end of the day behind them there is scripting required. These are not the record and playback tools that are in the market. They're great. We're using quite a few of them but they're good for certain use cases. At some point you encounter more complex scenarios where you need full control, for example, of the application. And for that you will need a test automation engineer that can actually write a script. I think I'm just in time. We have four minutes, right? Two minutes, questions. Let's look at the chat here. Yeah. Okay. So folks, you can ask the questions in Q and A if you have some. Till that time I can ask one with the languages that you mentioned like JavaScript. Looks like a developer already knows these languages. So what's your opinion on a QA engineer doing the automation versus giving that responsibility to the developers themselves? Oh, that's a very loaded question. I don't think it's the right thing to do. QA and developers, I used to joke they're like dogs and cats. Like they never get along because they have a different mindset, right? They look at things different. The developer just wants to finish writing new features that's all they're obsessed about where QA, we're more geared towards, it has to be perfect, it has to work. I'm paying attention to the smallest details. I'm not saying software engineers don't do that but they have a different goal in mind. So when you're obsessed with a new feature you're working on, you're gonna miss out on, oops, I broke something else on the way of building that new feature. So let the developers build their stuff. QA automation engineers will build our stuff and the DevOps, the third leg of this party, right? It's somewhere in the middle as well, which is another engineer. And together we are better literally. Like I said, if you leave it to R&D and I've seen quite a few organizations where they actually have R&D build the test automation and the testers have no idea. So I meet with them once in a while and I tell them, okay, let's start a new use case and they're clueless, right? And it's the worst thing that you can have. You have a team of 10 testers, none of them can run a test. They can run it, they can analyze the test results but they cannot add new use cases. So you're wasting R&D time to write use cases instead of spending time on training your QA team on those languages that are in front of us and teach them like it's literally, you can do it in a two-day classroom, right? I mean, it's not that hard just to read it and to know basic things. You don't have to know Java programming, objects are entered inside and out and understand all the design patterns to get started, right? Lastly, I mean, thanks, Iram, for sharing your experience with us today.