Where can I listen to this podcast?

This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.

Does this podcast accept guests?

Yes, this podcast regularly features guests.

Automation Explanation

Claim This Podcast

by Antwan Maddox

8 episodes

Updated Daily

Accepts GuestsHas Sponsors

Podcast Overview

In AutomationExplanation, we dive into the meaning and the practicality of applying test automation on software projects. We dispel all myths, and go over optimum strategies, implementations, and the integration of test automation within software projects based on industry foresight and experiences. Our goal is to reeducate testers and shape IT company culture in supporting a healthy foundation that will yield the best ROI when implementing test automation.

Language

🇺🇲

Publishing Since

5/24/2022

Visit Website View on Apple Podcasts RSS Feed

3 verified contact emails on file for Automation Explanation

Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.

See contact details

Recent Episodes

October 26, 2022

The Scariest Automation Stories — With Antwan Maddox and Greg Burdick

September 21, 2022

API Testing: Pros and Cons — With Antwan Maddox and Greg Burdick

Welcome to another episode of Automation Explanation, an Agile Thought Podcast, where you will learn about quality through automated testing and its place in modern software development.   This week, your hosts, <a href= "https://www.linkedin.com/in/antwan-maddox-68b15ab/">Antwan Maddox</a> and <a href= "https://www.linkedin.com/in/gregburdick/">Greg Burdick</a> are exploring the topic of API testing, they are talking about its meaning and purpose, as well as about the benefits and challenges of using API Testing.   Key Takeaways <ul> <li style="font-weight: 400;" aria-level="1">What is API testing?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">API stands for Application Programming Interfaces; there is a collection of functions and procedures which allows communication with applications or libraries and increases the connection between two services.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">API's architecture:</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">There are three layers: the communication layer where the UI is, a business logic layer where components reside, and a storage data layer.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Why do we need API testing in the first place?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">API testing is there to ensure it is the best version of the product and that all functions are working as intended.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">The importance of REST protocol and alternatives in API Testing:</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">It is a common method that is used to build API.</li> <li style="font-weight: 400;" aria-level="2">REST enables users to connect to, manage and interact with cloud services freely in a distributed environment.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What are some of the myths related to API testing?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">"Only UI testing counts." The UI is going to change most of the time with the business requirements, which are going to help in building the app. UI testing only does exactly what you tell it to do.</li> <li style="font-weight: 400;" aria-level="2">"API validations are irrelevant if GUI Testing is not." GUI Testing does not cover all aspects of API; you might not be testing the business logic, all you do is test navigational aspects.</li> <li style="font-weight: 400;" aria-level="2">"It is simpler to use GUI Testers than API." With GUI you are not going to test the interconnection points through the UI</li> <li style="font-weight: 400;" aria-level="2">"If a testing API has not changed, the app will continue to function the same exact way." This is false; an application changes and evolves with time. API has to be revalidated, continuously testing for API integrity, and ensuring its best function.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Benefits of using API testing:</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">It is faster and more scalable than UI testing</li> <li style="font-weight: 400;" aria-level="2">API testing is generally less complex and less fragile than UI testing.</li> <li style="font-weight: 400;" aria-level="2">API isolates business logic from display logic.</li> <li style="font-weight: 400;" aria-level="2">API testing allows security testing that is not covered by security scans.</li> <li style="font-weight: 400;" aria-level="2">API infrastructure is generally more stable and that is why those tests require less maintenance.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What are the challenges of API testing?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">One challenge is to try to chain or sequence a series of API calls to achieve fully integrated testing.</li> <li style="font-weight: 400;" aria-level="2">Another challenge is the validation of parameters. Changes in applications can cause failures.</li> <li style="font-weight: 400;" aria-level="2">Three reasons why API testing might fail:</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="3">The test itself and how it was designed,</li> <li style="font-weight: 400;" aria-level="3">True application failures, and</li> <li style="font-weight: 400;" aria-level="3">Communication failure</li> </ul> </li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Benefits of Contract Testing.</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Contract testing is a quick, lightweight form of API testing that verifies the content and format of API requests and replies. Complete API contract testing has to validate both the API producer (server side) and the API consumer (client side) to detect and diagnose when a contract is violated by either side.</li> </ul> </li> </ul>   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on <a href= "https://agilethought.com/category/podcast/">AgileThought.com</a>! Email your thoughts or suggestions to <a href= "mailto:Podcast@AgileThought.com">Podcast@AgileThought.com</a> or Tweet <a href= "https://twitter.com/agilethought?lang=en">@AgileThought</a> using <a href= "https://twitter.com/search?f=tweets&q=%23agilethoughtpodcast&src=typd"> #AgileThoughtPodcast</a>!

August 23, 2022

Using and Managing Automation Like a Boss — With Antwan Maddox and Greg Burdick

