From the Pipeline v17.0

The following will be a regular feature where we share articles, podcasts, and webinars of interest from the web.

The Top 5 Considerations for Creating a Successful Cloud-Based Pipeline

The article posted by Even Glazer covers the top five considerations for creating and running an automated, cloud-based pipeline. He advises anyone looking to implement a pipeline to consider the constraints of your organization, particularly around data security policies. The top five considerations area: (1) Consider Your Business Needs First, (2) Develop Your Cloud-Based Pipeline as Part of Your Apps, (3) It’s All About Continuous Improvement, (4) Enable Self Service Features, and (5) Track Your Pipeline, Microservices and Compliance Policies.

Patterns of Distributed Systems

Another mammoth post that can be turned into a book chapter on Martin Fowler’s site. This time, guest author Unmesh Joshi takes us through a set of patterns he observed in mainstream open source distributed systems. Several of these patterns are works in progress but the article itself is well worth a read.

“Distributed systems provide a particular challenge to program. They often require us to have multiple copies of data, which need to keep synchronized. Yet we cannot rely on processing nodes working reliably, and network delays can easily lead to inconsistencies. Despite this, many organizations rely on a range of core distributed software handling data storage, messaging, system management, and compute capability. These systems face common problems which they solve with similar solutions. This article recognizes and develops these solutions as patterns, with which we can build up an understanding of how to better understand, communicate and teach distributed system design.”

Code Coverage Best Practices

Another great post from the Google Testing blog about code coverage. They openly question whether or not code coverage alone reduces defects and a high % of coverage being responsible for higher quality in test coverage. Chasing a specific number does not mean the application under test is of good quality. Instead, it’s important to use a risk-based approach to testing and ensuring that all deployments are gated by code coverage.

“We have spent several decades driving software testing initiatives in various very large software companies. One of the areas that we have consistently advocated for is the use of code coverage data to assess risk and identify gaps in testing. However, the value of code coverage is a highly debated subject with strong opinions, and a surprisingly polarizing topic. Every time code coverage is mentioned in any large group of people, seemingly endless arguments ensue. These tend to lead the conversation away from any productive progress, as people securely bunker in their respective camps. The purpose of this document is to give you tools to steer people on all ends of the spectrum to find common ground so that you can move forward and use coverage information pragmatically. We put forth best practices in the domain of code coverage to work effectively with code health.”

Searchiiiiiing, Seek And Locate…But Only With Appropriate Attributes for Automation

Another great post by everyone’s favorite metal-loving test automation architect Paul Grizzaffi. In his latest post, Paul discusses one of the big drawback of UI-based automation: attributes used for locating elements. Sometimes the only access we have to an application is via the UI, so we must interact with elements that can be typed into, pressed or click, and need their values to be inspected. Sometimes third-party tools (such as Salesforce or SiteCore or Oracle Cloud) have dynamically built elements that make attributes difficult to nail down. We can instead use “data” attributes to add arbitrary attributes to an HTML element to help automation developers locate elements and make UI-based automation a little less brittle.

WebDriverIO for Javascript Automation Testing

Joe Colantonio walks us through the various implementation of WebDriverIO for automation testing. WbDriverIO is a javascript-based testing tool that uses Selenium. People typically use WebDriverIO if they don’t want to build their own framework from scratch and they want some additional features not provided in vanilla Selenium. The article provides a list of these features along with several podcast interviews on the subject for those looking to learn more.

Series Navigation