 Thanks folks for joining in. It's a real pleasure and honor to have Dan do the lightning talks. Dan will tell you the story about why lightning talks really matter, but Dan is the original creator of the APM project. And he's been the, he actually, Dan was it you, me, Srinni, a couple of us just happened to have a conversation at one of the Selenium conference and decided that we need to do an APM conference in India. And so we did one in 2019. And again, we are here. Thanks for all your help and support and putting the conference together. So cool. I mean, it's, again, great to have Dan and we're going to kickstart the lightning talks. I think I'll let Dan kind of explain how this is going to work and maybe even give a little bit of the background around the lightning talks why this is important. So over to you, Dan. Thanks again for joining from Vancouver. Right. Yeah, good. I'll say good morning. I know it's 6pm where you guys are. So I, this is why I wish I like India, you know, it's 6pm on a Friday night. We have 130 people on one track of this conference just coming to hear people talk about cool things with test automation. And so I have the task of introducing those people this evening for you guys this morning for me. So quickly, I'll sort of set out the rules. I guess I'll start with why we do this and then we'll set out the rules. And then we have five people on the schedule and we have room for a few more. I will tell you to message in a rush if you want to get added to the list. If you, we still have, I would say at least three more, something like that if you want to sign up. So first, why do we do this? We do this because the APM project would not exist largely without lightning talks. So, I won't go through the whole story again, but this project started as the sort of aftermath of a lightning talk I gave at the Selenium conference almost 10 years ago. I think it's nine and a half years ago at this point. And so, when we made Appium, we decided we wanted to always have lightning talks and so the idea of furthering the tradition and potentially hopefully one day we'll spawn another highly important highly successful project. But if not, I think there's a lot of value in listening to just what people have to say, even if it's just for five minutes. A lot of people have great ideas and so I'd like to have as part of this conference, an opportunity to give those people a large audience to share those ideas with and hopefully those sort of chemical reactions occur from this. All right, so rules. There are many rules. I'm not keeping a five minute timer. I'm not doing it. I'll assume it's in a rush, but I'll have to cut someone off if they exceed five minutes so you get five minutes. Talk about whatever you like. Those are the rules. That's all there is to this. And so with that, let me find our first presenter and promote him. All right, Daniel, your five minutes starts now. I'm keeping the time I guess. Okay, cool. Hey, everyone, Daniel. And so this talk is about a project that I did. So my last job at saw steps I reverse engineered a few things for us and Android devices. And one thing that we were looking into back then was how do you this was iOS 10 and 11. So quite some time ago. So we were looking in ways of how we could for a real device testing cloud get like fast video streaming to the cloud right so customers could do live testing and it will be super fast. Which it wasn't back then. And one of the ideas that we had was could we reverse engineer how quick time does it right so you might all know if you open quick time you can actually record iOS screen and everything so we found a better way and contributed actually trap you. But still you know I just couldn't get let this one go. So the question is how do you reverse engineer something like this right so as any good senior engineer like the first thing you do is you try to Google it. I'm like maybe someone has already done this. So you find this video on YouTube that is gone by now but back then there was one and you're like, yeah, somebody actually did it. So there's a way to get it working. Then you look further and you find discussions online without any links to any solutions and you're like those source code attached anywhere to the video and you're like okay damn it works somehow but there is no source code anyway so I thought you know how hard can this possibly be. And so basically started reverse engineering this and the question is how do you actually do this. Right. I mean one option is you decompile the source code and then you get something like this and try to understand how it works. Okay, the other idea is use fire shark and look what's going over the wire, right. And I always like to explain this. If you want to privately reverse engineer rest API right as a comparison what would you rather do. Look at modified JavaScript code, or just look at the, you know, API in your Chrome browser. That was basically what I did right so I open wire shark stop playing a video stop playing video, save the capture do some post processing and look at what I get and then I get this and like what is that. And I Google it and I'm like what is a good tip. And I Google it I find nothing. All these strings right there not helping me, but at some point it struck me is like oh this is just reverse by order right so let's skip some of those. And then suddenly it all makes sense right so this is actually not a good tip this is a ping, because you just have to reverse the bite order. And then everything comes together and you see all these values in it all sort of dictionaries and stuff and you go through the whole hex thumb figure everything out. And then you find that there's just a bunch of age to 64 units in there. So I concatenate them all to a file and then I was actually able to play video with video land. One second Daniel, we can't see your screen at the moment. Oh, you may need to click sharing. Don't worry. We won't take this. I'll pause the clock. Go for it. Did you see it. Yeah, now we see it. Totally forgot. Yes, this is the sharing thing that I was talking about wrap. Too nervous. Exactly this is a quick time feature right and. And let's see. So then I implemented this. It's open source. There's a huge reference documentation so if you're interested in how this actually works under the hood you can read that. And then in detail explains every little piece of it. Let's skip these things. And also there's a little demo on YouTube where you can actually see me doing it for the first time. So part of the goal was figuring out how to do this and run it on Linux, which is now possible. So if for whatever reason you want to have super high quality video stream from iOS device to a Linux machine you can do this now. So usually, if you do things like this the cool thing is if you reverse engineer it and actually really understand how it works you can do even cooler stuff than quick time can do. So one thing that is possible with this project is if you want to record audio only then you can also do that. So there's no need to get a video stream. If you run an Appium test and you want to capture device audio or something, you can totally use this tool and record the audio output of the device on Linux or Mac, whatever you want. And here's the link to the golden reference implementation. Right, so this works you can download it run it like I said it works on Mac works on Linux doesn't work on windows I tried and it's not possible. And that's it. All right, I would say a huge round of applause but I don't know how that's going to work here, but I asked we can also open the floor for some quick questions, maybe we can take two or three questions I'll ask question first to get this rolling. So you reverse engineer this is there anything else you think would be interesting to reverse engineer and return adding support for Appium so this you showed the sort of value you can get out of the process and sort of the unique things you can bring by reverse engineering as opposed to like using the APIs that come with a thing. Do you have any other ideas for things will be interesting. I mean I have another project that I talked about today right so it's a go iOS that allows you to run XT test for example so you can use Appium for iOS real devices on Linux which is pretty cool. Also, I enabled some things like for example Xcode in recent version has gotten this device state simulation feature where you can enable, you know, on the device to G simulation like lower network speeds you can activate thermal conditions degrade the GPU and stuff like that. It works in Xcode, but you know it's always a little annoying if you have an Appium test and you want to do this actually. I mean you don't really want to go to Xcode and enable it there. And this is why I added it to go iOS so you can do it from the command line. So if you run your Appium test, and you can just basically run this command line tool it has JSON output so it should be super easy to use. And then you can tell the device to I don't know behave like it's 40 degrees temperature and toggle all the speed stuff. Yep. Cool. All right, well thank you very much for presenting. It's a little help for me to rush to find out I think okay I'm wrong is now here. That's a name I recognize. So let's make. I'm sorry I don't know the genderization of this name, but let's make him or her. The next presenter and get rolling with that. Can you do that for me nourish actually then last deep is already there. I think Rajdeep then Rajdeep and then we go to up now. You're on the clock, by the way. Okay. Let me share my screen. Okay, can you see my screen. Yes. Okay. All right, welcome everyone. So, I'll, I'll talk about jetpack compose and how it goes along with apm. So those who don't know what jetpack compose is. It's actually a new view framework for Android. So in traditionally Android we have activities and we inflate those activities now I'm talking about Android developers here so they, they use XML markup for defining their activities and then they inflate their activities with views. They're slightly there's a very good improvement there in, in jetpack compose. It's a new framework, which is a modern toolkit for building native user interface. Same as before we have used to build native user interface but it simplifies and accelerates the UI development on Android. What does that, what does that mean because traditionally we have to define activities and the views and the layouts in XML markup now using jetpack compose. We can do it using code and the code basically written in Kotlin. So with this, what it means code is, code is much more easier to handle than handling the configuration of XML files. So it's, it's easier in that sense that it can be developed very quickly. And also code is more reusable than, than XMLs, right. You can wrap the code and you can, you can, you can create modules out of it and same in jetpack compose, you can create composables which could be used to show on your screen. And you can create those composables and store them in your code repository and then you can compose more out of composables. So, think of it like when you are developing Android, developing a user phase for a game, right. There is no, there is no defined position of things there. You just render things whenever you, you, and wherever you want on the basis and compose does exactly similar things. And because it's so, so nice and so developer, developer friendly, it is, it is getting a lot of ground and many companies have already started migrating their views on compose because it definitely gives gives them an edge over, over regular views. Now, since it is so popular, it's going to definitely be the future of Android use. Same way in iOS, you might have heard of something like SwiftUI, in case of Android, it's jetpack compose. Now, since jetpack compose is already out in the world and people are already people have already started building their apps using jetpack compose. And then we should talk about what is the testing support for it. Unfortunately, there is no end-to-end support in any of the available frameworks right now. And APM is also one of them. When I talk about no support, I'm actually lying. There's a very little support because in APM there are two options. One is APM's UI Automator 2 drivers. And there's a broken support there. Why I'm calling it broken is basically you can actually see the view hierarchy and you can find the element using content description or say text and you can operate on them. But whatever you will see in the hierarchy will be just a class, will be a view with the class android.widget.view. So there will not be like any text, edit text or frame layout, linear layout. Everything will be view because it's just a hierarchy dumped in terms of accessibility. It will be something like how does the end user sees your hierarchy and the content descriptions will be visible there. However, if you want to go with your APM UI Automator 2 driver, the support is going to be limited because you'll have to end up adding content description to each and every view that you want to be identified, which will basically mess up the accessibility of your application, which is a bad idea. So another option is APM Espresso driver. And as of now, there is no support in that APM Espresso driver. Now, since UI Automator 2 and Espresso are the framework provided by Google, which are being utilized by these drivers. Google has naturally provided another framework for Tech Compost Test Automation. It's called Compost Test Rule. It's basically based on instrumentation again. So what this means is we can actually instrument our application under test and use this rule. And that's what I'm currently trying to work on. So in the APM Espresso driver, what we do actually is we instrument our application under test and we create a companion APK, which is instrumentation APK for our application. And in that APK, the work is in progress for adding source code for end-to-end test support for Jetpack Compost Automation. As of now, the support is very limited and it is available in this GitHub request. And support is only for find element, click, and getting text. Also, there is a support for display. Now, you can see it's a huge PR with lots of command, which shows how I'm sure I am with Portland right now, but still trying to find my way out here. A lot of good review comments from APM maintainers there. So I'll fix them. After this is pushed, I'll request all of you who are interested to contribute in this repository for more actions. Not just find element, but also let's say for find elements for getting displayed selected. And then there are many, many, it's going to be a new driver in itself, inside a driver. So to summarize, that gives a quick overview. Two more sentences and then you got to wrap it up. Okay, yeah. So there is no need to, I mean, that's pretty much it. So that gives the current status of the support for Jetpack Compost Automation in APM. Thank you. All right. Thank you, Rajdeep. I guess if anyone has a question, raise your hand. I'll give you like 10 seconds to do that. If you raise your hand, we'll go to you. If not, I will move on to our next presenter, who I know less about than Rajdeep. So I guess let's go to Atmaram. Hello everyone. Can you hear me? Yes. Okay. So this talk is a little bit different. This talk is not about APM or any test automation framework as such. But this talk is about day-to-day activity of tester, that is data creation. And I'm going to talk about one of the tool that I myself have been contributing as a open source tool. This tool is named as COR. And this talk is about using COR for automating test data creation. So you might have been creating test data for your day-to-day manual testing or automated testing. You might need to create bulk test data or you might need to do ad hoc test data on most of the scenarios while doing testing. And how this tool can help you over there. I'm going to show that. So challenges with test data, there are typically following challenges that we face with test data. Like ad hoc test data creation requires manually changing values in postman or curl request. So suppose you are using curl or postman. So this premise of this entire talk is we are creating test data based on APIs. So when you are using REST APIs for creating test data, you might be using postman or curl request for creating this test data. And many times we need to capture value from one API. For example, authorization headers or many times we need to capture some value like some ID or something from previous API and pass it to the next API. So that we need to do. So what we generally do in postman, we write some output script or input script and we capture those values. Many times we want to make multiple calls by just changing few values in the request. So sometimes what we want to do is like capture the value, make n number of calls and create n number of data. At times we want to iterate over response of arrays to make equal number of API calls. So like suppose when API gave you a array and we want to create that many requests and we want to create that many data. So these are all challenges associated with test data when we are creating test data through APIs. And overall it seems time consuming. And there might be many more things which you might have faced. So for the sake of simplicity, I am going to demonstrate a simple application within this short talk. This application I have created sometime back two, three years back for demonstration purpose. This application is shopping application. There are categories of products and subcategories of products. So what we are going to do is we are going to create category and we are going to create subcategory within each category. So these test data we want to create. I think we are not able to see your full video. Your face is getting chopped off. Okay, okay. Yes, perfect. So we are going to create category and we are going to create subcategories within it. So this is a category, this is a subcategory. And steps for creating same using APIs, we are hitting the API endpoint, API slash category. We are passing it a name and in response we are going to get a category ID. Once we create that category, we will get a category ID in response. And when we are creating subcategory, we will need that category ID to be passed for that subcategory to be created within the crack category that we previously created. So that's the simple use case that we are going to talk about. Now, how would you, how would you do, suppose you want to create category sometimes with one name, sometimes with other name. Sometimes you want to create bulk number of categories, subcategories. You will do all of these ad hoc things while testing, right? Now, what we are going to do is we are going to use a car, which is an open source tool. It has an IntelliJ plugin for running this tool. It has its own programming language called as a journey programming language. It is written in Rust programming language. So it can be run on Macs, it can be run on Linux, it can be run on Windows as well. So all the Rust binaries are compiled to the native binary. So this is a cross-platform tool actually. Right now, the binaries are being published only for Macs, but it could be compiled from sources. Binary could be compiled from the sources. And how car help here is it can automate sequence of API calls using scripts. And each API call can be designed using a request and response template. So you get a templating feature in this particular car tool. And you can capture values from responses using templates. Now, the way we capture values sometimes in some templating language or some using paths and all. Car has its own syntax for capturing values. You can capture arrays. You can capture many different values using those templates. One minute warning. Yeah. And resultant scripts are like command line utility. Okay. And golden rules for call is it uses same captured value correlate for filling subsequent request. And if some variables from the template is not known at the runtime, it asks it to user. So let's see the demo. So here is a simple script created in core. It will hit the post request for creating category. We are capturing value of the ID over here. And we are passing it to the next request. And when I run this, it is asking me value for category name because it is not finding it anywhere. I will say electronics. It is asking how many subcategories I want to create. I will create two. We'll say TV and mobile. All right. We need to wrap up. So I'll give you two more sentences and then we got to close this out and move to the next person. Yeah. Yeah. And that's how it has created a test data that that is just the last thing that I'm going to show. It has created a category electronics and TV and mobile. Yeah. So that's that's the thing that you can use any questions. I don't see any hands up yet. But you will be able to contact up from after this. I guess if you have any questions, we have about 13 minutes left in the session and two more talks to do. So I'm going to move straight ahead to the next presenter, Andre. So Andre, please, your time starts now. So I have only three minutes. I'm getting rushed. Five minutes. So you have until seven past or just 37 past period. Great. Thank you. My name is Andre. I'm, I'm from Estonia, from Europe. And I'm going to show you how to write really concise or expressive or readable or short automated tests in a film using library selenite. Just two minutes. So if you're writing some automated your tests, either for web or for mobile applications, you should always have several typical problems. Most of first of all, you have all these problems with flake tests and with verbal syntax. You don't need to write too much of boilerplate code. These are typical problems. They are always typical in selenium tests, web tests, and they are probably even bigger in mobile tests because mobile is lower and so on. And I have one possible solution for this program. This is a library called selenite, which I created 10 years ago and which got quite popular in web testing. So what is selenite? Selenite is a free and open source library which gives you a concise syntax or API to write readable and stable tests. More information you can find on site selenite.org or in Twitter. And first of all, I will show a test for web and then I will show how the same syntax can be used for mobile tests. So how the test for web looks like using selenite library. Selenite has actually quite a few methods, two free methods. The first of all, you need to use method open, which just opens the browser. At this point, selenite wraps up all that logic built inside of selenium. It downloads the driver binary. It initializes the driver with all those complex settings, options and so on. And for you, it's very simple. Just open your browser. Then using method dollar, you can find some elements and dot and call some methods like set well, click, send keys and so on and so on. There is plenty of methods. And finally, you can check some results. You can check that this element should get some text or some class or some values and attributes and so on and so on. There is plenty of features, but you can don't have time right now to talk about that in details. But shortly said, don't you think that this syntax is cool? I think it's cool. It's great because we have short syntax, we have really readable tests, which has built-in waitings, which solves most of flaky tests. Yeah, probably I should say that all these methods like should have text, they actually do contain waiting. You know, you do wait a little bit if needed, if the limit is being loaded still and so on. It has automated screenshots, smart error messages and so on and so on, quite a lot of features. And the good news is that actually Selenite can be also used for mobile, for testing mobile applications. There is special integration of Selenite with Appium on GitHub. And now I'm going to show how Selenite looks like for mobile tests. Tests looks like actually really, very similar, really simple. Again, using MetaDollar, you can find some elements by name, by its path, by whatever. And again, you can do whatever you can do with typical Appium elements, clicks and keys and so on. In this case, we see a test for a calculator in Android or in mobile. And in the end, we can assert the result, assert that some result field has about six. Since we have a little bit time, I can even run this test. I hope it will be fast. As you see, this is a real goal, a real project, it absolutely executes. No magic. Yeah, and as you see, this test is really short and simple. So yeah, I hope you see my Android simulator, which runs the tests and clicks some buttons. Yeah, so with just a few lines, just a few minutes. And you might ask, can you use some annotations, find by something like that, or in my tests to create page objects, to make them even more readable. And the answer is yes, you can. You can use all that Appium annotations that we typically use kind of Android, find by iOS, find by and so on. You can even mix Selenium annotations and Appium annotations all together, and even reuse the same page object for both mobile platforms and for web tests, if occasionally we want to do it. So typical page object could look like this. And then in Pest, you can write even more readable and concise tests. You can initialize page object using Selenite method screen, and just use methods or fields of this page object. And again, I showed the results in the end. That was the demonstration of Selenite, and yeah, overall the good news is that you can write concise and stable tests even in mobile applications. If you have any questions I can answer, or later you can get me in Twitter or whatever in GitHub, and I can answer all the questions. Thank you for your attention. Thanks, Andrei. All right. I'm going to check just in case it appears Qashon is not here. If you are here Qashon. We have time for your talk. Otherwise, we'll assume he's not here. And we have time for one more person can have five minutes in front of these 150 people. If they wish, I guess just raise your hand and zoom, right? Or something. I don't know if Pooja's around if she wants to sing to us again this year. I'm out for that as well. We'll give it a minute to see if anyone volunteers. Yeah, I am just promoting Anil. Thanks, Andrei. I'm going to... All right, Anil. Five minutes. And then, Nuresh, it's all right if we go over by two minutes, right? Yep, that's fine. Good. It's all yours, Anil. Hey, hi everyone. Can you hear me? Yes. Is my video visible? Yes, yes. Okay, great. Hey, thanks for the opportunity. Actually, I wasn't prepared, but I thought of sharing one thought with all of you. So, yeah, we talked about the technology. We talked about the selenium. We are talking about the EPM and everything, right? So, yeah, all this is good. I mean, we can achieve parallel execution. We can reduce the test time and everything. So, all things are fine. But when it comes to a testing, what I feel is, what we should be delivering is the product quality. And how we can deliver that product quality is, when we think from an end perspective and user perspective. So, that is, again, an important thing which we should... which all of you should consider. And even that is one case and we should be thinking out of the box. Yes, looking at the technology, that is one perspective which is fine. But again, if we can think from an end user perspective, what they need, how they test it, definitely we are going to find more and more bugs. And with that, what we did is, we actually... we started one initiative. Like, we were executing all these test cases through our automation suite and everything. So, we used to get a very little number of defects. But what we started as, we called it as a break the app. So, we as a team came up and we decided, let's break the app. Let's think out of the box and let's try to find out as many defects as we can. So, surprisingly, what we got is, through automation, we used to get hardly like 10 defects or 12 defects. From this, thinking out of the box, actually we could find more than 20 to 25 suggestions, not bugs, but the suggestions here. This is something which we can improvise in our app. So, we actually did a lot of out of the box thinking there where we actually tested our app against... when the network is actually very poor, how do we are mobile app response? That is something what we thought. The storage level is very low. And this is actually, these are the real-time problems which customer can face. So, there are people who actually have a device, the storage limit is almost full. That's like a 90% of the device is full. And at that time, how our app performs. So, these are the things actually we never thought. But we thought that these are the problems which customer can face and we could find more bugs around it. So, what I wanted to tell again is when we think out of the box and when we think from end user perspective, that is something where we can achieve good product quality and we all should aim for that product quality because we as a testers, we wanted to deliver a good product quality and that should be our aim. Yeah, so that's the small interesting story I wanted to share all of you. Thanks for this opportunity, Dan. No worries. Thanks to you and thanks to everyone else who gave a talk today. It was looking pretty grim in the first five minutes but we pulled it together and I think there's some good stuff here today. Cool. Since, I guess I'll draw the session to a close and once again, thanks everybody. Thanks to Nourash and everyone with the organizing committee for organizing this. I guess the conference is over, we're just in day one so I won't give the full like whatever. I hope to see all of you in person soon. Hopefully the next time we do this conference or signing conference, it will be reasonable for me to make it out there along with the rest of us and we can do this in person again. But hopefully it's trending that way at some rate or another. Anyways, that's all I've got. I was impressed with everything I saw today. I always enjoy going to India for a number of reasons that I won't go into right now. The amazing talks but the other things as well. And I look forward to hopefully doing this again in a couple of years or maybe turning up at Selenium conference next year or something like that. Thanks so much Nourash and everybody who organized this. And thanks to all the speakers.