Speaker Pitches (Vote Now) Automation Guild 2024 with Joe Colantonio

Foreign.

Welcome back to another exciting episode of the Test Guild Automation Podcast. I'm your host, Joe, and today I have something special lined up for you. We're on the brink of the 8th annual Online Automation Guild event, happening from February 5th to the 9th, 2024. And as always, we are committed to tailing this event to meet your specific needs and challenges. So every year I reach out to previous attendees, asking them what they're currently struggling with and the topics they're eager to explore. It's a tradition here at the Guild that ensures our sessions are not just informative, but also laser focused on addressing real pressing issues that you all are facing. It's all about community driven topics designed to empower the Guild. So I've taken your valuable feedback and put out a call for speakers to create sessions around the topics you told me you want. And now we're at the next exciting phase. Voting yes, you heard it right. We need your help to select the sessions for this year's event. Remember, this is a community driven initiative and every vote counts in shaping an event that's tailored just for you. And this year we've added a twist. Our potential speakers have submitted speaker pitch videos giving you a sneak peek into what's in store and why you should choose their session. We have over 100 incredible sessions and after listening to a few of them, we need you to vote on all your favorites. So to do that, all you need to do is head over to test guild.com vote. I'll also have that link in the comments and in the show notes and make your voice heard. This participation is crucial to helping us put together the most impactful speaker lineup possible. Ensuring the eighth Animal Online Automation Guild is not just an event, but a transformative experience like it has been the past seven years we've hosted it.

So are you ready to dive in? Let's explore some possible speaker sessions together. And remember, your vote shapes the future of the Automation Guild. Let's make this year's event the best one yet. Vote now. Have your voice heard. Go to testguild.com vote and look forward to seeing your favorite sessions and your feedback as well.

Hi, my name is Dan Rialy and I'm a lead QA engineer supporting multiple teams at Dun and Bradstreet. Currently I specialize in web application testing and SaaS products mainly. So during a meeting for a major upcoming project, a senior developer asked me, what is smoke testing? Right then and there I knew I had some explaining to do. And this is not to knock that developer by any means. He truly just did not understand what smoke testing was and why it's so important. So I'd love to share that story in a little bit more detail and just provide some insights into how a simple question and conversation led to more quality advocates on our team and more respect for QA and what QA does. I'd like to talk about what smoke testing is and where it originated from. I also like to present a list of do's and don'ts for smoke testing just based on my experience throughout different industries and different products. So we'll take a look at the steps needed to implement simple yet effective smoke tests and you can leave with a playbook for your organization. If you're not utilizing smoke testing today, or even, even if you are, some things that maybe you can include in your smoke testing. Hope to see you all at the Guild.

Hi everyone, my name is Karim Salomon, I am from Bolivia and. Well, one of the reasons why I think that the Guild is gonna love my session or is gonna want to see it is because I propose a topic. The name is the Low Testing A Beginner's Quest for Practical Application. And the main idea on this is to show the people some real world cases that I had the option to leave or the challenge to leave with some of my teams. Nowadays after pandemic we realize how important is load test because everything it's online, everything is on the web and everything is on the Internet and applications. And I think now more than ever low test is really important or if it's not important yet for everybody, it's going to be. So the main idea on this presentation is to talk about not only concepts, about Lotus Fundamental and not only tools. Of course I'm going to mention and put the the relationship between both. But the main point in this presentation is to talk about how if you understand the fundamentals, how you will apply this so that you can get a better result, you can have a better analysis. And of course with your low test not only found in box but also given real value from your testing to your product. So as I said before, it's not about concepts and it's not about tools, but it's about application real cases, which monitoring you need to have in order to define your scenarios, which things you need to do before defining your Lotus and which kind of analysis you need to do after you're doing it. And when you can actually define something as accepted or not, or which kind of bugs or problems you can identify and you can report it so that's the main idea. I hope everything is clear and of course if you have any questions you can just reach out to me. Thank you very much. Bye bye.

