 Hi, I am Lakshmi Biddhi. I work as a consultant with Kolhapra. Welcome to this talk about automated OAS testing using containers. So, first of all, what is OAS testing? OAS testing involves different components. We may want to test OAS installation procedure, which includes activities like setting up location, time zone, disk partition, creating accounts, network setup, etc. So, once the installation procedure is completed, we want to verify the boot process, whether everything was properly installed or not. And we may want to extend this test to logging into specific desktop environment. Optionally, we may want to test a desktop application too. So, all these form different parts of OAS testing. And also, the testing framework should retain the logs and record them so that we can examine them later. So, here is an objective for an automated OAS testing tool. The testing tool should be easy to set up and run in any environment. Let it be your personal system or a cloud environment, or even a CI CD environment like Jenkins. So, it should be able to run it without any issues. Next, since you are using personal laptops or desktop, developers can test their changes locally without depending on QAT. And also, the QAT tool should make it possible for new developers to contribute to the test cases. So, they must be easily add more test cases rather than spending time on learning new languages or something like that. Finally, the testing tool should record the logs and screenshots as test results so that we can examine them in case of regression or failure. So, there are few tools which can be used for this automated OAS testing. But it has several shortcomings also. So, here you can see list of tools. On this, OpenQA is probably the only tool which fits the requirement. But it has few disadvantages like a high learning curve and dedicated hardware setup. So, if you are not familiar with Perl, probably you have to learn it to write a test cases. So, those kind of things comes with it. So, we need a testing tool which is much more easier for newcomers or beginners to learn within few hours and just start adding test cases within a day. So, with that objective in mind, so here is the proposed tool. So, as you can see on this, it relies on Docker desktop. So, as you know, Docker is pretty much usable anywhere. You can use it on your laptop or as part of CI CD or on any cloud platform, you can AWS or GCP. Anywhere you want, you can just launch it. So, the idea is to use Docker desktop, make use of Docker desktop. And then we have a chemo running inside the Docker desktop. And if you are familiar with PY autoguite module, you should know it's a pretty simple, dead simple Python module which helps to perform automations. So, the idea is to run the PY autoguite module as a test controller inside the Docker desktop. So, we will be launching a chemo instance from the given ISO image and set up a remote viewer. Then finally, we will be sending, giving input files which can ask the PY autoguite module to perform specific actions. Let's say like sending keystrokes or mouse events, those kind of activities. Finally, all these activities are recorded uses using FFMpad so that we can go back in time and check where the failure happened. So, let's get started with how the test tool works. So, if you look at at the top, it has something called task. So, it can say, for example, if you want to test a Ubuntu or Debian ISO image. So, installation process we can say Debian installer as a task. And then each task has nothing but a collection of files, they are called action files. So, these action files in turn will tell you what to do, what we should look for. It may be like finding an image or sending a key combination or running specific script or mouse events and those kind of things. So, this is how the tool works. It has only one or two components majorly, tasks and actions. So, we will see what is task. Actually, task files are the files with the end with dot task. This contains one or more YAML file names. These files will be executed in sequence and each YAML represents an action. So, as you can see here, there is a directory called task and it has a helloworld.task file. And in this file, you can see there is a YAML file, there is couple of YAML files. One is openterminal.yaml and helloworld.yaml. So, these two are two actions. So, this task, helloworld task has two action files. So, we will next look into what these action files will actually contain. So, as you can see the actions files end with dot YAML and it contains a key value path in this following formats. Say for example, it could be key can end with dot png or dot key dot type or sh. So, each file key extension kind of denotes its meaning. Say if it is dot png, then you are looking for an image. The action is based on an image. If it is dot key, it is a keyboard action. If it is dot as such, then you are executing some shell script. So, as you can see the value is delay time. Delay time is like after performing some action, wait for this much of time before proceeding further. So, as you can see on this couple of screenshots below, on the left hand side you can see openterminal.yaml and then few png files are available. And if you check the openterminal.yaml, you can see it has nothing but a list of key value paths. Say for example, in this start menu dot png colon 2, that denotes is like search for start menu png that image and wait for 2 seconds after clicking on it. So, this is how it will search for images. So, we will be populating images in a specific directory as we shown on the left hand side. And then we will be adding a yaml file to include those images and also mentioning the delay time wherever applicable. So, next we will look into some simple actions to get more clarity. Say for example, in startup menu dot png as we discussed before, it will find and click on the image startup menu dot png and wait for 2 seconds. And the 2 seconds is the delay time part. It can be negative also. If it is negative, we will just assert whether the image exists on our current desktop or not. Then if you see the third example, there is 3 images out there. Image 1, png colon 5, mg2, png colon 5. So, actually that means it is sometimes for whatever reason we may not be able to provide a specific image. So, we have a list of images. Even if one pauses, we may want to proceed with it. So, in those cases we can use this syntax. So, it will fight to find a single image from this one, from this list. If it pauses, if it unable to find the first image, it will check whether the second is available or not. In this way, at least one image is found, then the action is marked as past. Then you can see here comes the keyboard actions. There is an entry dot key colon 60. That means it presses the enter key and waits for 60 seconds. And then the next one is alt enter dot key and then control shift t dot key. All those things you should be familiar by now. Just sending of different combinations. You can send a 2 key combination or a 3 key combination with it. Then there is an action called dot type. In this case, it is a Debian dot type colon 5. So, that means whatever the current most portion is, there it will type Debian as a text. So, that is another action. And you have a script. We can even provide shell scripts. So, this will be executed inside the KMO using Python Fabric module. So, you need to set up your username and password properly for that KMO image. And then mouse actions. So, you can say write dot mouse means obviously it will click right click past the right click event. And right double click, obviously you should know what it must be doing. So, these are all simple actions that can be used inside the .yaml file. The next we will be looking into a small holo world test program. Say here you can see, by the way, you can clone the repo from above URL and you can even test it while watching this. So, just to clone the repo and you will have a script run test.sh and just pause the holo world task. So, it will produce an output similar to what we have shown in this screenshot. So, as you can see, if you look properly closely you can see it has start menu. It will search for 4 images. Obviously, you can make it from the image names. It is start menu, system tools, terminal open, terminal ready. So, by now that it ensures the terminal is ready. So, and then we have a holo world .txt. It will just read the content of the .txt and type it into the terminal. So, this is another way of executing commands within the terminal inside a desktop environment. So, another thing is sometimes when you want to develop a new test case, say as you can see it is not really, you do not have option of viewing what is really going on. If say if something fails in between, we may not know where it fails. It may show where it failed on the log, but viewing it while it fails, that makes a difference. So, in such cases, say we want to view the test progress. What we can do is just you can pause the expose port equal to 1, that implemented variable and then run the same program again. Now, just go ahead and open your browser with your local IP and just pause in that first the port is going to be 32.68. You can once you do that, then you can just view the progress of what is really happening. I would suggest you to open our terminal and keep the browser and then do it parallely. You should be able to view what is exactly going on the terminal as well as on the browser. So, next I will show you a Debian ISO image testing. So, actually the ISO image testing you can, it is already available, the images and scripts everything is available inside Debian Buster branch. You can just clone it and then expose the port if you like to see what is exactly going on. You can run the test, start the launch the test and you will be seeing the Debian installer getting downloaded from the latest version and the installer will be proceeding with the installation process. If you are interested, you can look into the chemo launch script which is available inside images Debian 10 launch ISO.sh and the remote viewer script is available under setup launch viewer. So, this is how you can test the existing setup if you like to get started with this tool. So, next we will be looking into how to add a new test, new test. So, as I mentioned earlier during the start of the session, it should be much more simpler to add a new test cases. So, here it needs only three steps, first step is just put the required images, text files, scripts under a test case name, test name. Say for example in this case images slash test name, you can place your images, scripts or test files whatever you want you have. Then just create a YAML file inside that test name directory and then mention which images you want to use or which script you want to use, how much time you want to wait in between them. So, those you can see, actually you can use hollow world as your starting point to play around with this. And finally, you can just add the YAML file name into testname.task file which resides under task directory. So, once you set it up, you can start running the test. So, the next is I will show you what the output results will be. So, the output results will be in the form of screenshots under video. So, because with screenshots around we cannot really figure out what is going on. So, we will have one video for each action as well as the final video. So, the videos will be stored in a directory, results directory with a unique ID and you will have a simple HTML file. If you can just open it, it will show the output in a HTML format as you can see here. So, you can see its first screenshot which is opening the terminal and second probably it might have done the results steps by then. So, by the time we have taken the screenshot, but if you look into the final video or hollowworld.amp45, you should know what exactly happened. So, next we will quickly look into Debian results. Actually, this is from a link I will share in the next slide. As you can see it has the on the first row you can see Debian launch viewer, you can see Debian live image are installed and also it provides you the welcome screen, all those things. And on the second row you can see it sets up the location and partitioning. Then we have the user account details and then we proceed with base system installation. So, everything is done in a cloud environment or a personal laptop or actually this thing is run in a GitLab CI environment. So, this will give you an easier way of setting up OS images testing for OS images. So, finally I will share few links where you can check out the source code as well as other results. You can see there is one Ubuntu ISO image results is available and then you have a Buster ISO which uses the manual partition and you have a Buster ISO with default partition. So, those kind of things are available you can go ahead and look. It is much more easier to add new test cases as you have seen before. So, all we need to do is just put the images into a directory and then create a key value pair about that image, how the action should be going to represent and then finally add a task file. So, that's all I have actually if you have any questions feel free to write to me or ping me on GitLab. I should be able to answer. Thank you very much. See you. Bye.