 and this is not in the program. Okay, so I think that we can start. So, hi everyone. We are very happy to be here. As you understood, we are like a backup, but this is a nice chance for us. We want to share our experience with you about breaking through RScale Drupal projects with Behead. We use these two a lot in our experience and yeah, here we will share a couple of our cases and a lot of our experience with it. We'll try to do that. So, first start with some introduction. Here is me. I am Burjidar Boshnakov. I am from Bulgaria. I'm working for FIDAL agency. Currently, I am a real manager in Gabrivo. This is a whole production unit and also head of QA department. My responsibilities was to guide all the QAs through the whole projects, to plan the resources and to lead almost every automation activities. I also have George with me. He will introduce himself. Hi guys. Can you hear me well? Okay, nice. So, my name is George Tarkov and I'm also from Bulgaria. Working in FFW as QA lead currently. Focused on automations. And I have more than three years experience already in the company and I'm responsible for most of the automation frameworks that are developed in FFW Bulgaria and below are the contacts where we can finance. Yep. So, yeah. Actually, George took my responsibilities over the automation activities and improving our frameworks and so on. So, yeah. He'll talk about leader to share his experience because he was the main QA lead actually on our biggest project. So, but first of all, I want to show you our agenda to be informed what we are going to speak about. I will just start with some introduction about behavior during development. What is behavior during development? What is Behat, Girk and Ming? After that, I will explain you how we execute our tests because this is a very important part. I will speak after this about the Drupal extension and actually this is the main reason we choose Behat because it has this very nice Drupal extension which helps us a lot. And of course, we are on DrupalCon and this is important part. After that, we'll share, as I said, some of our experience about some common issues that we have and if you start working with it, what maybe, what problems you may face in your way to deliver a good automation coverage, how to solve them and the real-life examples from our project, what we have as a problems and how we fix them. So, but first of all, I just want to start with some, another topic which is, I want to talk about intelligence. Intelligence, why intelligence? Because most of the people working in our industry are smart, maybe all of them are smart, but intelligence is a liability and why is a liability? Because maybe if you are that smart and if you think that you can work without a proper process, this is a problem. Smart people can make progress. They have too many stuff in their head, they just see it's right code and they do some things. Maybe if it's a small project or not that small, but not a big one, they can make a good progress and this is a good thing. But without a process, we are not able to make a good project, big project, projects with large scope and this is not a good thing. So, from what I saw is that many companies think that they have good process, think that they are doing the things in the right way, but I faced many problems as a quality assurance engineer, what is my job actually to find problems and to think about how to fix them and I saw that the process is not implemented in the right way and many companies are working because they have smart developers, they have smart engineers and they are delivering their projects because they have the capacity to do it, but with the right process, I think they can improve their work much, much more. So, professionals, first design, plan and prepare. This is very important and I think this should be always part of our work and here from the QA perspective, I need to share this with you as well because the QA engineers also need to design, prepare first. This is very important and then do the work and this actually produces better results and makes it even faster and this is not only for the developers, this is for the whole team and this is very important for us and when we are talking about the process, this actually makes a difference between the software engineering and just programming, just coding, which is for me very important and I need to focus on this one. So, when we are talking about the process and why I was talking about this and why it's important, here are steps in the behavior during development. Behavior and during development is a methodology. There are many theories, what is it? Some people, many people actually accept it in different ways, but it's actually, it could be said like this. Behavioral development is about implementing a complication by describing its behavior from perspective of the stakeholders. This is a quote I took from Dan Nord, which this person is meant to be one of the inventors, one of the founders of this methodology. But as I said, there are many people, there are many thinking about the behavior during development and there are many other quotes that I want to share with you. Maybe a better one and easier for me is this one. Behavior during development is when you use examples in conversations to illustrate behavior. This one for me is much more simpler and actually more true. So this is about the process. This is how we talk with our clients, how we want to build our project and what we do in order to achieve a better product. And the last one that I like the most is that the behavior during development is about delivering software that matters because maybe you saw in your past, a lot of graphs that show that actually in our industry, very often we deliver more and more software that is not used at all or it's used not that often. Maybe like 10 or 20% of our systems at our sites are used very often and they are really helpful for the clients and they really improve their business, which is the most important thing. But most of the features, they don't use that often or they don't use at all, which is a huge problem. And in order to follow this process, in order to help in this process as a Q engineers, what we do in order to verify application behavior as software developers, Q engineer, no matter what, I need tests. We prefer automation tests of course, because manual testing for huge projects, large scale projects, big time frame with big team, of course manual testing is not enough, never enough actually. So what we do, first of all, don't go into the coding, don't start working on our automation tests, don't start preparing a lot of lines of code, which are aiming to capture every book to report it to the developers and to say, okay, this is not working, you need to fix it. We found the book, we are great, but this is not the right approach and we don't want to do this. We'll start talking. And we'll start talking not with our team because we think that we got a good communication with our team already established. We start talking with the business, we start talking with the clients and how we start talking with them using the language, business can understand. Because I saw very often that the business and the development are not talking the same language. Actually, developer is thinking how they can implement something, how they can realize a functionality with their system, with Drupal for example, and how they can make their work easier if they say, okay, this could not happen in this way, you should change it. But the client wants another thing, the client wants his business to be successful. The client comes with an idea, an idea which should change his business, should improve his business and somehow bring value to all that they're working. And this misunderstanding in the communication is not a small problem and we should focus on this one. And here comes the QA part where we should start talking to the business, we should start gathering business requirements and help the client and the business to speak more easier with the developers and the team that we are working with. How we do this? We do this with one language called Gherkin. Gherkin is business-readable language, domain specific, creates special behavior description, gives you ability to remove the logic details from the behavior test. So what we need here, we need a language that describes what have to be done, but without that coding specific, that details that could make our wife harder. So Gherkin has a specific syntaxes, as I said, human-readable business language, which is really nice, which the client sometimes partially accepts, but after we show what are the benefits, I think that every hour client accepted that language and our test and they are using them, they are learning from them and they are extending them even, which is really nice in future. And so here I gave you one very, very simple example, which I really like, I saw in another presentation, describing actually the Gherkin syntaxes. And it's really that simple, as you can see, like we have one feature, one functionality, which is like banana calculator. And we have Bob the banana merchant. And as Bob the banana merchant, I want a calculator, they cannot ban us, so that I know how many bananas I currently have. And this, as you may see, is like a user story, user story in the Java methodology. And it is described in the test. Actually, we took the description of the user story and we move it to the test. And after that, we just create scenarios to test, is it working or not? And like this, adding bananas to increase amount I have. For example, we have, given I have three bananas, when I have five bananas, then I should have eight bananas. And actually it is simple as that. If you have it in the Drupal world, two, it is simple as that. I want to buy some product in our web store as a customer, I walk into the system and I need to be able to add product to the basket. And you can write it in this way, you can write it in this business readable language and it will work because behind this, stands actually a code which is helping us to implement it. Code based on one framework that we are working on and we are working with. This is the BeHat and this is where BeHat and Win come in. Actually, the tools that we are going to present today. To you, we are using them and I think that they helped us a lot in this mission to actually establish a better process, to be part of the whole project and to improve. I can say every part of it because the communication is everything. And when the communication is good and the process is good, everything is good. So this is where BeHat and Win come in. What is BeHat? BeHat is an open source framework, based on PHP, of course. And BeHat helps us to automate and to make these tests as you saw on the Gherkin syntax to be like living. They are executable, they are working with this language and they are actually doing what is described in the text. So another thing is Mink, another thing is Mink because Mink is very important because Mink is providing us the way to control the browser because we know that actually our tests, if you want to be automated, we want to make them from the client perspective, from the customer perspective, what the clients are going to do or what the visitors are going to do. And this is the best way to test the system. I know that there is another tests, they are unit tests, integration tests, they are really nice and they are helpful, they are helpful for our developers, first of all, but they are not visible for the clients, they are not helping us to see is the user experience good, is the loading time good, for example, or so on. How many steps are needed in order to buy a product, for example, these unit tests and integration tests don't show this to us. And here we need one framework, one system, one tool, which can give us the ability to test the behavior of the system. And Mink is the one that is controlling our browser, allowing us to traverse the pages, manipulate pages, elements, or interact with them. This is what Mink gives us actually. And here we come on the execution part, how we execute our tests, because I said that we are using the Behat framework, which is PHP-based, and of course, we choose it because Drupal is PHP-based, Drupal is Symphony already, but okay, our developers helped us at the beginning because I know that in many companies, the QAs are not that good as developers sometimes, but I think that this is the future and every QA should be at least a half developer. So at the beginning, they helped us, which is really useful for us, and we managed to actually really implement this. So about the execution, how we execute them, they are like say two different ways of execution. The first one is headless browser emulators, and the second one is browser controllers, and what is the difference? The first headless browser emulator, and when we want to send HTTP request and to parse the response of it, and to work with this response. But as you can imagine, this is the way we can test any JavaScript or Ajax calls, we can work with the system in full capacity, like say it like this. So for short test that we want to test something which is not including JavaScript, this is good. We are using it, of course, because it's a lot faster, and it's not generating career browser, it is just sending HTTP requests and parse the response. Read it and yeah, work with it. And the other one is much, much slow, but on the other hand, we have a real browser simulation. We need an installed browser, of course, to run it, which is a little bit hard when we want to execute some test on an environment which is not having browser there, but somehow we manage to convince the clients and the developers to have this also set up in the projects and to work with the test also and to make them use them to not only the QAs, on every deploy, on every change they make, they are using our tests to verify they didn't break anything older. In the previous prints, for example, like in the last two months, because some projects are not for one month, as you know, and especially in our company, we don't have such. So the other thing, as I said, allows us to test the site as it is with all the JavaScript, all the Ajax things, and actually allows us to be like a visitor on the site or administrator and to click on every link or every button and to see what happens and to see how much time do we need and to see how the interactions are happening in real life on the wife side. So what do we use to execute these tests? The first one is good, only for pure HTTP requests against an application which pass the response that I set and returns the content and work with it. This driver actually is not supporting browsers, not supporting JavaScript, but it's a lot faster, as I said. On the other hand, what we are using, we are using Selenium WebDriver, which is actually controlling the browser, actually the sessions, cookies, headers management, HTTP authentication, traverse the page, selectors, and manipulate the page. Actually, the Selenium WebDriver supports a whole browser, which is and allows us to iterate with all elements we see. And another thing that we are using, which is really nice and I think very useful because sometimes the servers that we have and the tests that we have are on the servers which don't have graphical interface and we are not able to run exactly like a wife browser and we are not able to see it or anyway, something like this, some problem like this one. So we are using Phantom.js. Phantom.js is a very interesting technology that is growing, I think, and it is very useful for us. Phantom.js is a headless webkit scriptable with a JavaScript API. It has a fast and native support for various web standards and also allows us to work with the DOM elements with the CSS electors, JavaScript, and no other libraries. And actually what Phantom.js do is to create us a headless browser in water. Actually, we don't have real browser running but it works like we have it and actually it's a lot faster and we still achieve what we want to achieve. And most of the companies they are using the Selenium WebDriver, from my experience, I also used it a lot of years before I found this one and before I started using it and now it is working better and better. Just one note here for Selenium WebDriver, if we are using the Chrome driver from the latest versions of Chrome, now the Chrome allows also this headless execution which is really nice. But yeah, Phantom.js is the one that I recommend here. So on the interesting part and actually why we choose Behead because it has a really nice integration and a really nice extension, the Drupal extension. Of course we are all working with Drupal and if we have something that could help us in our work and help us to not start from the beginning what we are usually do if we want to work on some automation package. We choose this one because the Drupal extension is very strong and actually what Drupal extension gives us, the Drupal extension gives us a lot of things. The Drupal extension gives us work with George, work with the Drupal API, work with regions, node types, user roles, taxonomies and a lot of elements and a lot of functionality specifically related to Drupal. They are already written. This is like a library. We just extend the Behead framework with this Drupal extension. We got already written functions. What Drupal means to clear cache for example, what means to create a node from article content type, what means to create a user, what means to be authenticated or not. And stuff like this, I will show you some examples after this, but actually Drupal extension gives us a lot. Gives us a lot if you want in order to work with Behead and with Drupal of course. So here are some examples. We can easily, with that extension, we can easily define some regions and to create tests like this. You saw the banana merchant but this is a, for example, real cases when, for example, I press a button in the header region and it's as simple as that. Just mark these header regions, other CSS selector in the configuration and it's working. And after I press the button and I fill some fields, I can follow links, I can see error messages and the Drupal extension gives us that that the system understand now what is error message in Drupal. What is, for example, region in Drupal. And this is really, really useful. Also, it works for nodes. As I mentioned, you can say given a content type and I want to create the following nodes with their ID, with the IDs of their fields. For example, title, body or whatever you want. And in these easy steps, we can actually generate content on our side. We all know that it's important if we want to use our tests in their big ones, we need to clear everything we've created at the beginning. This is important to mention because we aim to not leave any dummy content after us, which is, yeah, which could be a problem, just like an advice. And of course, users, rows and taxonomies. Again, the Drupal extension gives the behead ability to understand what are rows in Drupal, what are taxonomies, and how to create them easily. So, yeah, these are the steps. And from here, after my introduction, we can move to the more interesting part of the presentation, actually. What are our real examples and how we actually worked with, we had what problems we faced because I know that there are a lot of automation tools. I know that there are a lot of frameworks and you may be hurt for all of them. But when we get into the action, it's really, really hard to automate a huge project with only this one. With only behead, with only Drupal extension, with MIG. They give us a lot, but when we talk in details, when we talk in projects, this is not enough. And here, my colleague George will show you some of our experience, some of our projects and what we did. And yeah, this is from me. So, yeah, it's George's turn. Okay, so after this really nice introduction to the basics and how we are using and implementing BeHat in our company, I would like to continue with some real case scenarios, how we did it in our projects, what issues we faced, how we managed to fix them, stuff like that. So, of course, we all have problems and we all face them. First of all, I would like to ask you, do we have Q engineers in the room, actually? Yeah? Okay, nice. And you write automation test, I guess? Yeah, perfect. So, you're familiar with our pain. First of all, I would like to mention you guys, what common problems and issues we faced during our daily work. And first and the one that irritates most is the badly written HTML and markup at all. It's due to the fact that a lot of developers, let's say sometimes miss CSS electors, let's say they don't put IDs on inputs or something like that. Other thing we have is that the tests are being executed in a non-developed environment. It's a perfect case scenario to have a dedicated environment where you can run your tests or have a site which is built for each build and you run the tests on it. And due to the fact that we have continuous development on the environment, we have a lot of things changing in the functionalities which can cause us test failure. And starting from then, debugging a test failure due to the newly introduced code is a really hard thing to do. And most of the time we have issues with that. Other thing is performance. When you have a large scale project as we mainly do in our company, you start creating automation framework. You just start with a couple of features. Then you add more and add more and add more. And eventually in time you get a build which is running for more than two hours only because of the tests. And they are really huge and that's actually stopping the whole development process because code can't be deployed to development environment, let's say, or staging or production or whatever. So here that's another issue. And we have dealing with third parties. That's the same thing we faced a lot in our projects and it's really irritating to try to automate something that you don't have control of. Because in the case of missing IDs or bad markup, you just can't say to the developer, hey, I need this ID here, so the process is really faster. But when you have a third party which you don't have control on, you just can't do nothing. And of course, a lot more issues that can bring us on a daily basis. But from the previous slide, we weren't a lot of lessons. Facing all these issues, we of course try to solve them because you can't proceed with your work if you don't solve all the issues listed before. And for me and for my team, I think the most important thing is to keep really good communication with your development team. Like I said already, you can go to them and say, hey, I have a problem here, can you help me? Or like Buzhidar said that they can help you with setup for environments, for BeHat overall and stuff like that. And of course, they can make really small changes to the functionalities, let's say. If you want to, let's say, register on a website which have a one-time login link, that's sent through email. And if you want to do that, you need to go to an email client, catch the link, go to the website with that link, blah, blah, blah. But the fastest thing is a developer can expose that link on a webpage which is specifically, let's say, developed for automations, which was the case in one of our projects I will show later. And yeah, keeping the connection and being really close to the development I think is the most important part, I think. The perfect thing to have is a dedicated environment for tests. That happened a couple of times in our company. We are trying to do it like a must, but so far that's not the case. But we have it, and it's a really nice thing. Because when you say you do a deploy from two development environments, firstly you do a deploy to the testing environment. You run all your tests there. If everything passed, everything is green, we can proceed and deploy this code to the development environment. Saying that we will have a really strong, bug-free development environment, which can be, let's say, deployed on stage and production each day. And the last thing that I mentioned is that we need to separate the suits. I mean, suits, those are the big packs of automation tests that are specific for different functionality. And what we did is we separate the tests based on how important they are. For instance, we have one small package which is based on the really business-critical functionalities, and we run that on each build. And running that on each build allows us to verify that, for instance, if you are selling some products, you still can buy a product. This product foe is not broken. Other thing that we do is nightly builds. Nightly builds and nightly automation runs, which they cover a lot, a lot more of the functionalities of the website. And, yeah, this thing can help you, firstly, giving you a better, a stronger environment and also giving you faster builds. Because all the times you are pushed, let's say, from project manager or from clients, I want to see this part of the code and production, I want to see it working. But if you have like a two-hours suit of automation tests running, you can deliver that fast. And here, I would like to present you some real case scenarios on projects that we work on. And what actually what we have next is a couple of the hardest things that we face during our work or how the business likes to cause them simple projects. First of all, we have the wish. It's a retail cosmetic company. It's a really huge platform, which is based on nine different Drupal instances and Symphony One and mobile applications for Android and iOS. All of them working together, all of them sharing data through APIs and services. Meaning that you have, for a start, a really, really huge platform to build on. And we managed to roll out this platform for 17 different countries on 15 different languages. So you can imagine how you need to check the error message which is I wasn't able to create the note on 15 different languages. That's really hard thing to do. And couple of the Drupal instances that I mentioned above are only backend, meaning that there's no front end. You need to iterate only with the Drupal administration, which I will show how we actually face these challenges and how we actually solve them. So here, we have the challenges listed and overall, as I already said, planning the whole automation framework on this huge platform by itself is a really hard thing to do and it's really challenging. And of course, we achieved that by spending a lot of time thinking about the future implementation and the future functionalities that are going to be added. Because in this case, I think one small new feature can break your automation architecture completely. Because introducing something in the middle, let's say, for that you're buying a soap, it's really different to do. And what we did here is actually built one architecture and we change it due to iterations, let's say during the sprints or during a couple of months because it was needed. It's not like one thing and it's changing constantly. And of course, managing all that websites and their profiles because one thing Boudjidar didn't mention is that you can build a different profiles for each website. Let's say you have three different websites and you can pre-define their URLs, their basic authentication. You can pre-define, let's say, rule taxes and you can use that easily in Big Head. Say something like I want to be logged in and that will walk you in in a specific website. So the system to know which specific website you need, you need profiles. And to have profile per environment, per site, and per country, it was really hard thing to do. And also you have per profile. So we have 17, we have three environments, 17 countries and nine profiles. It's really worth scaling. And we actually managed to do it. How we managed to do it? We introduced a chain of YML files. That's where the Big Head configuration is stored. We have separated, as I said, per country, per environment and per profile. And we added a lot more attributes to the profiles which can help us test simultaneously both the Drupal website and the mobile applications. For instance, we store things like tokens so we can call some requests in the mobile API and we already have a generated token so we can store that in the profile and easily access it after that and whenever it's needed. Our thing is that most of the profiles were with backend. Here we develop a specific context which we are going, it's still in development but we are going to introduce soon to the Big Head community and the community overall. It's a specific one working only with Drupal administration. It makes it easy to navigate through Drupal menus and also give you ability to do other stuff really, really Drupal specific. It's built on the Drupal extension. We get some ideas from it and try to improve it and to see what's in fitting our cases. And we use it here in the wash. And the last thing, oh no, it's not the last thing. The next one is creating the test that works simultaneously with web and mobile. The interesting part here is that we should have like let's say the same products simultaneously on websites and mobile applications and if you want, you can buy it from the website, you can buy it from the mobile application and the false should be absolutely the same and the communication between the website and the mobile application should work constantly. For instance, you're out indicating in the mobile application but you need to have a Drupal user to do it. So there's a talking between the website and the application. And for that, meaning there's a lot of custom work that we did. So we can crawl the application, we can crawl what's the data coming through the APIs, capture that and after that compare it, let's say to Drupal data and compare if the user IDs are the same, compare that the basket, it's not empty and stuff like that. And we had a huge migration because they get a website which was already built on Drupal. It was Drupal 7 to Drupal 7 migration but it was like more than 15,000 nodes which were from a couple of different content types and the good thing that we faced here is that while we were doing the Drupal 7 new, the new Drupal 7 website, we had the old one still running and we have a dedicated server for it. So we were able to easily compare old data to newly migrated data. And we built automation framework for the migration which was like going to one website, crawl all the information that is located in the node and after that compare it to the newly migrated one in our new system that we built. Okay, so other project that we worked on is for a world-reading agricultural company. Here we have the almost, let's say the same scenario because we have a multi-site setup with a lot of countries and a lot of languages. And what we did here for the lot of languages, a colleague of mine introduced us to a newly developed extension which is called the multilingual extension. You can follow the link. That's easily allows us to have different languages and strings defined on different languages. And for instance, you can say something like, I would like to verify this error on all languages and that will compare the string on English. After that, switch the website to Dutch. Change it to Bulgarian, look it in Bulgarian, stuff like that. And or you can say something specific like, I would like to check this error message in English and that will pick or any other language and that will pick a specific language out of the YAML files that are configured and compare the strings and give you the results which give us a lot more time to do other stuff. I mean, this feature allows us to have concentrated on other things in the project and fixed a lot of our issues that we had so far. Other thing that I mentioned earlier is the one-time login links. It was an issue before, but we have developed a feature in the Drupal meaning of feature which can be easily like turn on and turn off. And for instances, our automation tests were doing the stuff that they go first on the website, enable that feature and do the rest of the testing after it. And after the content is cleared, after the users are deleted, which we're using, so we don't leave any dummy content on the website, we turn off the feature. And that's leaving the environment as it was before. And the last thing that I want to mention here is a really interesting CSV imports that we're doing. We are actually importing nodes through CSVs. But the unique thing here was that UADs for each nodes needs to be like random strings. And actually we didn't have that in the beginning. So each time we run any automation tests, we receive the CSV from the clients which was with not generated UADs. So we generated them automatically and importing them like a new column in the CSV. And after that we save it and upload it in our system which was like we faced a couple of tricky things during that process. And of course, like we tried to do that so you can have like really independent tests. So you can say each time you can run with no matter what CSV, you don't need predefined data in it, it can be generated automatically and randomly. The other company and the other problems that we faced was for a telecommunication company. And first thing we have here is a two-factor authentication. Two-factor authentication was a really hard thing to manage. And imagine having a lot of automation falls that will visit third party websites that you don't have control of. And the two-factor authentication is based on a third party. And this third party can be changed on a daily basis, a lot of content is added to it or something different which makes your work like really hard, let's see. Other thing is that we have JSON files but the tricky part here is that the JSON files were encrypted and they were on remote servers which we don't have access to. And here, actually how we saw that is something that I mentioned earlier, keeping really good communication with the development team. So we went to our development team, say, hey, we are not able to manage that by ourselves, can you help us somehow? And again, we introduced that feature, in Drupal feature, automation feature. When this one is turned on and you visit an old which is supposed to receive this encrypted JSON file and store it there, we have that exposed in the back end. So there's on note edit, there's a different tab on the top that says, let's say automation. And on this tab you can receive the JSON file and after that start growing the website and comparing JSON data with the website data. And due to working a lot with JSON, we built a couple of, let's say more than a couple of steps that are doing comprehension between this data. And we built an extension which is allowing us to have different parts of code introduced to the system during currents, that's PHP trades. And we use the trades to have different parts of code like plugged in during the execution of the tests. And here, Burjadar would like to say a few more words. So yeah, and yeah, after all these examples, if you didn't understand, all this happened with Behead because, yeah, Gurgi didn't mention it, but all of these problems we managed to fix with Behead. And at the beginning when we choose Behead, of course it was not that easy. We didn't have all these things. When we receive a huge project, as he said, with many environments, with many different countries, we were not able, we were not capable to do this with Behead, but we extended Behead, we contributed as much as we could. Now we are continuing contributing on it and of course Behead is open source, PHP based. It's free, which is very important, one of the reasons why, it's free. We're continuing it and we think it's very powerful too. These are the main reasons actually we saw. And after all these experience we got with it, after all these completed successful projects with the huge packages that I'll repeat again with our clients are using as, some time as actually manuals and documentations to educate their editors how the site is working. Actually they're using these steps to, for example, if they forget how one of their functionalities is working because we have such cases. I don't, I'm not sure did you have such case, but we have cases when our clients forget how some of their functionalities are working and they're asking us from backend perspective how they could, for example, build that book or build that view. And they're using also the test as a documentation, as a education materials and they're extending them, they're asking us for our trainings, how they can extend their tests in future if they continue the development or if they want to cover more and more. And yeah, so this is happening with Behead and this is the reason why we made this presentation, why we're working with it. And of course, everything that Terkan have mentioned could be shown to you and to the community, it's all there in internet or you can contact us. So if you're free, if you want to try it or if you have any problems, we are here to help. So yeah, this is the reason why, this is the answer to the question why, yeah. Okay, yeah, I'll answer this one. So we have both scenarios actually. We run tests on separate environments which are dedicated only for tests and run them against a development environment, staging environment and production. But what we have the case currently is that we have, as you said, a Docker container which is built with Jenkins and tests are run on this Docker container and the environment there. And if, as I said, everything is green, we deploy that to a development server. The best case scenario is that we have like a sanitized database that it's from production. So we have some real data but it's sanitized and we try to use that. Or in other cases, the Drupal extension can easily provide you some random strings and fill you a couple of nodes which you can use for the functionalities. And from my perspective, the best way is to create it by the BCHAT tests. At the beginning, you have like a preconditions feature which is actually creating the content that you need in your automation package because the way of creation is it is simple but many times we face problem with the most simple functionality. Sometimes the client reports that they are not able to save and to create an article. For example, which is a very basic and straightforward thing but I think that the best way is to have a preconditions which is generating this content from the BCHAT steps, from tests, from tests. And after that, of course, as Tarkov said, also to delete the content because we should not leave any dummy content on the environment. If this answered your questions. Okay, so yeah, join us for the contribution sprints at Friday and of course thank you. And if you have any questions, we are here. So thank you for your time. I hope you enjoyed our session. And if anyone has any questions, okay. So one problem that we face in our company is that the person writing the tests is constantly frustrated because one of the developers changed the function. Which is good because the client requested it but the problem is that the development team is about eight people and then the person writing the tests has to go to every single of them if they can't figure out themselves who it was. So you mentioned good communication is key but so far we haven't managed to get a workflow that really helps the developers tell the test engineer to this is now changed and yeah, because the test engineer sometimes not in the office and no. So you can imagine this frustration from my point of view has to go away. So true, yeah, thank you for the question. It's really, really a life example. This is happening and as we said, the key for this to be successful is the communication but not only between the developers and the QAs. As I started from the beginning we should talk to the business. Business should understand how much it costs to change something when we already started or we already developed it. When they are thinking about the change request or when they are thinking about what they need to improve which will change a lot of functionalities that they should know that if you want to make it we want to spend not only developer hours but we should spend a lot of Q hours and they should be aware of the resources that they have if you say one developer, seven developers and one Q engineer which is a big problem many times we got it also and I think that if the client is aware how much it will cost and what will be the result of this because if you change it the whole automation package is not working, the QA should rework it. Yeah, of course, all these they could be more careful because they are not always that careful and they always want to change something and this is of course acceptable. We can't say to the client don't change this or don't change anything. This won't happen in the real life of course but if they know how important is to define the descriptions at the beginning and to the user stories better at the beginning they will like this will be reduced the times that you change your tests will be reduced drastically and also what we are doing actually we are at the beginning of the project one of our QAs which is more like business analyst instead of automation engineer sitting close to the client and help them define the user stories and accept as criterias and this is very important this is something that is missed very often on the discovery some of the early project phases we need that person we need someone who is technical enough to know how it's going to be implemented but to be business oriented to help them actually realize what they really want because with the experience maybe you already done a lot of project similar to this one you can give ideas and you can say okay we had project like this and for this project in future we got these problems and the client wanted this to be changed so maybe at the beginning think about this yeah let's make it like this so we will not spend that much time in future and you won't pay for change request that much in future because they care for their business and for their budget and for their scope of course and if we care about their budget scope and business they'll be happy to work with us and they'll listen to us and yeah this is the most important thing that I this is the key to success for me and from my point of view but you always have these situations when you rework a lot of tests this is actually, this is their real life yeah thank you