Welcome to another episode of Automation Explanation, an Agile Thought Podcast, where you will learn about quality through automated testing and its place in modern software development.   This week, your hosts, <a href= "https://www.linkedin.com/in/antwan-maddox-68b15ab/">Antwan Maddox</a> and <a href= "https://www.linkedin.com/in/gregburdick/">Greg Burdick</a> are accompanied by <a href= "https://www.linkedin.com/in/john-gravitte-5417a91/">John Gravitte</a> to today's episode, John is the former Senior Director of Validation and current Market Unit Technology Head at Agile Thought.   Key Takeaways <ul> <li style="font-weight: 400;" aria-level="1">If there is one myth about automation as it relates to quality: What would it be?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Quality is not just executing test cases, it is a Team activity, and everyone is responsible for quality.</li> <li style="font-weight: 400;" aria-level="2">Not all test cases are good candidates for automation.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What is one of the biggest banned from the book actions that an organization can take to prove the quality stands?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Including the quality professionals from the start. Get them involved in creating the stories and looking through the acceptance criteria.</li> <li style="font-weight: 400;" aria-level="2">Include quality professionals in every meeting and let them decide if a meeting is valuable for them to attend or not.</li> <li style="font-weight: 400;" aria-level="2">The more involvement the quality professionals have the more they will understand how to test it.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What makes quality testing so challenging?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Nothing stays the same, data changes, tables change, and even the database configuration changes, that is why achieving quality is very challenging.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Why is quality important? Do organizations and clients understand why they want quality?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Quality is reputation. A bad experience using the product can negatively affect the client's reputation.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What is one thing related to quality and automation that John has learned the hard way?.</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">In regard to quality, never cut corners (you will pay the consequences). Always document your findings, so you can prove what you have done.</li> <li style="font-weight: 400;" aria-level="2">Don't be so quick to purchase a new automated tool without doing the research about the skill set that is present in the quality assurance group. Get to know the big picture first.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Managing risk and quality when quality is one of the first things to get disregarded.</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Documenting assumptions at the beginning is important, when you see risk, document where you saw it, and explain to the client or boss what the consequences could be for a certain decision. Keep the focus on the outcome.</li> <li style="font-weight: 400;" aria-level="2">Have Plan A and Plan B.</li> <li style="font-weight: 400;" aria-level="2">Collaborate with the Team and listen to others' ideas, you don't have to do it all on your own.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What do non-technical people need to know about quality and automation testing?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">First, they need to know that it is not one person's responsibility, it is an entire Team's effort.</li> <li style="font-weight: 400;" aria-level="2">You need to be available to answer questions.</li> <li style="font-weight: 400;" aria-level="2">Test engineers need to understand the core workflow. You need to run test automation every day to ensure quality.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What do test automation engineers need to understand about business and business people?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">You need to meet the business people to really understand the core workflow and to get to know more about the application and how is it being used. This will help you to automate the right test cases.</li> <li style="font-weight: 400;" aria-level="2">Showcase the automation, run it for the client, and let them see it, a lot of business people don't know how it functions.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Best practices to educate the client.</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Have a client engagement kickoff to explain the process including how the quality is managed.</li> <li style="font-weight: 400;" aria-level="2">Have a quality playbook to educate the customer, and even have two, one for manual testing and the other for automation. That playbook must include roles and responsibilities, so the client can understand terms and who does what.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What is a demand trend for quality in Automation testing and why?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">A lot of companies want to do test automation because their test bed is so large.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">Does DevOps even exist without automation? How tied are those practices together?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">DevOps and automation are intimately connected to get some automation in the pipeline and the processes of deployments.</li> <li style="font-weight: 400;" aria-level="2">In reality, DevOps are still part of automation, but it can happen without test automation, in depends on the approach.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What does it take to sustain the Quality effort?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">A repeatable process is needed in order to maintain Quality effort.</li> <li style="font-weight: 400;" aria-level="2">Keep the right mindset and tools, but overall keep constant communication, transparency is essential.</li> </ul> </li> <li style="font-weight: 400;" aria-level="1">What does it take to thrive as a Test Automation Engineer?</li> <li style="list-style: none; display: inline"> <ul> <li style="font-weight: 400;" aria-level="2">Constant education. Never stop self-educating, never stay with only one tool.</li> <li style="font-weight: 400;" aria-level="2">A Test Automation Engineer needs to have an understanding of the application architecture that is being built, its layers, and which are optimum for automation.</li> </ul> </li> </ul>     Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on <a href= "https://agilethought.com/category/podcast/">AgileThought.com</a>! Email your thoughts or suggestions to <a href= "mailto:Podcast@AgileThought.com">Podcast@AgileThought.com</a> or Tweet <a href= "https://twitter.com/agilethought?lang=en">@AgileThought</a> using <a href= "https://twitter.com/search?f=tweets&q=%23agilethoughtpodcast&src=typd"> #AgileThoughtPodcast</a>!

8 total episodes available

Deep-dive analytics for Automation Explanation

Frequently asked questions

Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.

What is Automation Explanation?: In AutomationExplanation, we dive into the meaning and the practicality of applying test automation on software projects. We dispel all myths, and go over optimum strategies, implementations, and the integration of test automation within software projects based on industry foresight and experiences. Our goal is to reeducate testers and shape IT company culture in supporting a healthy foundation that will yield the best ROI when implementing test automation.
How often does this podcast release new episodes?: This podcast updates daily.
Where can I listen to this podcast?: This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
Does this podcast accept guests?: Yes, this podcast regularly features guests.

Legal Disclaimer

Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.

All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.

We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.

While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.

By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.