Avsnitt
-
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, Antwan Maddox and Greg Burdick are celebrating Halloween with the audience by sharing the scariest automation stories.
Key Takeaways
Dealing with the organization's expectations about the developers’ role Some organizations expect the development Team to test the changes and provide feedback before the changes move forward to production, But it is not the best practice for developers to test their own code, developers in fact need to think outside of the box. Developers realize general observations in order to detect errors and asses risk. Quality analysts are providing the scenarios but not testing them. .Whose job is quality? Is it the quality engineer’s, the quality analysts’, or is it the responsibility of the entire Team to ensure quality? The entire Team is responsible for sharing their observations over the project. When a Team closes a specific sprint, that outcome is the result of the effort of an entire Team. Everyone worked together to provide support to the customer and to follow the correct procedures in order to do so. There is a bias towards functionality over vulnerability. You don’t want to rush functionality, it can exhaust the Team. It is important to figure out the reason why the Team is not delivering effectively or timely. What are the effects of not following best practices? Manual testers are crucially important. Documenting is extremely valuable and will be used for several purposes. You need to know what and how to document, following a Team agreement. In order to pass an audit, documentation is vital! The Automation Team needs to provide the value of their role to the customer for them to see how they are getting the return of their investment. Don’t hesitate to share your work with the customer, that is the way for the automation Team to show its value to the customer. Automation can become invisible unless you are actively telling the story..
.
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
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, Antwan Maddox and Greg Burdick 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
What is API testing? 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. API’s architecture: There are three layers: the communication layer where the UI is, a business logic layer where components reside, and a storage data layer. Why do we need API testing in the first place? API testing is there to ensure it is the best version of the product and that all functions are working as intended. The importance of REST protocol and alternatives in API Testing: It is a common method that is used to build API. REST enables users to connect to, manage and interact with cloud services freely in a distributed environment. What are some of the myths related to API testing? “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. “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. “It is simpler to use GUI Testers than API.” With GUI you are not going to test the interconnection points through the UI “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. Benefits of using API testing: It is faster and more scalable than UI testing API testing is generally less complex and less fragile than UI testing. API isolates business logic from display logic. API testing allows security testing that is not covered by security scans. API infrastructure is generally more stable and that is why those tests require less maintenance. What are the challenges of API testing? One challenge is to try to chain or sequence a series of API calls to achieve fully integrated testing. Another challenge is the validation of parameters. Changes in applications can cause failures. Three reasons why API testing might fail: The test itself and how it was designed, True application failures, and Communication failure Benefits of Contract Testing. 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.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
Saknas det avsnitt?
-
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, Antwan Maddox and Greg Burdick are accompanied by John Gravitte to today's episode, John is the former Senior Director of Validation and current Market Unit Technology Head at Agile Thought.
Key Takeaways
If there is one myth about automation as it relates to quality: What would it be? Quality is not just executing test cases, it is a Team activity, and everyone is responsible for quality. Not all test cases are good candidates for automation. What is one of the biggest banned from the book actions that an organization can take to prove the quality stands? Including the quality professionals from the start. Get them involved in creating the stories and looking through the acceptance criteria. Include quality professionals in every meeting and let them decide if a meeting is valuable for them to attend or not. The more involvement the quality professionals have the more they will understand how to test it. What makes quality testing so challenging? Nothing stays the same, data changes, tables change, and even the database configuration changes, that is why achieving quality is very challenging. Why is quality important? Do organizations and clients understand why they want quality? Quality is reputation. A bad experience using the product can negatively affect the client’s reputation. What is one thing related to quality and automation that John has learned the hard way?. In regard to quality, never cut corners (you will pay the consequences). Always document your findings, so you can prove what you have done. 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. Managing risk and quality when quality is one of the first things to get disregarded. 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. Have Plan A and Plan B. Collaborate with the Team and listen to others’ ideas, you don’t have to do it all on your own. What do non-technical people need to know about quality and automation testing? First, they need to know that it is not one person's responsibility, it is an entire Team’s effort. You need to be available to answer questions. Test engineers need to understand the core workflow. You need to run test automation every day to ensure quality. What do test automation engineers need to understand about business and business people? 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. Showcase the automation, run it for the client, and let them see it, a lot of business people don’t know how it functions. Best practices to educate the client. Have a client engagement kickoff to explain the process including how the quality is managed. 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. What is a demand trend for quality in Automation testing and why? A lot of companies want to do test automation because their test bed is so large. Does DevOps even exist without automation? How tied are those practices together? DevOps and automation are intimately connected to get some automation in the pipeline and the processes of deployments. In reality, DevOps are still part of automation, but it can happen without test automation, in depends on the approach. What does it take to sustain the Quality effort? A repeatable process is needed in order to maintain Quality effort. Keep the right mindset and tools, but overall keep constant communication, transparency is essential. What does it take to thrive as a Test Automation Engineer? Constant education. Never stop self-educating, never stay with only one tool. 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.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
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, Antwan Maddox and Greg Burdick are talking about the big debate: commercial vs. open-source automation tools. Antwan and Greg explore every aspect of the important decision regarding choosing an automation tool. Listen to this episode to know the pros and cons of both open-source and commercial automation tools, and remember, automation is an art and it is never obvious which is the right tool for you.
Key Takeaways
A brief history of the debate between commercial vs open-source automation tools. In the ’90s, solutions started to be packed to get over the market to tackle the texting complexity of web apps or servers. The enthusiasm for improvements in automation continued throughout the years. Low-end and inexpensive web products appeared but later became more costly. Commercial tools and open source automation tools started to compete. The shift was caused by different development practices. What about using a “mixed bag” of different tools for Development, Agile, and tracking? Whatever tools that you are using have to match or atleast support the application style; they have to integrate with the current development tooling. What does it mean, this debate about commercial vs. open-source automation tools? Open-source automation tools can be downloaded and just used. Commercial tools are usually paid for and are developed in-house by a vendor. The testing challenges. Today testing runs by a continuous-delivery model. Wanting to test more frequently introduces complexity as well as trying to give shorter feedback loops. Fast maintainability and the creation of scripts are also challenges. Achieving greater coverage is another challenge. Pros and cons of commercial and open-source automation tools. The pros of open-source automation tools are: Open-source tools are mostly free and are specifically code-based (requiring intimate knowledge of coding and development). They are easy to integrate and easy to use. There is no vendor locking. These open-source tools are constantly being enhanced. The cons of the open-source tools are: Some have a hidden cost. Lack of support. There are threats to safety and security. You need to know about code and programming to be able to use them. The pros of commercial automation tools are: They are codeless. They have embedded frameworks involved. They usually have more liability as a result of the time they have been on the market. No threats to safety and security. The cons of commercial automation tools are: There might be a vendor lock-in. They can be expensive. Picking a tool must depend on your needs and business goals. Make sure the tool meets the skills of your team and the current development text app. You need to know how long this tool has been used, and if it has been enhanced. Automation is not obvious; picking the right tool at the right time has to follow a lot of considerations. How to choose an automation tool: The budget should not be the main aspect to consider. Be ethical. Keep in mind that open-source tools are not necessarily less valuable than commercial tools. Get what you paid for! While choosing an automation tool try to maintain your situational awareness. Remember that you never want the tool to drive your strategy, the strategy needs to be upfront. Collaboration is key to choosing the right automation tool.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
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, Antwan Maddox and Greg Burdick, are exploring the myths in regard to the role of Test Automation Engineers. Nowadays, there is more collaboration than ever before in the automation arena and most is happening remotely; the challenge is to provide a high-quality customer experience. People are investing a lot in automation, but it is very unlikely that they are actually succeeding in it, resulting in the failure of most automation processes, and the root cause often begins with wrong perceptions about the engineering role. Today, Antwan and Greg do their part to stop perpetuating these Automation myths.
Key Takeaways
Automation Engineers/QE/SDET are not magicians. The origins of the magician myth: No Automation Engineer can take care of everything, meaning the automation performance, low testing, data validation, and mobile testing. There is no single person who has the breadth and the experience to the depth to be able to succeed in all these areas. Myth: Automation will solve all your problems. Automation cannot replace manual testing or solve communication bottlenecks as well as other problems that are related to the overall organization. Myth: Let’s automate 100% of the test cases. Why do you have manual testers in the first place? What is the intention behind using commercial tools? If the intention is to put a bandage around the lack of mature collaboration among the Teams utilizing Automation, it is wrong. Automation is better suited for Agile Development Teams that understand the mature process of leveraging automation. There often isn’t a proper ratio between Developers and Automation Engineers. Without an appropriate scale, you can’t expect positive results. Myth: Automation will eradicate all bugs and defects. Test Automation encourages repeatable testing and it happens to find bugs, but this is not the central point of Test Automation. Why do these myths even persist? Organizations look for an Automation Superhero as a result of Agile immaturity which is still a challenge for many organizations. The inertia of dysfunction and resistance to change are two of the reasons why these myths persist. The perception that testers are cheap also contributes to these myths remaining. Some organizations expect Automation Engineers to accommodate their dysfunction and not challenge it. Lack of education in regard to Test Automation motivates these myths to stick. Antwan talks about the criteria for continuing testing maturity which fall into five categories: They do not have enough foundation to support the appropriate level for continuing assessment. Testing is an afterthought but test automation is at the forefront (which is so unbalanced from the Development Teams perspective!). There is nothing on the frontend that supports automation. There is little to nothing on the backend that supports animation. Do they even know what the Automation Team needs are? The movement toward change is scary and delays progress. What can we do to move forward? Empathy among Teams in providing what is necessary; empathy can be a game-changer! Understanding the architecture around the application. Assessing your level of maturity as a Team and as an organization towards Automation. You can have better quality with fewer tests. Setting up the environment for collaboration. Antwan shares some real cases to exemplify how to tackle these myths in organizations.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
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, Antwan Maddox and Greg Burdick are discussing Quality and who is responsible for it. They start by addressing the origins of Quality Assurance and dive deep into the differences between Quality Assurance and Quality Control. Antwan and Greg share valuable analogies for a better grasp of the meaning and extent of Quality Assurance as well as they speak of the most common mistakes in this field and how to prevent them.
Key Takeaways
The origins of Quality assurance. The notion of ensuring quality starts before the Industrial Revolution. Before the free market, vendors could just sell anything, usually involving cutting corners in order to cut costs. In the early years of the software age, in order to release what was considered good software at that time, different attributes were involved: Ease of installation, configuration, and friendliness. They believe if certain standards were followed there was no need for quality insurance. In the 90s and early 2000s, there was a shift in customer perception in terms of change management, how quickly consumers can make updates, and efficiency in distributing new versions of software through the internet. How significant is it to be good at Quality Assurance in software development? The role of Quality is amazing and it will continue to grow. The organization overall is responsible for quality. Quality Assurance vs. Quality Control: Quality assurance is making sure that the appropriate processes and procedures are there to enable a product or service to meet some level of quality, involving outputs and inputs. Quality Control is about ensuring that you are meeting the already agreed Quality standards and one way of doing it is by testing. Everyone within the environment is responsible for making sure all the elements and processes are been followed to deliver a successful outcome in providing a product that can be consumed. Externalities: The days of externalizing tasks are rapidly coming to a close. Businesses are becoming more development-centered. Quality is not easy: The most common mistakes and how to avoid them. Developers don’t need to test their own code; after that everyone is responsible for assuring Quality Agile is truly Team-based, that is why you cannot blame a single part of the Team for Quality problems. The process of continuous improvement involves supporting the QA Team. When Quality hasn’t been measured appropriately, the only measure is the number of bugs and defects. A Development Team has to have clear and measurable KPAs to help Teams improve every single Sprint. Test Automation is not part of the Development goals. Reactive Programming: Reactive programming is making sure that things are being taken care of at the moment of development. Messaging is important, things have to be logged appropriately. More mature development Teams around the world are starting to employ subsets of reacting programming to make sure they are enhancing value at the development stage. Quality Management. Quality is not the manual tester’s responsibility only, total quality involves everyone’s hands on it. Quality management not only saves costs but also captures opportunities for incremental improvement.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
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, Antwan Maddox and Greg Burdick are talking about the crucial value of Automation Strategy; they dive deep into its history and origins, as well as explain its role in regard to Testing and the significance of the whole Development Team to be included in the process. Antwan and Greg also discuss the types of Testing approaches that are used to leverage Automation and the patterns to avoid.
Key Takeaways
Test Automation Engineers or Quality Automation Engineers? In order to be in alignment with ISTQB® Certification, the formerly called Quality Automation Engineers are now referred to as Test Automation Engineers. It’s a unification of terminology. Why is Automation Strategy important? “If you fail to plan, you are planning to fail.” Benjamin Franklin A plan of execution is needed to assure effectiveness and efficiency. The history of Automation Strategy, where does it come from? It comes from experience in the past. As Automation progressed, some of the technology around Automation had to change. The Automation Strategy is owned by the entire Development Team. What is the significance of Quality? Lowering the anxiety and the stress around deployment. Automation Strategy explained: The Automation Strategy defines the who, what, when, where, and how of Test Automation. It is a plan that is agreed upon and understood by the entire Development Team for creating and maintaining Automation Test to help ensure higher ROI, increase coverage and availability, and faster time to market, in a way that is repeatable. Collaboration and response to change are two key pillars of Agile that sustain the Automation Strategy. Automation was not designed to catch bugs; it happens to catch them since it is set in a repeatable path. What should be included in Automation Strategy? First, you need to understand your why, what is your goal? That will help you establish the technique, the tools, and the process in building Automation, and the technology that is going to be used to support those goals, as well as help you determine who are the members that need to be on the Team to support that Automation. It will help you define what additional technologies are going to be needed and the environments you are planning to run against. What types of testing approaches are used to leverage Automation? The Shifting Left approach is a great way to Test Application components. Test Automation solutions need to be embedded in the application. It is a way of preventing risk quickly. Model-Based Testing. Contract Testing. The Team is in alignment with the continuous Test Maturity Model, it is a whole Team approach. Models for success: Which organizations are modeling the right way of doing Automation Tests for success? Google understands Automation. It is only possible when the whole organization has been educated on Automation, they are all supportive, and know their roles in regard to Automation. Agile does not mean to move fast, that is why Quality is important. Patterns to avoid. It is hard to bridge Manual Testing and Automation; a really mature Team approach is needed. Quality Engineers must focus over the long haul on prevention of production-based risk; features that are being delivered must be tested to make sure they work.Mentioned in this episode:
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
-
Welcome to the inaugural 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, Antwan Maddox and Greg Burdick are starting this series of shows to discuss some of the challenges and areas of improvement related to quality engineering. Today, they are diving deep into the history and role of Quality Engineers, their place in Development Teams, and how they fit into Agile.
Key Takeaways
A brief history of test automation. Test automation has existed for more than two decades. At the beginning of automation, users reached a point where the time to do automation outweighed the benefits. There were also some environmental issues, where some development environments were incompatible when running Scripts. The next generation of automation tools replaced the previous generation. What is a quality engineer? What are their responsibilities? The acceptance of Agile methodology has played a role in changing the role of a tester. A Quality Engineer is someone with a strong foundation in manual testing and test framework development Are clients looking for quality engineers? There is a big need for Quality Engineers currently in the market even though there is always going to be a need for a manual tester. Modern DevOps plays a big factor, emphasizing continuous innovation and delivery, leading to more frequent integration of code and deployments to the production environment. What should a Quality Engineer focus on learning more about DevOps or Agile? First, a Quality Engineer has to learn a programming language. Second, he needs to learn how to automate the front end. Third, a Quality Engineer needs to have more intimate knowledge of the back end. Stage four is about DevOps automation, and every Quality Engineer should know about it. How do Quality Engineers fit in Agile? Quality Engineers fit into the Development Team very intimately and they are part of the cycle from the beginning to the end. Quality engineers are key to creating testable and automatable software. They need to know about the application roadmap. Quality engineers have to be included in the software development process. Everyone should be involved in automation. The organization needs to be ready for automation. To deliver an application is not just delivering a bunch of features, it is also delivering a testable and automatable code, quality is a must when delivering software. What is Quality Engineering about? Quality Engineering is not about velocity or defects, it is about how software is put together and organized for the development effort. A Quality engineer assures that there will be a low stress and anxiety deployment. A Quality Engineer is constantly growing and learning. Quality engineers should be hired in pairs.Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