Hey Joe, thank you for the opportunity to present on the Test Guild conference in case I will be selected and I want to quickly summarize what's going to be the topic of my presentation. So I want to make a comparison between Cypress and Playwright frameworks, but not in the context of the just comparison of the technical capabilities of both frameworks. I want to compare more the context of the framework's application so how the differences between Playwright and Cypress can drive the decision making for the company either to choose the Playwright framework or Cypress framework depends on the framework's pros and cons, advantages and disadvantages. And the second topic as a bonus topic that I want to present would be a concept of the user facing locators. I remember you listed the hot topics and one of them was how to handle the dynamic locators and how to make the tests more stable. So user facing locators concept is related to that. This concept was introduced by the Playwright first and I want to show how to use this concept and also I want to show how to use the similar concept in in Cypress in case someone use Cypress and want to follow the same pattern and follow the same approach how to use user visible elements in order to make the locators more stable. So that's pretty much it. This will be a topic of my presentation and I hope you guys gonna like it. Thank you.

Hi there, my name is Anne Ivan Asselt. My talk is about solving a universal pain point bug management and especially the frustrations of allocating the bugs to the right teams. That is why I'm excited to introduce Laku Caracha, the AI driven bug management solution born from a hackathon through GPT API. It automatically matches bug reports to the right teams and further streamlines the bug management process through the integration with Slack, Jira and Amplitude. Together we will explore this solution and how GitHub Copilot can help us during the development of it, learn actionable techniques for efficient bug management and get inspired to boost productivity through AI. See you at the event.

Hello everyone, my name is Agustin Pequeno. I'm currently working as QA Director on Merkle Denmark and I wanted to give this talk about this really cool library that I have been developed for the last year and a half called rubyradar. The idea behind rubyradar is to kick off your automation.

With an array of open source tools. So from the get go. We have a free solution that you can use for your own projects, for customer base project, for playing a little bit with automation, for learning a little bit all about it. And it's Ruby based because I pretty much love Ruby. I think it enhances my automation skills and it makes coding more fun, more accessible. So I really think that my talk will appeal to everybody who wants to get into automation or to everybody that is already into automation and want to try something different or maybe to that niche of Ruby automation testers that are out there and want to find alternative solutions. So that's pretty much my pitch. Thank you so much for your time. Have a lovely day. Bye bye.

Hi all, I'm going to talk about Art of BDD Scenario Writing when we started with Behavior Driven Development at Nimble Work, we initially read about it and discovered that it is so much to do with given when then scenarios. Eventually we started doing these scenarios collaboratively with the developer, tester and the product owner working together. It has been a long journey, evolved over a period of time, learned from lot of hardships and then we put down our own best practices and there's no looking back. What dawned on us is that the practice of BTD can assist in developing software that aligns with business goals.

And it's a great enabler of agility in today's rapidly changing technical landscape. So the goal of my session is is to elevate BDD practice, help teams shift from siloed automation initiatives to creating living documentation of applications behavior that aligns with business objective.

My name is Ashwini Lalit. I head Quality Engineering at Nimble Work and I enjoy training teams on BDD continuous improvement, continuous testing and bringing in the right balance between upstream and downstream quality.

Hello, my name is John Chesher and I am a Senior Software Engineer in Test or SETT for Aspire Software, a service titan company that specializes in producing software that fits the end to end needs of landscaping, snow plowing and janitorial companies. As the senior set, I have owned the process of building a test automation architecture from the ground up for our flagship product, Aspire Landscape. For those of you who regularly automate regression tests, I'll bet you've probably come across the following scenario multiple times throughout your career. You're creating automated tests for a portion of a legacy system and you write a new test that seems to expect what the software under test or Sutton should do, but you find that the test fails. So you go to the software engineer or SE and show him the code and find to your delight that he confirms it's a bug. So you write up a bug report from it and put it on the backlog. But then your bubble gets bursted when you find out that although it is a legitimate bug, it's not high priority to get fixed. Sound familiar? So what do you do with your brand new legitimate but failing test? Do you comment out the assert that failed? Do you leave the new test in an unmerged branch until it's fixed? Or do you go ahead and merge in a failing test? All of these strategies have serious problems. I think there's a better approach. Consider changing your new failing test into what I like to call a progression test. We all know what regression tests are, tests that tell when the SUT's functionality has regressed. But what about a test that points out when changes to the SUT have brought about progress? Here's how it works. You have test code that asserts what the SUT should do, and you also know what the SUT is doing now. So since this bad functionality is deemed acceptable for the time being, you write a little more code to expect that bad functionality and pass the test. As long as that assert checks out. You also provide a link to your bug report and then you tuck your legitimate asserts into another method that will never get called.

