 So, I am an automation architect and working with InfoStretch for the next eight years. So, basically InfoStretch is in like Ahmedabad, Pune and we are also expanding in Bandor as well. So, in these talks I will cover, so we developed some QE products which mainly based on like we do the automation. So, we have created some products around automation and we have also a product like predictive QA and some AI based tool. So, basically in these five minute talks I will cover, so one of our products is called QMetry Automation Studio. So, before I, so let me just give you, overview of this product through one video file. Quality tools will help you achieve that goal. QMetry Automation Studio, QAS. Yes, I mean this is not so easy. Approach to the software development life cycle for a faster time to market. Today you need to be more agile and work with various DevOps constructs. Today you need to run. Doing this is not so easy, especially when you are working with complex enterprise applications. They are integrations with a need to release features quickly. And that is why we have designed a tool specifically for you to tackle these challenges. So, now you can focus better on testing and finding bugs and our quality tools will help you achieve that goal. The QMetry Automation Studio, QAS is designed to manage any automation effort seamlessly. Whether it's UI, mobile, web or web services automation, QAS supports all these with common standards and guidelines for execution. The Automation Studio offers support for open source technologies such as Selenium and Appium. The tool supports an advanced automation strategy to address significant market needs. It is designed for the manual teams making the transition to Scripless Automation and it supports automation experts with coded Scripps. This tool is designed to support complex mobile conditioning scenarios like barcode scanning, touch ID, location spoofing and more. It offers an extensive authoring support with BDD, keyword and code-driven approaches to offer an approved automation experience. Today you need to support a sophisticated device world with a multitude of test cases, scenarios and Scripps for these variations. The Test Automation Studio aims to solve this problem with its built-in objective spy built for iOS and Android to test and analyze any application with a single click. The fundamentals of test authoring are changing to accommodate natural language for ease. This enables the product and business analyst teams to pitch in and author test cases and manage their projects easily. The Qmetry Test Automation Studio has made BDD and TDD as the de facto standard with its content assist and step viewer to enable better communication across teams. The OmniChannel Digital Enterprise demands a lot and QAS is the Swiss Army knife you need to ensure scalability and comprehensive coverage for your application. The studio brings out-of-the-box scalability containers and leverages the cloud to provide the right CI integration with mobile conditioning libraries and many other modules. No automation effort is complete without the right coverage and analytics. QAS offers a detailed dashboard that showcases all the results of your automation initiatives filtered by various types of attributes. The Automation Studio is designed for DevOps and the same scripts can be used by developers, automation engineers and operation leads enabling seamless DevOps outcomes. Simplify your automation efforts with the Qmetry Automation Studio. Quickly learn and start your new automation project. Talk with us now. Yeah, so basically this QS, so now you've got the idea, right? So basically it's an automation tool. Yeah, so Qmetry Automation Studio is basically an automation tool, right? So where like, you can create a uniform script that can be worked on the different platforms like a web, mobile and the cloud base also, right? So let me just quickly go through with the product itself. So I have this, the product installed in my machine. So you can easily create, give you all the basic capabilities like create new project. So as I said, it's a uniform way, right? So all your resources like object, locators, your script, your implementation, right? It does support different techniques to author your test script and all, right? If you see in my video, right? So we do support like BDD, keyword-driven, test-driven, right? So based on your choice, you can write your script in any like BDD and all, right? So let's say, let me just open quickly one BDD scenario. So we have like an in-built capability for test data manager also, right? So every test needs valid test data, right? So that test data, so this studio can consume in any other format like JSON, XML or TXT. You can put your test data in the external source. So this BDD scenario, so here you can see, right? So for this particular searching, flat with the data, right? So this data I can create in the under the resources. And the similar way, like it's very easy to create a new automation script. So we are offering like some in-built steps, right? So it's very easy, like very quickly you can create your test. So if you see here, like you can use the different checkpoints for assessment, verification. So it also does support like web service. So you just need to define your web service request in form of tabular and it will automatically generate the test case. And it's very easy to create a test for mobile web as well as API, okay? And so it's also like in-built automation framework also, okay? So when I say automation framework, right? So there are like a different concept, like we have implemented in this, like we can create a component. So component means like, so let's say in my application there are some components which is having like a common characteristic, right? So I just need to create one element for that component and that I can reuse in the different pages also, right? So it will reduce lots of your time in terms of implementing your automation, right? So let's say if I open this calendar, right? So it's a most common example. So let's say in every application, the calendar component can be used in the different pages and all, right? So in normal traditional automation, we generally write the locators for each and every elements and all. So by using this framework, like it's very easy, you just need to extend, it's a Java-based framework. So you can just quickly extend with the web component and describe the component characteristic by using some annotation, right? And then I can use this component in any application or any page, okay? So for regarding, so it's leveraging like Selenium and Appian. So we can use all the Selenium and Appian capability through this. So as well as like we have created the mobile library also that can help you to solve the complex mobile scenarios as well, like bar code and if I want to automate the scenario, like deposit a check, right? So it has like an in-built library also. So by using this common BDD steps, we can perform such automation also. Okay, yeah. Thanks, everyone. Okay, great. Thank you everyone for joining. My name is Misha Ivinnik. To actually clarify one thing, I live in Canada, so the topic and the talk that I'll present will be probably a bit different for you guys. So the stress-driven development. Basically here I'll try to tackle the problem of stress we have at work as developers and how I'm personally trying to tackle it and continue my work in a creative and innovative way. So as I mentioned, there is a problem right now, stress that we have at work. And that stress basically arises from the fact that nowadays office becomes our life, especially in the states where they try to make an office as appealing as possible, where they serve you lunches, they build those fancy rooms where you can play games all day. So they really try to attract you and basically stay in the office. So as a result, you don't really separate life and work as much. And it's very difficult for us as engineers because hopefully we enjoy what we're doing. So you say, oh, as a developer, I work extra, I love what I do, so there is no problem. I would actually say there is still that problem of continuously working for your employer. There's also stress that may arise from the fact that you might be a consultant and the consultants usually work 24-7. Or you maintain legacy systems that also add some stress because you can be innovative when you work in legacy systems as much as you would like to. And so the way I try to tackle that stress is by something that people really try these days, especially in North America. It's some sort of meditation. Or there is an app that's called Headspace, which I found a nice introduction to just the breathing techniques that help you start your day in the morning, 50 minutes sitting in silence and really get yourself together before you go to work. It really helps you to kind of clean yourself before you go into that daily routine. It's daily routine that usually adds the stress to your work. So another thing I've tried before is the float therapy. It's also a great thing to try because what it does to you is basically it's the noise and the sense isolation capsule. So you don't hear anything, you don't see anything and you lay in the salt water for like 90 minutes. The whole thing nowadays is that we have so much noise pollution, light pollution and this kind of isolation for a short period of time really helps you to remove the stress. And the reason why I even talk about it is as soon as you get rid of that daily stress, you can actually be more creative, innovative and productive. Studies have shown that 40 hours a week or even like 100 hours a week that some people try to do, it's not going to help you to deliver a better product. Yes, you might deliver a product faster, but again, the hidden cost of any software isn't maintenance. Hence, when you're delivering a software fast with a stress in mind and just pushing yourself as hard as you can to have something on the market, you're probably not thinking as much or as well as you would about the architecture and how to actually write this software in an easy to maintain way. So if you actually get rid of the stress, you will be able to write that software much better. And if you're a lead or a manager, you really have to encourage your employees or your colleagues to kind of get rid of the stress. The good thing I've noticed myself because I have a lead position is to lead by example. So really try yourself, take days off. That's a big problem I've noticed especially in America where a thing called unlimited PTO, paid time off, is a thing where they don't have a set number of days for you to take a vacation. You choose when to take a vacation. As a result, people often don't take any days off at all and if the game adds to the stress, you have to take time off. Speaking at the conferences and traveling is also a great way to get rid of the stress. That's what I found for me very useful. Read the book. It's also a good way to, especially a non-technical book, it helps you to kind of broaden your horizons. And to finish my talk, what I like to usually say at the end is yes, life is short. You can do very little things to prolong your life but it's up to you to choose how wide your life would be. So really do all those things I've mentioned. Find your own ways to work with the stress and get rid of it and maybe share your tips with me. I would be very interested to hear from you guys. Thank you. Hi everyone. Hope you're all having a wonderful day. So I'm Megha. I work with S&P Global. I'm a test engineer there. And I want to take this opportunity to discuss a Selenium Grid cloud automation solution we built to overcome a problem that basically entailed having to run, as you can see, around 1,200, 1,300 test cases every time there was a major build. And these were all UI test cases to be run on browsers and the underlying, the tools that we're using, Selenium, Java, our own test automation framework that we built in-house. So earlier, a year back, we were running all these cases on an on-prem Selenium Grid, which basically consisted of powerful Windows machine acting as the hub and to which were connected a variety of Windows VMs, few Linux VMs. And we were basically sending all our 1,300 test cases to this hub to be sent over to all these connected nodes. Now, as you can imagine, as test automation engineers, we already have our code base to maintain. On top of that, you add the infrastructure that also needs maintenance, upgrades, hardware upgrades, all these changes from time to time. So as a solution to that, as a workaround to that, and there was also the problem of limited hardware. Having to run all these test cases, we were limited in the sense that we had 20, 30 VMs to run these on. And once the load actually increases, the CPU and memory use its spikes, your tests slow down. There's nothing wrong with the application, it's slow down. So the next step we took was to dockerize our framework, run the test cases in Docker images, customized Docker images. So that helped us to quite an extent. There was less maintenance headache because Docker, right? And every time the load went up, Docker was zippy, it was fast. It's any day lighter than having to run on a VM. So that was that. But even then we were heavily limited in the sense that the infrastructure on prem was still not able to facilitate, was not able to handle all that load. So we decided to host our grid in cloud. And for that, we did a lot of POC. We started from the very basic that, you know, we are going to spin up EC2 instances in AWS cloud. So we began from there. We started doing our POCs. Then we thought about ECS. Then Fargate was launched around the same time. We started thinking about, you know, hosting on Fargate. So I'm going to talk very quickly about that. But before that, I just want to launch our containers on cloud. So as you can see right now, it's a 503. So we have a Jenkins job, which basically upgrades the Fargate services, which are basically three in number, one service for the hub, one service for Firefox, having, as you can see, 15 containers, and one service for Chrome, having five. Because most of our test cases are, you know, meant for, are supposed to be running on Firefox. So I'm hoping in less than two minutes, the grid should be up. Yeah, so I was talking about the limitations we were facing with on prem, you know, hardware. Every time that number of test cases would increase, or, you know, we have to run the same test cases multiple times, the infrastructure would completely give up. There was cash getting created. There was a lot of maintenance headache. So we wanted to get rid of all that. So we thought of using Selenium. We thought of using AWS Fargate. Now Fargate is AWS solution for running your Docker containers. Some of you who may have worked on ECS, may be wondering how is Fargate any different from ECS? In ECS, you have to spin up your own EC2 instances, which are nothing but ECS agents. You have to spin them up. You have to maintain them if there are patches required, anything maintenance related required. The effort still goes there. Fargate is one step better in the sense that there is no maintenance. You don't have to, you know, spin up your machines with a particular configuration of CPU and memory, and you don't have to build your own AMIs. You don't have to look after them. Fargate will do the job on the fly for you. It will create those instances. You just have to, you know, be very particular about what configuration you want. If it's taking time, it's a good sign. While it loads, I'll also touch upon another aspect of Fargate that you are charged for the amount of time that you're running your test cases, right? And you're charged by the second. So if your test cases, right now, our test cases take anywhere between 50 to 60 minutes. With this, we have cut down the time by one-fourth right now. So as long as we need the instances, we keep them alive. Once we are done with them, we shut down the services, and, like, in a day, we're using it for barely 15 to 30 minutes, and we're charged only for that. It could be because, you know, of the internet. And the last thing, it won't start right now. I don't suppose it would. But the last thing is there's also auto-scaling involved. So suppose the request comes in for, you know, running the same batch of cases simultaneously on different environments, you know, that load has doubled. So there's auto-scaling logic also involved, which will add your predefined number of containers to the grid, and that will happen when the CPU and memory usage spikes. It starts touching 80%. So AWS will automatically detect that usage at the containers so that your tests are not skipping. They don't die down due to lack of containers. And basically, they're not in queue for a long time. Sorry, guys, I lugged out today. There's no internet. I mean, the internet is not on my side. So if you're interested in the solution or you're looking for something similar, just let me know. We can talk about your offline. Thank you. Hi, I'm Shridhar. I'm working as a QA in ThoughtWorks Technologies. Okay, so today, the whole day, we have spoken about mobile in one of the tracks. So I'll just quickly show you how to inspect an element on one of the mobile apps. Has anyone used it before? Has anyone tried this? Inspecting an element on mobile apps? Android.ios? Yeah. So yeah, I'll quickly start in the interest of time. So I'm using a tool called apm desktop. So after this, I'll just quickly share an experience. We had a specific problem and how did we overcome that? I'll just quickly share it after this. So I'm just starting the server. You can see it, right? Okay. So first I'll show how to do an iOS one. So these are the basic desired capabilities which we have. So what's a desired capability? So we know apm is a client server thing, right? So client server application. So the capability is the one which says, so for any client server application, we need a session. So the desired capabilities is the one which the client says to a server like, I want this type of session with the server, right? So that's the, in basic terms, that's the desired capability. So in here, I have added a few basic ones. There's the app path. So the app path is again for simulators. So it should be a zip file or a PPP file. If it's an iOS device, then it should be IPFI, okay? So platform name, automation name and device name. So version and also UDID. So I need a UDID of a simulator because I don't have any real devices connected. So I'll say just instruments, instruments, iPhone devices. This will give me the list of simulators available on my box. I will just select one. So UDID is equal to this one. So this will short me an app which is in that path, the zip which I have saved there. So this works, the APM desktop works with both iOS and Android. Yeah, so this started, booted me a simulator and it's launching the app. Okay, so this is the app and it will launch me the inspector here. Yeah, so this launched me the inspector. So in here, I can just select on this like similarly how we inspect the web elements. Similarly, we have to do it here, right? So if I see here, I can see the label as user name, name as user name, value as admin, like all these things I can get. And I can just use the APM like find by iOS, find by Android, find by, and I can just select this element and I can do the actions on it. Right, makes sense? So this is how we do it for iOS. So for Android, we can do it using the same tool, using APM desktop. But let's explore something different. So Android SDK provides something that you can do by automator viewer. So this one ships along with the Android SDK. So we can use that to inspect the elements on an Android application. So I will just go to... So this used to be there in Android home, but with the latest version, they have moved it to bin tools. Yeah, so this is the Android automator viewer. So if I just click on this, so I have an Android simulator open here. So in Android, there is no difference between a simulator or a real device. It's just the ADB command which works for both. And this one will get me the current snapshot. So if I have to select something, if it's some app which is open, then I can just get the... So if this is the app, so it gives me the package name, content description. So content description is nothing but the Android... Fine, I will just quickly explain that later. So this gives me all these details. So we can inspect the element using this tool and we can just perform the actions on it. Okay? Yeah, so this is what I wanted to show on the APM desktop. So one more thing is, currently I'm working with a client which has web application and also Android and iOS native applications. Yeah, one minute. I'll finish. So yeah, I'll quickly show you. So in the web application and the native application, the flows are almost the same, except some customized like my account kind of applications, my account kind of pages. So what we did was like using APM we can find, like you can see here, say like there's a single mobile element which I can find it for web, also for Android and also for iOS. So using the APM field decorators and also multiple strategies are available to find the allocators here. So like we did this and also say there is something to say, I would say like we have to read an alert, we have to read an alert. So the way we read an alert in iOS is very different from Android and also in the web. So how we did that was like we added an interface which provides the runtime polymorphism. So if it's an Android driver, then do it in a different way, like use a different application, like use a different element for it. If it's iOS then use a different thing. So like this we solved that problem. Yeah, thanks for this opportunity. Tested firsthand and some of it that I haven't tested firsthand. So the first item I'd like to mention is Aspire. So following on from Dimitri's talk on stress-driven development, Aspire is a wearable device that monitors your breathing. So you can monitor your stress and whatnot. I actually have two of these devices. I would normally bring them around to demo but I didn't pack it today as I came here. It's an app. You can see your breathing in real-time as well. This device connects over Bluetooth with your phone. You can either wear it on your waist pocket or you can wear it on your bra strap. I'm looking around. I don't think there's a large amount of the audience wearing bra straps here. I don't know. You could all be wearing bras underneath. I'm not judging. No judgment here. Hashtag. It can give you notifications when you're tense. I don't know if this might cause more tension for some people. But I found it useful. There's been one or two situations where I'd been in a doctor's theater surgery and I had this little device vibrate against my skin to tell me I was stressed. Unfortunately, I was in a situation where I couldn't get out of that stressful relationship. I imagine if I wore it here in Bangalore, it'd be buzzing every time I walked into traffic. Probably. It can give you stats over the day. For example, how many minutes you are calm for the day, how many times you are focused, how much tension you had during the day, your activity, your number of steps. I think nearly every wearable these days can monitor your step count and how long you've been seating as well. So you can monitor more other elements of your health if you like. Why did I stop using it? I found when I wore it on my bra, it would actually rub against the skin and cause discolouring. So that wasn't all that great. I moved as well and misplaced the charger. I ended up getting a replacement. It also wasn't working very well with Android Oreo at the time because it was Oreo had just been released. So it's one of those things that I've used once or twice, at least for a month or two. I really enjoyed using it, but it's one of those things you buy once and use for a bit and then get out of practice. I would like to practice more mindfulness techniques, so I might recharge my spire and start doing it again at some point. But that might be one combat to the stress-driven development. Monitor how much you get stressed during the day. Another device is the Android Wear. When I was a contractor at Google, they gave me an Android Wear device to help with testing. So I wouldn't have gone out of my way to buy it myself, but they gave me one to test with. I didn't like it. It was annoying. There's a reason why I hardly used it. Has anyone used a wearable watch before? Hands up. Keep your hand up if you're still using it. Yeah, that's actually not too bad. That's better than I expected. I'd like to experiment more with wearable app development at some point, but I wasn't super impressed with that. Something slightly related is not really wearables, but I was experimenting with using the Nike Runner to monitor my running. It uses a lot of similar technology with what you'd use wearables for. There are watches and whatnot for this. The reason why I stopped using the Nike Run app was I broke my ankle about seven months ago. You don't really do much running with a broken ankle. But I would like to get back into it. I liked a lot of the data it showed. It was all free. They had training programs you could sign up for. They had this every Sunday that had a 5K challenge where they would tell you how many people were doing a 5K challenge. And it would kind of motivate you to just go out and run for 5K. And it was nice to see improvements over time, gamifying some of those stats. PeriFit is for women's health. It is a device that you wear on the inside. So, guys, you can't really test this one out. All that is loose. It's used for... It is used for pelvic floor strengthening. So, you wear it and you squeeze the muscles and you see this butterfly go up and down. And you're supposed to collect little flowers. Sorry. Is that... Am I at five? Okay. If you're an all-male dev team, I think it might be a little challenging to test this in person. But if you do overcome those challenges, let me know. But thank you. The problem we were dealing with was innovation. And function, innovation is equals to... So, I want to write this because this is something... is the key for what we've figured it out. Is function, innovation is equals to the organization that people you have into architecture. The architecture that you put them into. Keep our mechanisms into culture. Right? So, the biggest pain point here was nobody wanted to write this. No, not a single engineer wanted to write this. But there are a set of engineers who really wanted to write this. And those are all engineers who had worked in open source. And we saw people who actually contributed in open source. They really understand the value of tests and like craftsmanship for writing code. So, then we started asking everybody to contribute in open source. And suddenly everybody started realizing, okay, probably, yes, it's good to write tests. Right? Mechanisms. When you give people processes, simple processes, they understand, when they do it multiple times, they understand the value of them. So, we had no processes. So, we started putting a lot of processes, like from test development, retrospections. All of that kind of led to an answer that we need to stop wasting time like releasing stuff. We just write small code, right? And we just test so many things across mental platforms. That... And then we moved to an architecture which was bought. Essentially, each part has a product manager, a designer, a set of engineers, and they own a problem autonomously. They can do whatever the fuck they want to do to solve that problem. And they can take n number of months to solve that. But the problem is your component are not like this. Your components are shared. So, how do you solve that? So, that's it. Looking at this and this, we kind of created a team called cd slash ci. And we looked at our architecture as any time we need to solve a problem, we need to create a different pod which productizes a problem. Like for example, we productize this infra at point of time. We now have productized continuous-driven integration. We've productized writing tests. We've built in-house frameworks to make tests very easily. We've built frameworks so that everybody can manage their components and still make staging available for everybody. But it was not simple. I think if you guys want to bring that change, focus on culture, if you kind of make people, make engineers see and contribute in open source, that would be a big leverage point. So, I hope this kind of helps.