 As Yurgis said, my name is Rafał Nowicki. I'm one of the superheroes, so which works on STX Next, and I'm also still student of Wrocław University of Technology. I'm really glad to be here. It's my first Europe icon, and it's also first time when I have a speech. So, today we are going to talk about automated tests, but this talk won't be so technical as many I saw here. I'm going to share my experience with a project where we implemented, where we was implementing the automated tests. So, there is agenda. At the beginning, I will give you a background about the project I used to work on, just to keep the context much better. Then, short talk about tests, about automation in web development, and I will shortly show how we do it in Python. Then, we jump to behavior-driven development. I talk about benefits, problems, solutions, and then I'll show you the conclusions. So, a couple months ago, I used to work for a project which was an interface for Assets Management Platform, web interface. So, we had the chance to implement Selenium test for it to test it more efficient. We work in small scrum teams, and I will show you my point of view as a developer. So, let's begin from test automation in web applications. Two things which we need to write automated tests is scenario. Most scenarios are written in Gherkin language, and we also need the programming part, which is Selenium API, and it's what we use it over here. How it's looking at Python. So, we've got an example scenario, and this is the Gherkin syntax. You've got the name of the feature, name of the scenario, and you've got the steps which is separated by keywords, which is given when and then. And then, we make implementation of all of any steps in this scenario. So, for example, when we had the given, and it has been written that I'm on a login page, we have the Python method where we can program the behavior of the web robot, which is Selenium. Here, you can see there is, actually, you can put the Selenium code over here, but to keep it clear, it's much better to make adapters. It will help you to don't duplicate your code in the future. Here we are, behavior-driven development. But I'd like to start about test-driven development. How many of you know or hear about TDD and about BDD? So, generally, to be sure that, we are on the same page, behavior development comes from TDD, but it's mostly focused on functionality and on business values. Yeah. So, a few days ago, I met some guy over here and I told him about the contest of my speech. And to be sure that we know what's the BDD, I asked him to talk about the BDD, I asked him to collapse it and he said business-driven development. And then I realized it could be, it's actually like this. So, about BDD, we've got benefits, but we also had a lot of problems. So, I'm going to show you the benefits problems and then the solution of those problems, which we got. So, improved developer skills. Because it is the way of programming when you have to write the test at the beginning, it's quite a challenge, especially for beginners or for programmers who work on a more complex project or on new part of the project, which never tapped. It's also, the big benefit is that the developer learns about the business values and about the end user's needs. And here we have cooperation between developers, QAs and business people. I think it's really hard to meet a developer who are experienced in both, I mean, he's a great programmer and he understands the business values of the project, of the task, which he do. Here we have end-to-end tests focused on functionality. So, we are going to help our QAs, our testers to run the automated test except on manually boring stuff. And the biggest benefit, I think, in way of you have all app covered by functional tests, you can make completely new app which fits to those business needs and you can create completely new user interface, create a project for different platform and run the test and check if it still covers the main values. During the implementation of the Selenium tests, we had a lot of troubles and to begin from inexperienced people, we have, there was around four teams which was working on implementation automated tests and I really knew all the people from at least one, at least two teams and all of them are good programmer but all of them, any of them have never need to write something with Selenium API. Another one was different environments and it sometimes happens when you write a test and you run it on your computer, it pass and then someone pulls your changes and he's running this test and it fails. We recognize that there are problems with the browser versions, Selenium versions and web driver versions. We didn't have automated validation of our builds so the way of creating the code in one repository was that we get the plus ones for a code from our co-workers on a PR and before merge, someone else had to run this test on his machine, check it if it pass and then give another plus one that the test passes. The teams which duplicate their work, it happened many times when we were working on implementation the test for new features and for current functionalities, we didn't cooperate as well so it was also the problem and there was even one team which was working on a new feature on isolation and it was actually my team. When the idea of the cover, the app with the automated test came, my team was focused on delivering a new big feature and we used to work on our feature branch and we used to do the same with the Selenium tests but it was a bad idea because after a few weeks we recognized that the master on test code base was completely different than we have and it changes on our branch and it is also about the premature architecture because the architecture wasn't so... we didn't have the completed architecture from the beginning, so we had to get some idea how to do it and then we were improving this recursively as we do it in a scrum. Okay, so what was the solutions? So for inexperience stuff, after a few days, actually this solution sometimes happens after a few days but sometimes it has been resolved after a few springs so from the beginning we started to run the workshops and we share our knowledge with the other teams. We created unified environments and it was in two steps I think because one of the things we've made is to run the script that builds our environment with all the dependencies and another step was that we've got the phantom browser on a virtual machine with all things which we need to run the tests. We started to work in transparency as we should do from the beginning. We get one board on Agira where all the tasks about the Selenium code-based has been touched and we can check which part of the code-based our friends touch and the architecture has been improved. We came to this point that we covered all the use cases and we get one standard with clear documentation for it and we also started to support versioning and the conclusions. I give you an example of the problems which we had in our project. In your project, some of them can work but I get and write down on the slide the most important thing for me and one of them is about communication. It fits to many cases because communication is about the most important part of software development process and it's about people. I strongly believe that it's much easier and nice to work together on one solution rather than work in a separation on different solutions for the same problem and then fight for the best solution which will be our standard. Another thing about the Selenium test mostly you have to learn patience to write this test because in general I really appreciate the work of the QAs of the testers which have to be so patient to repeat the same steps over and over again and writing automation test it's like this at the beginning so you really need to be patient people and I think that's it. I'm looking for questions. Do we have any questions? Alright, thanks a lot. Let's give him a round of applause. Okay, thank you.