 Welcome everyone to this session of visual testing and visual regression tracker by Pavel Strunkin. We're glad to have you here today. So without further delay, over to you Pavel. Thanks and hello everyone. And today I'll be speaking about visual testing and how you can do that with the visual regression tracker. So my name is Pavel Strunkin. I love to call myself as the software developer engineer and test and mostly I utilize the Java and the JavaScript in my work. And I am the creator of the VRT tool. Those are my contacts. So feel free to reach out to me and take a note about the latest contact is the telegram chat dedicated to support for this tool. So see you there. And according to our agenda, we have some introduction, then I'm going to present to you how you can set up the service, how you can integrate your existing test with it, and how you will see the results of the visual testing in the admin panel. Of course, I'm going to share the future plans and how you, yes, yes, how you can contribute to that as it's an open source solution. And first, I would like you to imagine the situation that you are a QA, you work in the company, and your company has some mobile application or the web page in the mobile design that you are responsible for testing. And you are testing this in the variety of different screen resolution, and of course variety of different platforms, whether it's Android, iOS, etc. So you are quite busy because there are plenty of them. And maybe you even have some farm of the devices that you are running your test on it. And of course, multiply it by the number of the browser in case you have a mobile application that runs in the browser. So imagine you have lots of work to do, really. But if you think that you as the person can memorize how your application looks like, and from version to version, you can constantly review it and note any difference that is caused by the visual regressions. Not the case, actually, because our brain doesn't work like this. We memorize only general things. And unless you put the old version and the new version of your application side by side, you may really notice only then that there are differences, and you cannot control them. You may find lots of interesting examples of the visual regressions. For example, these images were found really within five minutes for the big application of the Twitter. Some of the regressions visual visual regressions may cause your user even stop using the tool because some of their features may not be accessible to the user. But this, in fact, you cannot control with the tools that are already provided to you. For example, Appium, it doesn't provide you any solution to this problem. And if you try and you already have the tests that are checking the functional side of your application, it's not the case with the visual representation of it. And you may blame the tool itself because some of the issues may still slap into production, but it's not the reason to blame them. You just need the different set of tools. And lucky we, there are specific tools dedicated for that, such called as the visual regression testing tool. And the basic concept of it is that you have the baseline, the image, how your application looks, and you already asserted and decided that this is the way how it should look like. And every time you do the change, you make another screenshot of the newest version, and the image comparison algorithm helps you to find the difference highlighting the pixels. So for you as an operator, you can decide whether this change is the new feature that is introduced in the new version or it's some unneeded regressions. Mainly you can use it for checking the design, how it looks like in different combination of screen resolutions for the tablet for the mobile for different mobile for desktop application. So such called as a responsive design, and you may be controlling that. Also, you may be interested to control how your application is rendered in different platforms like iOS or Android, etc. Also, with the browsers is the same. It may look different in different browsers. And maybe if your application is internalized, you can have some of the configuration file with translation. So after you made a change in there, you can run your test and spot the difference without need to check them manually. And first of all, you will be searching for the visual regression if the change is causing any difference any glitches, such called as the visual regressions, but what about really the functional things. Maybe some vendors of the paid solution for visual testing may say that the visual testing is something that's going to replace the existing test. I am more conservative here, actually, and I would say that you should mainly respect the testing pyramid. For sure you know what is that. And the visual test should be on the very top of that pyramid. But depending on your project, if the functionality is something that you can assert visually. Yes, you may use the visual testing. I saw even some examples of the people that are using visual testing for the API testing. But it's up to you to decide. But still, it's possible. To give you all the information that I had before I started my journey in the visual testing, feel free to open this web page. This is the created list of visual testing tools that you may find on the Internet. There are lots of information about the tools itself with the documentation, with video. So that's the good point to start. But when I started using that, and some of the tools were not working, were outdated, or dedicated to specific automation tool or a language. And as I work in different companies in different projects, I didn't want to tight my project to specific automation tool. So I decided to make the solution that I'm going to be using by myself. And that is not specifically dedicated to the automation tool. So that's how the visual regression tracker started. It was the beginning of the pandemic, of the COVID. So I had lots of free time and I made a good use of it. So feel free to go to that link. You will find the source code, the whole project. And feel free to hit the like button if you like this tool on the GitHub. To give you the quick overview of the application, it's basically the front end and back end application that is running inside of the Docker container. For you is provide the admin panel as the operator for the test they can integrate with the API, through the API, through the SDK, or through the agents. Basically, those are the libraries to store to send the images into the server that are stored inside the container and in the database. The quick setup is as easy as it looks here, you need the Docker installed everything is wrapped up into the Docker compose file. We have the installation script that gonna go through that gonna make all the things that are needed for it to run. And it will start the service locally for you just to try it. But if you want to see the example how I run the tool in the remote like cloud providers. So you can check out this video how I do it for digital ocean, for example, it's already there. So feel free to check this out. After you do all of this preparation, and the console will tell you that there is already created the default project for you and default user for you to already start integrating your tests. The integration of the test may be falling to separate into different cases. For example, you're using playwright Cypress, code suggest or web driver IO, we have dedicated libraries to that are providing more native integration way for them. So if it's not the case, don't worry, you can still utilize the row programming language SDK, like a JavaScript for Java for Python, even for the dotnet. If it's not the case for you, you, you, you work with the different languages, you can still use the service as it provides the rest API and you would need just to write developers over it to send the data to the service. You can use it with any languages. In fact, and for all of these libraries, we have the set of examples. So feel free. After you set up the server server locally, feel free to clone the repository with the example and just try it to make sure that it works for you for to feel how it really, how it really works. After you set up the service, after you made the, the installed the integration library, you can already start integrating your test. For this, you go to the page with all the configuration needed for you with the URL API key, and you can copy this to further use in your test. I'm going to show you some examples that are written in Java. This is the real example you may find it into in the GitHub for Java examples. You would need to create the config object providing the URL where the service is located in our case it's a local host but for sure for you it's going to be maybe a different URL API key to authorize yourself the project for service to know where to store the image. And of course the branch, depending to which the changes are going to be stored as we are just starting the main branch for us is the master so this is going to be our first branch just to make all the screenshots except the baseline, and then we're going to be changing this branch related to the branch we are currently using in our version control system enables of the sort option will provide us the capability of not failing the test and made all of our tests run through. Then we accept all the baseline and then we can switch off this option just to make our test fail in case there is any difference. Now you are making this conflict, then you can easily start the service by calling the VRT start method. So this is the same way how you do with the driver. So just put it up. Just put this code after you do with the driver and you are ready to utilize the method to send the screenshot and inside of your test. This is how it's going to look like. So you do some preparation you navigate it to the needed activity when where you want to make the assertion. You make the screenshot. There's the same way how you do usually and also you can send the screenshot, like is shown right now. So we are calling VRT track method, providing the name of the image that we want to store in our case we want to store the homepage how our homepage looks like. So we are passing this string there to name our image, we are passing the screenshot itself. The rest is the optional configuration that will help the service to store separate separate images for the combination of different things. For example, we are running our test for iOS device with the API version 14 and 14.5 for the iPhone for the browser in case we want the browser for the viewport. We can make these parameterized things for the service to know whether the image is should be stored as the separate baseline or compare to the existing one. So this is the help information to save the same copy of the homepage for different devices or different resolutions. The last part here is the ignore areas. This is something that is useful with the mobile testing when you want to ignore some parts of the image. For example, the header that where we have, for example, the timer when we have the clocks. So we can ignore the full region of the header and we can make it of course parameterized depending on the device of viewport. So this is just an example how you can do that. After the tests are executed, you can navigate to the admin, you will see all your bills or your test runs with all the tags that you are providing with the status of those tests. In case there is a difference, right now you can see how this difference will be showcased to you. So the pixels are highlighted and it's up to you whether this difference is expected. So you approve the image or it's the regression that you need to fix. So you fix the issue and run your test again. So here we have some more functionality that you can utilize. For example, you can manually draw the rectangle to ignore in case this is not needed. For example, we have the animation that we want to ignore. So we can easily draw this rectangle and also we can copy in case this rectangle wants to be reusable to other images. We can copy these two other images. So we have some kind of baseline history when you can track all the images that are taken for this set of the tags. And of course we can add some comments here. The service also provides the functionality of storing images related to the branches corresponding to your version control system. Just imagine that you are testing the new feature and your feature is made in the separate branch. When you run the test, you would need to pass the name of this branch to make to let the service know that this is a different branch is not the main one. So the service will store the separate baseline and when your code is merged finally to the master branch. The service will try to find the respective image across the feature branches, the such called functionality as auto proof feature. So it will try to make the test pass according to the previous history. So you can, you can already use it as the service will make it automatically for you, but you can still switch off this feature. It can be done in the configuration of your project and make the manual merge of your branches. But the service provides you the capability of working and having the baselines for different branches. I would like to also share some tips about how to make the visual testing really works for you. So first you may struggle with some dynamic parts, maybe some animation. These things would need, you would need to take control of that. For example, you can freeze the animation or you can ignore the parts of the, of the screen. Also, in case you have the data that comes from the server, you need to have a control over it. Either you make the preparation in your database or you are intercepting the request. The visual test would need for you to have the same data displayed on the screen. Otherwise, the images will be different. So you will have the flaky test and we don't need this really. So you would need to mock the data for sure. And just a good example or how you make the screenshots, you can make it with the retry mechanism. The service also supports sending the same image over and over again, unless the only the latest image is saved. You can find the example how you can you, how you can do that in the Java, but in fact is the same way how the expected conditions are working so you just do this over and over again. And also, I would like to share some future plans how I'll be working on it. So you may notice that I'm not the best designer or the front end developer so we will work of course on the UI UX improvements. So we are working on the performance issues. Of course, when I made the service, I didn't expect a service to have like 1000 of an images or one image more than 20 megabytes. So we will need to make some adjustment for it that we're going to be working for sure. The latest version introduced some permission mechanism that now you can set the roles to the user in order to allow or restrict them from deleting or managing the baseline. So this is already there, but for sure we need to work even more on this. So related to config to comparison algorithm. Currently you can use three different algorithms like pixel match looks the same or odd if those are the libraries to compare the images, but I really personally things that we can do better and we can think of some libraries that are part of the image of the pixel by pixel comparison, we can do some. We can find or maybe even develop some libraries that may notice not only the pixel difference but also the structure differences whether some part of an image shifted left right or etc. And also, I would like to work towards the CI integration. The CI providers like github allows you to make some plugins and make the visual test as the separate step. So I would like to work on it as well. And of course, it's your suggestion are welcome. This is an open source project so feel free to contribute to this. And then how you can contribute are really different. You can use it, you can share, spread the word about this. You can request feature through the github issues, suggest improvements, and of course feel the feedback form, we have some small feedback that you can feel to give us the information that you would like to see. I encourage you to became a contributor. The most of the integration libraries that are done are done by external contributors so feel free to write some code. And if you would like to donate, you can do this as well through that link. And the last one I would like to thanks to all the contributors that are worked already and made a contribution. So thanks to all of those guys and I really appreciate your work. And I would like to see more people here. So that was actually the all information for me. Many thanks for having me here. Join the telegram and subscribe in Twitter. Thanks. Wonderful. Right on time, Pavel. Thank you so much Pavel for sharing your experiences with today.