devopsy.kinsta.cloud

Tag: automation

  • Why You Must Lead With AI

    Why You Must Lead With AI

    AI will soon be a necessary part of doing business. Every company will have an AI strategy in the same way that they have a social media strategy, branding strategy, talent strategy, etc.

    So if you want to stand out from the competition and gain an edge, you can’t just use AI; you must lead with AI.

    What does that look like?

    To lead with AI, you can’t simply set up a small innovation team to solve point problems. You must embed AI throughout the organization, such that every team is taking advantage of the technology and incorporating it into their operations.

    The specifics will vary from company to company, but there are some general strategies that will help you begin leading with AI.

    Be Persistent

    Leading with AI doesn’t just happen in the blink of an eye. It’s going to take time and hard work, and it’s critical you stay persistent.

    Amazon, a leader in machine learning technology applications, didn’t start out using advanced AI techniques on day one. Just like everyone else, they had to go on a journey filled with discovery, successes—and the occasional course correction. For example, in 2017, Amazon launched a TV ad that accidentally triggered Alexa devices in its customers’ homes to purchase an expensive dollhouse. Not ideal, and not the best advertisement for the convenience of their machine learning devices.

    They stuck with progress, though, and learned from their mistakes. They were persistent, even though they started out behind the pack. Their focus on incremental progress meant that it only took five short years for Alexa to beat out Siri and Google Assistant in the smart home speaker market. Alexa may have had a slow start, but now she’s a very strong player in the market.

    Persistence and determination are the ingredients that build leaders in AI—not perfection from the start.

    Train Your Leaders to Look for AI Solutions

    Before a business can lead with AI, it has to identify problems AI can solve. You can’t accomplish this by building an AI tiger team and turning them loose to hunt through each department for inefficiencies. That AI team wouldn’t have the necessary context, and all its time would be spent coming up to speed on the operations of the various departments.

    Each division or department is familiar with its own operations and has the context to identify the most important problems. What they might lack is an understanding of AI and the types of problems it can solve. Giving them that training is the first step.

    Organizations that do this successfully start with the belief that every department can use AI to solve some of its problems and work toward enabling their leaders to identify and solve those use cases. For example, a CFO, who is presumably good at what they do, probably doesn’t have any experience in AI—their expertise lies in finance. That CFO will need training to develop an AI-aware mindset, the ability to identify the places within the finance department where AI can solve problems.

    Obviously, your leaders don’t need to understand everything about AI; they just need to know enough to be able to identify when AI is a good solution.

    Create Cross-Functional Teams

    When you think of AI, your mind might jump to data scientists, but there’s a lot at play in an AI model. It’s a marriage of technology and business, which means you need cross-functional teams to develop the best solutions. Because of this, the organization as a whole must become highly effective at multidisciplinary communication and collaboration.

    At its simplest, this might involve rolling out something like Slack to improve communication across departments. Some companies might adopt Agile processes and workflows to encourage collaborative planning of requirements, or they might institute regular all-hands meetings to sync up business priorities all at once and provide transparency.

    The details will be different for every organization, but every company will have a need for departments to collaborate more than before to identify common problems, prepare and share data, and develop related models. In some cases, this may be best served by restructuring the organization and reporting lines; in others, a department that expects an extensive adoption of AI—marketing, for example—may need to establish its own data science team.

    This degree of change may seem overwhelming. It’s important, however, for organizations to avoid the short-term solution of creating an AI team that’s shared across the company, or that team will end up being the primary bottleneck blocking AI adoption.

    Budget and Allocate Resources

    Nothing happens in a company without a budget and allocated resources. Finding the budget to implement AI solutions—to buy off-the-shelf products, hire people with the needed skills, spend time and resources annotating data—is critical, but challenging, especially because a good portion of the investment in AI has to be made company-wide up front.

    Leading with AI can necessitate reallocation of significant money and people, both of which are, in most cases, already budgeted out to normal operations. Deciding how much to reallocate and from where will impact the entire organization.

    Cutting costs is always unpopular, but you must look at it as an investment. Take, for example, a company eager to invest in AI that runs a call center to capture support calls, return requests and complaints. There’s no magical pool of money sitting around to invest in AI to improve this call center.

    Instead, the company will have to take money out of the yearly budget to spend on the AI initiative and just accept that the time to handle a call will go up for a period because fewer agents are deployed to receive those calls. The promise, of course, is that the investment in AI will lead to a chatbot that can divert 15% of those incoming calls, requiring fewer agents to handle calls and improving the call-handling time overall.

    Clearly articulating the long-term gains of AI will make it easier to secure buy-in across the company, so that the needed resources will be allocated.

    Leading With AI

    Leading with AI is hard. It will take time and massive investment. It’s never easy to switch up the operation of huge chunks of a business, reorganize reporting structures and refocus priorities; it will almost certainly require killing some sacred cows.
    Amazon, for example, spent years and a lot of investment to make the transition to leading with AI. Now, on the other side, they’ve maintained their status as a leader in their industry, with the infrastructure and culture that enables them to implement new AI solutions throughout their businesses as opportunities and problems arise.

    With persistence, AI-aware leaders, cross-functional teams and the right budget and resources, you, too, can begin leading with AI, ensuring a future competitive advantage.

    Co-author Wilson Pang is CTO at Appen.

  • Survey Illuminates Long Dark Road to Hybrid Cloud

    Survey Illuminates Long Dark Road to Hybrid Cloud

    While hybrid cloud computing will play a critical role in enabling digital business transformation it turns out most IT organizations lack the skills and technologies required to achieve it.

    A survey of 108 IT executives conducted by the research firm Pulse on behalf of CloudBolt Software, a provider of a cloud management platform, finds 94% believe hybrid cloud computing will be critical to digital transformation. A total of 92% also noted that empowering end users through self-service IT is a digital transformation accelerator, while 99% said successful automation depends on streamlining integrations.

    However, 78% of respondents said they lack the visibility necessary to optimize cloud deployments. More than half (56%) believe that their self-service offerings fail to meet user needs and more than three-quarters (76%) still rely on some form of custom coding when it comes to integration.

    In terms of the capabilities respondents are looking to acquire, 80% noted they want real-time insight into cost optimization and security remediation. A total of 71% want self-service to be easy for end users, while 62% want an approach to integration that doesn’t require deep domain knowledge or special expertise.

    CloudBolt CEO Jeff Kukowski said the biggest immediate obstacle when it comes to hybrid cloud computing is the lack of visibility IT organizations have into their existing IT environments. IT teams are not going to be able to unify the management of distributed IT environments without it, much less achieve anything approach observability, noted Kukowski.

    Pressure on IT organizations to accelerate application development while simultaneously reducing costs rose as the economic downturn brought on by the COVID-19 pandemic began. The challenge is that each new platform adopted by an organization tends to increase the total cost of IT as organization acquire tools and hire specialists to manage those platforms. It’s not likely all those platforms will be managed via a single console, but Kukowski said it’s clear IT organizations are moving toward a more federated approach that will enable them to centralize the management of IT.

    In the meantime, Kukowski noted organization are collectively wasting billions of dollars on IT platforms that are employed inefficiently. Most of that waste stems from either overprovisioning of IT infrastructure, or simply because someone didn’t think to turn off a virtual machine left running on a cloud service.

    It may be a while before IT organizations are able to strike that perfect balance between flexibility and control that currently remains elusive. However, organizations that focus on improving a few small things today will find themselves in a much better position to manage what is rapidly becoming an over extended enterprise tomorrow. Right now, Kukowski estimated only about a quarter of IT organizations have the sophistication required to manage a hybrid cloud computing environment.

    There’s no doubt the management of IT will become more automated in the months and years ahead. The challenge organizations face today is determining what tasks either can or soon will be automated. Once that’s determined, it becomes a lot easier to identify what DevOps skills those IT teams will require tomorrow.

  • Using RPA for DevOps Process Automation

    Using RPA for DevOps Process Automation

    Modern operations teams today are at the cutting edge of automation. DevOps and SRE practices are entirely based on an automation-first philosophy. CI/CD is fully automated and the next generation of automated testing is now being adopted.

    However, these same teams are still running their human processes based on hastily thrown-together wiki pages. The increase in remote work over the last year has amplified the problem. Engineering teams that were used to quickly getting the right people physically into a war room now struggle to find the people with the right knowledge to troubleshoot or resolve a problem.

    Teams with ample resources have built tools and bots for DevOps process automation and orchestration. These tools can help automate things like getting communications channels set up quickly, with the right people, the moment an incident is identified. Or, they may automate actions across the DevOps toolchain that would otherwise live as static documentation for an on-call engineer to try to decipher and execute. But only a handful of organizations have the resources to build this kind of automation technology in-house.

    These higher-level DevOps processes are ripe for innovation similar to robotic process automation (RPA). Companies like UiPath and Automation Anywhere have shown that there’s an enormous market for this in every business unit and industry. Process automation for DevOps needs to be another layer of automation available to any engineering team. Automated remediation of incidents and resolution of service desk tickets has to be the future of this space. However, there are important differences in how automation is optimized for DevOps versus the application of RPA for business functions.

    Where RPA Fits on the Automation Spectrum

    RPA is great for solving deterministic problems – those that can be resolved in the same way every time you run into them – which are fully automatable. An example of this type of end-to-end automation is any back-office task, which are consistently good candidates for the application of automation. It’s the reason why fields like HR and finance have made some of the greatest progress in automating business processes to date. Every time you close the books, for example, the steps are pretty similar.

    Process automation for DevOps and SRE, however, is on the other end of the spectrum. Although teams may benefit from RPA for simplistic, repeatable tasks, many DevOps processes are dynamic and unpredictable, making full end-to-end automation too often fallible. The complexity of modern technology stacks and infrastructure requires processes to be agile and adaptable to change, rather than deterministic. This is where it’s important to enable humans to step into the spectrum of automation. Human-in-the-loop automation – the idea that lets humans be in the cockpit while letting machines provide guidance and support – is the future of DevOps automation.

    Applying Process Automation to DevOps

    To use automation in a meaningful way, DevOps teams need a mix of what RPA provides with the added element of human judgment. Human-in-the-loop automation can be applied to numerous DevOps processes including incident management, service requests and continuous deployment and delivery.

    Rather than automating from end-to-end right from the start, DevOps teams should use incremental automation to strengthen and build trust in automation. This starts by codifying free-form processes so teams can more easily identify predictable steps that can be automated. Then teams can mature to more complex workflows, automating pieces within processes and incorporating human checkpoints for areas that will need judgment or approvals.

    As teams incrementally automate, they build up sustainability – in their systems and their roles – in high-stress environments and are able to orchestrate processes across the continuum. The goal is to find the right balance between leveraging machines to make lives easier while creating room for human judgment and adaptability.

    Level-Up DevOps Automation

    Looking ahead to the next few years, what the RPA movement did for back office tasks will also happen for DevOps and SRE. Technology leaders can take notes from the RPA movement and apply them to eliminating the toil of modern production operations. The issue is that, in DevOps, many problems are unique.

    The next evolution of DevOps automation will force us to look at how we can model the real world in a more holistic way, which includes incorporating human judgement and manual execution of non-repeatable tasks while automating repetitive steps.

  • Red Hat Extends Reach and Scope of Insights Analytics Service

    Red Hat Extends Reach and Scope of Insights Analytics Service

    During its online Red Hat Summit event, Red Hat today announced it has extended the Red Hat Insights predictive analytics cloud platform for managing IT to now include support for editions of Red Hat OpenShift based on Kubernetes and the Red Hat Ansible Automation Platform.

    In addition, Red Hat has extended Red Hat Insights for Red Hat Enterprise Linux (RHEL) to include the ability to prioritize security alerts, streamline notifications and track Red Hat subscription consumption.

    In total, since launching Red Hat Insights in 2019, Red Hat claims there are now more than 600,000 RHEL hosts analyzed per day.

    Joe Fitzgerald, vice president and general manager for the management business unit at Red Hat, said Red Hat Insights provides IT teams with the equivalent of a co-pilot for managing IT environments. In general, advances in automation and artificial intelligence (AI) are making it easier to manage complex IT environments at scale, noted Fitzgerald. However, it’s not likely IT environments will be automated to the point where lights-out management without human intervention is likely to be achieved any time soon, added Fitzgerald.

    However, it’s also becoming apparent that it’s not possible for IT teams to manage complex IT environments without help in the form of advanced analytics tools. In fact, while many IT professionals are leery of automation tools because of the perceived threat to their jobs, it’s also becoming apparent that IT teams will not be able to manage modern IT environments without these tools. Organizations can’t afford to hire small armies of IT personnel. In addition, finding and retaining IT professionals that have, for example, Red Hat OpenShift skills remains a significant challenge.

    Red Hat Insights provides IT teams with additional levels of context required to manage these environments that goes beyond simple monitoring, noted Fitzgerald. That’s critical, as the IT environment becomes more extended in the age of hybrid cloud and the rate at which platforms are updated steadily increases, added Fitzgerald. Platforms such as Red Hat OpenShift, for example, are now typically updated every three to four months.

    DevOps, of course, has always been about ruthlessly applying automation whenever possible. As analytics applications become more robust, IT teams gain the visibility required to automate a wider range of complex tasks, noted Fitzgerald. In fact, in the absence of that visibility, automation can be a dangerous thing when mistakes caused by a lack of visibility and insight are made, added Fitzgerald.

    In the longer term, Red Hat expects to see continued convergence of job functions and roles as IT teams become more cross-functional, said Fitzgerald. Platforms such as Red Hat Insights will provide a single console around which these teams can collaborate, added Fitzgerald.

    Going forward, there won’t be a handful of administrators with augmented capabilities. Rather, IT specialists that have a particular set of skills will be able to collaborate more easily in a way that both creates a better outcome and ultimately keeps a lid on the total cost of IT.

  • Three Manual Accessibility Testing Pain Points

    Three Manual Accessibility Testing Pain Points

    According to industry research, the vast majority of IT leaders view test automation as the single most important factor in accelerating software innovation. This also applies to automated accessibility testing – a great first step for making websites accessible to persons with disabilities. The new breed of automated tools can catch nearly 83% of all accessibility issues (not to be confused with overlays, which claim 100% automatic compliance.)

    Automation does not, however, replace the need for manual testing, which is the only surefire way to ensure all users can access the information on your website without difficulty. To get complete coverage, you also need to perform manual accessibility testing (which requires a human to complete using the various assistive technologies that people with disabilities depend on) with multiple browsers and interfaces. However, manual testing comes with several challenges, which is why testers often perceive it as painful or complicated.

    Pain Point One – WCAG Has Many Success Criteria

    The most widely-accepted set of accessibility standards are the Web Content Accessibility Guidelines (WCAG), created by the W3C. WCAG criteria are classified by various versions and levels. Versions include WCAG 1.0, 2.0, and most recently 2.1, with version 3.0 actively under development. Success criteria under each of these versions are further broken down into conformance levels A, AA and AAA, with each level adding criteria.

    Depending on which WCAG conformance level you choose, you could reasonably expect to check somewhere between 25 to 50 success criteria when assessing the accessibility of your site or app. As you can see, a significant amount of familiarity and expertise is required with WCAG success criteria to be able to perform accurate, full-coverage accessibility testing on a site or app.

    Fortunately, software has reached the point in testing maturity where there are guided instructions for testing for specific criteria that must be manually tested. One example is keyboard navigation, often used by persons with motor disabilities. In this instance, the tool would simulate a user who interacts with a web page solely by using their keyboard; then the tool would describe a step-by-step instruction to identify accessibility issues during keyboard navigation. One such example: a news site with a carousel featuring five news stories, only one of which is visible at a time. There needs to be ‘previous’ and ‘next’ buttons that can be accessed and triggered using a keyboard so that keyboard users can navigate through the stories just as easily as they could with a mouse.

    Pain Point Two – Screen Readers Take Time and Expertise to Learn

    In addition to understanding numerous success criteria, accessibility testers also need to understand how to use a screen reader, a popular form of assistive technology. There are numerous screen readers available including JAWS, NVDA, VoiceOver and Talkback. Now, imagine having to memorize more than 50 success criteria that need to be tested across three different screen readers in multiple testing environments (desktop, responsive web, native mobile, etc.).

    Luckily, customized testing methodologies have been developed based on a chosen ruleset and testing environment. This reduces the amount of memorization and prior experience the tester needs to run effective tests. With specific screen reader testing steps outlined for each ruleset and testing environment, accessibility teams can improve their efficiency and create a standardized testing process for the whole testing team to follow—whether they are screen reader experts or not—resulting in a significant productivity boost.

    Pain Point Three – WCAG Success Criteria Can Be Open to Interpretation

    Some WCAG success criteria can be very contextual. Criteria that appear simple to test for, like color contrast requirements, can sometimes be tricky to analyze. For example, imagine a black, bold-faced word featuring dark gray shadowing against a light gray website background.

    In this image, which two colors should be compared to verify whether the minimum color contrast requirements are satisfied? Light gray and black, dark gray and black or light gray and dark gray?

    In scenarios like this, different accessibility experts can (and will) have different opinions. For a developer, there is nothing more frustrating than receiving different remediation requirements for the same issue. This can create confusion and introduce significant delays in the release of a product.

    The solution is clearly documented and detailed requirements to help reduce the potential number of issues that can be interpreted differently. Properly documented testing processes can help ensure that the results coming from an accessibility test team will be consistent, and significant time will be saved communicating issues back and forth between testers and developers.

    Automated testing is great for addressing many ‘low-hanging fruit’ problems without having to be an accessibility expert or hire one, but it does not eradicate the need for manual testing. While there are certain characteristics of manual testing that can make it onerous, fortunately, there are guided testing tools, auditors, methodologies and more available to take the pressure off accessibility teams. This will enable development teams to strike the ideal composition of manual and automated accessibility testing that helps them identify and repair the highest possible number of issues.

  • Technical Obsolescence

    Technical Obsolescence

  • AI Reimagines Computation and Improves Software Development

    AI Reimagines Computation and Improves Software Development

    While modern business software solutions unlock organizational efficiencies, agility and the ability to deliver new value to customers, such tools were not available when applications deployed on mainframe systems were being developed.

    Today, many of the Fortune 500 companies, the world’s largest banks and insurance companies and several of the largest retailers in the U.S. continue to rely on legacy programming languages, such as COBOL or Java, to power their applications. However, with new languages coming on the scene and experienced programmers in legacy languages exiting the workforce, organizations find themselves in an increasingly difficult spot.

    Is it a Coding Skills Shortage or a Knowledge Gap?

    As proficient programmers retire or move on, organizations across industries are recognizing they no longer have the specialized domain knowledge of the industry and institution to effectively maintain and support their complex critical systems. To combat what is perceived as a skills shortage, organizations are sinking a significant amount of effort into hiring new developers, teaching them to write in the legacy languages and tasking them with changing enterprise systems.

    Modernizing applications, databases and systems that run well in their current state can be risky and expensive, so building on top of and around existing code can be the better choice. But such workarounds are not always completed in the most appropriate manner. For example, when a developer is cutting and pasting large chunks of code just to change one behavior, the end result is often awkward and unmanageable applications that even the most accomplished developers struggle to deconstruct and understand.

    Understanding the code is not enough. Developers have to know what an application actually does, but if they don’t recognize how altering code in one part of a system impacts another part, the consequences can be devastating. As such, the challenge is not a skills problem — most programming languages are straightforward enough to learn — it’s a knowledge problem that exists across programming languages.

    Goodbye, Years of Language-Specific Experience. Hello, AI.

    The programmers who wrote all those billions of lines of code are still running mission-critical applications, but they are increasingly aging out of the workforce or opting for a new or different career path. This results in legacy systems being less well-understood by the companies that rely on them every day. While many programming languages are meant to be easy to read and understand, unknotting the program logic frequently devolves into a tedious reverse-engineering project in which developers are attempting to unearth the intent of previous developers encoded in the software.

    Rather than relying on aging subject-matter experts to pass along that specialized knowledge to programmers fresh out of college (who are in short supply anyway), organizations might consider leveraging advanced artificial intelligence (AI) tools to automate the process of identifying the specific code that requires attention — no matter how entangled that code is throughout the system.

    While AI can be used to help with the syntactical issues of writing code (much like the Smart Compose feature leverages machine learning to “look ahead” and offer suggestions as you type), the impact of such tools is minimal. AI’s greatest time-saving opportunity lies in automating developers’ steps when conceptualizing and writing code. Whatever the reason — be it poor documentation or spaghetti code — developers spend about 75% of their time in search of the source code that needs to be changed. That source code is likely to be interspersed throughout the code repository, requiring a developer to “think through” what the code does, at nearly every step, to trace out the code detailing the behavior that they seek to modify.

    How AI Overcomes the Inadequacies of Automated Testing

    The goal of many organizations is making changes to systems running older programming languages as safely and efficiently as possible. Some organizations are turning to DevOps to improve agility and accuracy without sacrificing their existing mainframe system’s stability and performance. When it comes to COBOL code, where the problem is more acute than in other languages, automated testing in the CI/CD pipeline is inherently inadequate.

    Once a developer has identified the code representing a behavior that needs to be changed, they’re in a position, in that automated pipeline, to ensure that the corrected behavior never changes. However, because the code describing the behavior in question can be spread throughout the system, a developer will make a change believing they haven’t altered any other behavior, but they may have actually ‘broken the world.’ System-breaking changes can be made to the code -and stay hidden – because testing may not cover scenarios that the developer didn’t consider. Well-constructed automated test suites are data-dependent, but assembling all of the data necessary to get 100% code coverage is, unfortunately, next to impossible.

    If, for example, the application required a security or regulatory change, a developer might think that their correction will be covered by the automated test suite when it’s not. Without copious data in the suite, developers cannot guarantee that a behavior will never be altered. With AI “reimagining” computation as conceptual, developers are able to validate that they haven’t broken the system before they compile or check-in the code — or even run it in debug mode to check it — before running the automated test suite. Once developers are confident their change is isolated, the “conceptual check” of the behavior may be leveraged in the CI/CD pipeline, thereby ensuring the behavior remains intact from that point forward.

    In short, advanced AI makes developers’ lives easier because AI can automatically analyze source code and understand the human intent behind it. Now, developers can collaborate with AI to locate source code in an effortless manner, quickly perform comprehensive impact analysis and make the necessary change(s) without ‘breaking the world.’ The improved productivity and efficiency AI unlocks is critical in maintaining and improving the important legacy and mainframe systems that handle tens of billions of business transactions every single day.

  • Low-Code Automated Software Testing Drives DevOps

    Low-Code Automated Software Testing Drives DevOps

    The DevOps world has quietly turned its focus to solving an essential challenge: enabling software teams to innovate quickly while meeting high customer expectations for quality. In other words, to build useful things faster with fewer mistakes. This tension has been growing for years, but 2020 added the challenges of remote work and accelerated digital transformation to the continued disruption brought about by cloud, SaaS and DevOps. In 2021, we need a road map for taking test automation to the next level with quality engineering, a discipline that incorporates best practices and data-driven testing into the end-to-end customer experience and drives organizational growth.

    Rethinking the Quality Process for the DevOps Era

    Quality engineering (QE) has traditionally lacked the tools needed to keep pace with digital transformation. Many QE teams struggle with complex, brittle automation frameworks and slow manual testing which create serious bottlenecks to DevOps adoption. While development accelerates, QE is left with disparate or outdated workflows and toolsets.

    Rising to the challenges and opportunities presented by DevOps and digital transformation will require innovation in our approach to quality. More than ever, we need to shift our focus away from quality assurance as a task that you perform late in the software development life cycle (SDLC) in favor of quality engineering practices throughout the entire life cycle. It starts with broad, effective test coverage – beginning when your developer is working on a local branch and continuing until a high-quality customer experience is confirmed in production across the entire surface area of the application – web, API, mobile, email, PDF or otherwise. It also goes deep; you evaluate all aspects of quality, ensuring that you satisfy requirements related to functional correctness, accessibility, performance, user experience and more.

    Low-Code Test Automation Unlocks a Culture of Quality

    With low-code, genuinely effective testing is at the fingertips of every role, from manual testers to developers, automation engineers, product owners and customer support. Requiring all of these roles to develop specialized programming skills is impractical, so low-code tools serve to democratize quality engineering by enabling everyone to participate in authoring tests, updating tests, and gaining insight from test results.

    Low-code testing brings several advantages to quality engineering, particularly in the transition from manual testing to automated testing. While traditionally this process would create major disruptions, low-code platforms are smoothing the way. In their IT Automation predictions for 2021, Gartner expects that by 2024, improvements in automation capabilities will refocus 30% of IT operations efforts from support to continuous engineering. For manual testing teams, that shift would likely trigger talent changes and a long process of pilot projects, retraining, and gradual rollouts. Low-code is key to managing this shift, upskilling workers and ensuring quality throughout.

    Modern Automation Solutions Embrace Rapid Change

    A key challenge with traditional test automation tools is that they were designed for applications that didn’t change frequently and were intended only to validate code. They relied on static selectors to identify page elements. If the selector (say, an ID) changed or objects (the XPath) moved on your webpage, then your tests failed. As more enterprises accelerated development via DevOps, Agile and CI/CD, the burden of test maintenance resulted in the same bottlenecks as manual testing.

    2020 was a breakout year for low-code test automation. New, easy-to-use solutions surpassed the capabilities of legacy frameworks that have dominated the sector. These solutions incorporate machine learning, data analytics and other advanced technologies to greatly reduce the burden of test maintenance and overcome the test rigidity challenges of legacy frameworks.

    With AI and machine learning, test automation solutions are trained by a tester simply navigating their product. As the tester moves through common customer journeys, the solution builds an understanding of each element and its context so that if an element moves or a property changes, tests containing that element are updated without human intervention. This drastically reduces the amount of maintenance required to ensure your tests are current. When tests do need to be updated, low-code models make it easy for anyone to jump in and make the updates. Looking ahead, auto-healing and low-code editing are crucial to supporting quality engineering in high-velocity teams.

    Testing the Entire Customer Experience

    Traditional pass/fail validation stops short of offering real insight into the user journey, a critical step effective quality engineering. The next generation of test automation platforms expands focus from validating code to validating the entire user experience. This starts with broadening testing to cover non-functional requirements, such as application performance, accessibility, and user experience. For example, identifying trends in load time for key pages and monitoring visual changes are done autonomously and essential to managing the customer experience. From there, you can prioritize quality efforts toward the components of your application that are most heavily used or highest risk. This enables you to make data-driven decisions about test coverage — focusing your testing efforts on high-priority pages like the checkout page for an e-commerce site, or high-risk pages such as those with multiple interactive elements that are linked from other pages, such as signup forms.

    But even a fully data-driven testing strategy that only focuses on the app or website UI is unlikely to cover the full end-to-end user journey, resulting in test coverage gaps and potential pain points for customers. For example, a common user journey may include opening an email, clicking on a link, checking a web site, and downloading a PDF. Whereas the limitations of legacy tools relegates testing to the web portion of that journey, modern solutions allow you to validate the entire user or customer experience (CX): receiving and opening an email, clicking on the link, logging into the web site, downloading the PDF and verifying its content. It’s even possible to confirm values in the backend via API – all without writing a line of code. Developing the tools to seamlessly monitor, repair, and manage the expanded CX is central to our innovation and to our customers’ success.

    Quality Engineering as User-Centric as You

    Quality is no longer an afterthought or just a box to check before deployment; it’s an essential part of the user experience, and therefore an essential part of maintaining a competitive advantage in every industry that uses software to serve customers. Test automation is critical for high-velocity teams racing to innovate faster, shift to DevOps, and build quality products while working remotely. Thankfully, a growing number of quality assurance teams are getting a seat at the table as DevOps is implemented, elevating the profile of quality as a strategy and growing demand for test automation solutions that can keep pace with the demands of DevOps.

    In response to this demand, a new generation of intelligent test automation solutions is enabling teams to rise to the challenge by embracing low-code and machine learning to maintain quality. To build a culture of quality engineering in this environment, your team needs test automation solutions that are as user-centric as you are: solutions that provide coverage across the entire user journey. Solutions that not only verify functional correctness, but provide rich insight into all aspects of quality and enable continuous improvement. Perhaps most importantly, you need solutions that enable everyone on the team to participate in quality. This ensures that the entire SDLC actively participates in building user-friendly products that continue to set the standard for quality at the speed of DevOps.

  • The Post Scarcity World

    The Post Scarcity World

  • Survey Shows Mounting DevOps Frustration and Costs

    Survey Shows Mounting DevOps Frustration and Costs

    A survey of 400 developers and DevOps team members in the U.S. and Europe found, on average, 15 hours a week are being spent managing tasks such as debugging pipelines and waiting for tests and builds to complete.

    Conducted by the market research firm Vanson Bourne on behalf of Garden, a provider of a platform for automating application development and deployment tasks in Kubernetes environments, the survey finds more than three-quarters of respondents (76%) said the time spent on these and other manual DevOps tasks is generally being wasted.

    Garden CEO Jon Edvald said, all told, 39% of a 40-hour workweek is typically devoted to these tasks. When the number of developers and DevOps specialists that are employed today are factored into that equation along with their salaries, as much as $61 billion is being wasted on these tasks in the U.S. alone, he noted.

    The top sources of DevOps frustration cited by survey respondents are waiting for pipelines to run (76%), waiting for builds and tests (74%) and setting up, maintaining and debugging pipelines/automation (71%). In fact, only 11% of all respondents are completely happy with their development setups and workflows.

    Those hidden costs may even increase as organizations bring on additional DevOps expertise. A full 83% of respondents said their organizations are planning to hire more staff or increase their use of freelancers/outsourcing into DevOps roles in 2021. Three quarters (75%) said DevOps budgets have increased or will increase compared to 2020.

    In addition, the adoption of more complex platforms, such as Kubernetes, may also conspire to increase costs, noted Edvald. Respondents at organizations not yet using Kubernetes spend an average of 14.3 hours per week on low-level DevOps tasks, as compared to 16.5 hours a week for those who are already using Kubernetes. Nearly two-thirds of respondents (62%) said their organizations are already using Kubernetes, while 31% are currently evaluating it, to varying degrees. A full 95% of respondents using Kubernetes have faced challenges after rolling it out, including training and onboarding (37%) or complexity of setup/configuration (35%).

    Of course, not all the time that might be saved is going to be applied to tasks that increase overall productivity; nearly half of respondents (49%) said if they had it, they would spend more time developing new products and services.

    Specifically, 46% said they would improve speed and delivery of existing products and services, while 44% said they would focus on improving security for existing products and services.

    Edvald said the survey makes it clear there’s still plenty of opportunity to automate repetitive DevOps tasks. Organizations are spending too much time on the care and feeding of DevOps platforms that takes time away from building and deploying applications, noted Edvald.

    Less clear is when organizations will reach some type of DevOps breaking point. Garden is betting that the transition to cloud-native applications based on microservices will eventually force the DevOps automation issue. However, in organizations that only know the DevOps processes they have used for years, change may be a long time in coming.