Until the set changes. Weeks or maybe months later, an SE will find some reason to change the way the set works, which will cause your assertion on the bad functionality to fail. As soon as it does, your progression test code will immediately run those legitimate asserts that you had tucked away to see if it has changed for the better. Whether those assertions pass or fail, the test as a whole will fail, thus immediately bringing your progression test to the SE's attention or right While she is thinking about the changes she just made and the failure notification will also give her information indicating whether her change was inadequate to solve the problem you uncovered, or if she just fixed the bug, perhaps in the process of fixing something else. If she was working on something else, the failure message will also point her to your bug report, which she can pick up and and add to the list of things she accomplished that day. I hope you will vote for me to speak at the Automation Guild Online Conference 2024 so I can tell you more about the benefits and potential pitfalls of converting your failing or commented out regression tests into live passing progression tests once again. I'm John Cheshire with Aspire Software. God Bless.

Hey Gil, I'm Swapnil Kothwal. I'm a lead engineer here in CellPoint Technologies. So basically I work on automation, building the automation framework and many other things.

My day to day job is mostly to deal with the CDCI pipeline. We also have diversification of our automation team like security performance and our regular automation thing. So I am currently leading the performance team and current today I'm planning to talk about more about observability there. So let's see how it is different from the traditional approaches. Okay, so for observability, this term is not very new in a SaaS world. Okay. But I'm trying to explain the open telemetry today. So what is that open telemetry and how it different from the other observability tools like Datadog, Prometheus, Grafana and things like that.

All right, we're recording. Robert Lukenbill from Scorpion llc. I'm actually in Kansas City. Our company's out of Valencia, California. The quick pitch for why you should why you'd want to hear what Scorpion is doing on quality assurance. It's really quick. We went from a very large manual QA operation down to just three automation engineers who run all of our quality assurance for our department. The change went in January of 2023. In 2022 we just had, we had around 1516 manual QAs. And the decision that we made in management to make the paradigm shift for our company was simply we're spending too many man hours on quality assurance and not receiving enough return on our investment. We were still rolling out a lot of bugs and we were putting out unfortunately a lot of expense in maintaining the application. So we made this paradigm shift in January and we changed the entire methodology of how we did qa. And using Cypress in that integration, it allowed us to open up so many more windows, save over 160 person hours a month, and it allowed us to lower our bug count significantly with automation. And I'd love to share with you and your companies on how we accomplish this.

Hi, I'm Rahul Parwal and at this year's Automation Build Conference I will talk about skyrocketing your test coverage using model based testing. Now, model based testing is a very interesting and fascinating test design approach which uses the power of models, that is your visual intelligence and mathematical graph computations to derive and generate test cases. In a moment. It supports generating tests for different coverage levels, from small sanity checks to different.

Cases, to even doing exhaustive testing with complete flow and path coverages. So how do you do that through model based testing? This session is about that. How do you use model based testing to generate test within a second and use those new tests to update your automation with the right impact analysis with the right direction where you have to execute and do major updations in your test. So this approach is going to talk about all these factors and there are much more practical examples that I will be covering in this talk. So stay tuned. Thank you. Bye.

Hello everyone, my name is Benjamin Bischoff and I think you will really enjoy this session because I will show you that the KARATE framework is much more than API testing. I will demonstrate how you can use it for your UI testing needs and why this could be a smart move in terms of onboarding and alignment of your tests. So it would be nice to see you all in this session.

Thank you all potential speakers for your automation awesomeness. For links to everything of value we covered in this episode, head over to test guild.com forward/a46e and while you're there, make sure to have your voice heard by voting by clicking on the vote button and voting on all your favorite sessions. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is help you succeed in creating end to end full stack automation awesomeness. As always, test everything and keep the good Cheers.