devopsy.kinsta.cloud

Tag: testing

  • Testing Emerges as DevOps Hurdle in Mainframe Shops

    Testing Emerges as DevOps Hurdle in Mainframe Shops

    A survey of 400 senior IT leaders responsible for application development using mainframes finds 90% believe automating more test cases could be the most important factor in their success, as the pressure to accelerate innovation increases. However, the same survey finds only 7% of organizations automate the execution of test cases involving mainframe code today.

    The survey, which was conducted by Vanson Bourne on behalf of Compuware, also finds the time required to conduct thorough testing is the biggest barrier to integrating the mainframe into agile and DevOps processes for just over the half the survey respondents (53%), followed by a lack of skills (39%) and lack of understanding how code changes will impact distributed applications (34%).

    A total of 82% said that unless they can automate more test cases, they will not be able to meet the need for speed the business now requires. That may account, in part, for why 56% of respondents said they plan to start automating the execution of test cases on mainframe code within the coming year.

    The biggest benefits expected to be derived from those investments include greater efficiency within the IT team (59%), improved consistency of testing (53% ), reduced chance of human error (47%), reduced pressure on IT teams (47%), accelerated innovation cycles (46%) and less chance of bugs making it into production (40%).

    Primary areas of focus for automated testing are ranked as functional testing (63%), followed by integration testing (53%) and unit testing (37%).

    The survey also finds development teams are spending, on average, more than half their time (51%) on testing during the release of a new mainframe application, feature or function. That compares to 39% of their time testing applications, features or functions on applications that don’t run on mainframes.

    A full 92% said mainframe teams are spending more time testing code than they needed to in the past because of the growing complexity of cross-platform application environments. Issues organizations are contending with are “Manual and time-consuming test processes” (44%), “Mainframe testing processes require specialists that are not always readily available” (40%), “Testing processes are costly” (39%) and “It’s hard to visualize and understand dependencies” (35%).

    Not surprisingly, 77% of respondents find it increasingly difficult to simultaneously increase quality, velocity and efficiency to meet business innovation goals when developing and testing mainframe application code. Top concerns when it comes to mainframe development are introduction of security flaws (50%), impact on customer experience (38%) and disruption to operations (36%).

    A full 85% said it is becoming more difficult to deliver innovative and faster applications without compromising quality or increasing the risk of bugs finding their way into production.

    Steen Brahe, product manager at Compuware, said organizations that have mainframes are usually under pressure to innovate faster now because competition from startups relying on DevOps processes and modern platforms has increased sharply. Rather than incurring the cost of replacing mainframe applications on which the business currently depends, organizations that have mainframes are looking to extend DevOps processes to integrate emerging and legacy applications.

    It’s not clear to what degree those organizations will succeed. However, the one thing that is clear is organizations with mainframes that fail to embrace best DevOps processes are already most certainly doomed.

    — Mike Vizard

  • Testim Adds SDK to AI-Based Testing Platform

    Testim Adds SDK to AI-Based Testing Platform

    Testim this week launched a beta release of a software development kit (SDK) consisting for a set of JavaScript application programming interfaces (APIs) that will enable DevOps teams to build tests that leverage machine learning algorithms from within their integrated development environment (IDE).

    Company CEO Oren Rubin said the Testim Development Kit makes it possible to call capabilities such as the ability to record user interface interactions via an application programming interface (API).

    The Testim approach to applying artificial intelligence (AI) testing differs from rivals in that Testim allows DevOps teams to fully inspect how algorithms construct a test, he noted. DevOps teams can also customize those algorithms to fit their own requirements, which is critical when it comes time for DevOps to explain how tests were conducted as part of a compliance audit.

    Testim will continue to provide access to its platform via a graphical user interface, but with the edition of the SDK, Rubin said his company expects to see an increase in the number of DevOps teams that will incorporate Testim within the context of continuous development/continuous deployment (CI/CD). Once that occurs, the number of tests those teams will be willing to run against software before it’s deployed in a production environment should also increase, especially as more developers leverage APIs to create their own tests, Rubin said. That doesn’t eliminate the need for another set of eyes to test an application, but it should reduce the number of common errors made before any piece of code is tested by someone else on the DevOps team.

    One of the most time-consuming elements of any DevOps process is the time it takes to create tests for each application. The Testim platform employs machine learning algorithms to discover the entire application environment and then begin creating appropriate tests. As DevOps teams modify those tests, the Testim platform continues to learn how to build tests the way the DevOps team prefers.

    The Testim platform doesn’t eliminate the need for testing expertise on the DevOps team, but it does enable organizations to scale their testing processes by augmenting whatever testing expertise they have on hand to reduce bottlenecks and improve overall software quality. Those algorithms also provide the added benefit of never taking a day off or quitting to take a more lucrative position elsewhere.

    When it comes to AI, there is naturally a lot of fear and loathing. On the one hand, IT professionals become concerned AI will replace them. On the other hand, they are often disappointed when machine learning algorithms don’t instantly automate a process to their satisfaction. It takes a significant amount of time for algorithms to learn how any IT environment operates, with each update to that environment requiring those algorithms to discover new functions. At this juncture, it’s not a question of whether AI will play a role in DevOps processes, but rather to what degree. Given the repetitive nature of testing, Testim is betting application testing will prove to be an area that lends itself to AI sooner than later.

    — Mike Vizard

  • CloudBees’ Acquisition of Rollout: The CEOs’ View

    CloudBees’ Acquisition of Rollout: The CEOs’ View

    As Mike Vizard reported yesterday, CloudBees, as part of its mission to build “the world’s first end-to-end automated software delivery system,” announced another acquisition: Rollout, a developer of a feature flag application that allows for simplified testing of new modules within an application.

    Not to repeat the gist of Vizard’s article; you can read it for yourself. But this continues what has become something of an acquisition tear by CloudBees. The company has acquired CodeShip and Electric Cloud, among others, while becoming one of the founding members of the new Continuous Delivery Foundation (CDF), under the Linux Foundation and a sister foundation to the Cloud Native Computing Foundation (CNCF) and the Cloud Foundry Foundation. The CDF is now managing the Jenkins project, as well as Jenkins X, Spinnaker and Tekton.

    CloudBees’ Mission

    Make no mistake: These acquisitions, along with the CDF formation, represent a major change for CloudBees. The team there is clearly trying to separate from the pack of “end-to-end” DevOps contenders. CloudBees CEO Sacha Labourey is pushing hard to raise CloudBees above the noise and the rest of the market. The company announced a $62 million round of financing about a year ago.

    You don’t have to be Warren Buffet to see that CloudBees sees an opportunity here. The company is driving toward achieving scale in product and revenue on the path to some sort of liquidity event (perhaps an IPO?) or market leading opportunity.

    For now, though, back to the Rollout acquisition. I had the chance to sit down with Labourey and the CEO and founder of Rollout, Erez Rusovsky. We discussed what Rollout does, its history and how it will fit into the CloudBees product portfolio.

    It is always great to interview a founder about his company being acquired. What a tremendous feeling of accomplishment to found and build a company, and have another entity value it so much that you are willing to sell it to them. This goes so far beyond validation.

    Congrats to Erez and the whole Rollout team and, of course, congratulations to Sacha, KK and the rest of the CloudBees team. This seems like a perfect fit.

    In the meantime, here is my conversation with Sacha and Erez on the acquisition and more. Enjoy!

     

    — Alan Shimel

  • Why Workload Security Is Not Just for IT Anymore

    Why Workload Security Is Not Just for IT Anymore

    Once upon a time, workload security (which means making sure an application and its environment are configured and deployed securely) was something that developers didn’t have to think much about. Developers’ only real security responsibility was to write secure code. After they passed the code off for building, testing and deploying, it was someone else’s job (specifically, the IT department) to secure the workload of which the code was a part.

    That’s no longer the case. Today, workload protection is the responsibility of the entire DevOps team, not just IT engineers.

    Let’s explore why, and what this change means for developers.

    How Security Problems Flow Down the CI/CD Pipeline

    To understand why workload protection has become everyone’s responsibility, you have to understand how DevOps and CI/CD have given rise to new types of security challenges.

    In an organization that has embraced DevOps, code is intended to flow continuously, in a so-called CI/CD pipeline, from development to testing, to building and, finally, to deployment. To keep the CI/CD pipeline flowing smoothly, DevOps teams typically strive to standardize and automate as many processes as possible.

    From the perspective of efficiency and reliability, standardization and automation are great. They are key to enabling continuous software releases.

    When it comes to security, however, standardization and automation have a downside, which is that a configuration problem introduced at one stage of the pipeline can flow down the pipe and reach production environments easily without anyone noticing.

    This is true for two main reasons. First, standardization and automation minimize the amount of human intervention and oversight that go into the CI/CD process. Again, that’s exactly the point, and it’s a benefit in most respects. But when it comes to security, less human intervention means a greater chance that a security problem will go undetected (particularly if you don’t have automated security tests or audits in place to catch the issue).

    The second major risk associated with standardization and automation within a CI/CD pipeline is that sometimes, developers might set a configuration that they don’t intend to be used in production, but is pushed into production nonetheless by the automated pipeline.

    For example, developers might place code inside a container to help with testing or staging, without intending for that same container to be used in production (instead, they assume the code will be repackaged before being deployed). Because they don’t intend for the container to be used in production, they don’t use a secure configuration for it. Maybe they let it run as root, for example. Then, if communication breaks down and a release automation tool pushes that container into production without changing the configuration, a container with a security flaw will end up being deployed.

    To learn more about security and compliance for DevOps, check out our recent webinar.

    Extending Workload Protection Beyond IT

    In a perfect world, the IT team would be able to catch these flaws. But the reality is that in a fast-moving CI/CD environment, it’s not realistic (or fair) to expect IT alone to make sure that workloads are configured securely before they are deployed.

    Instead, the entire DevOps team needs to take responsibility for workload security.

    What that means specifically will vary from organization to organization, but in general, extending workload protection beyond IT means the following:

    • Making sure that developers (and not just IT engineers) understand workload security best practices and why they are important to follow at every stage of the CI/CD process.
    • Establishing and enforcing (via automated audits) policies for how workloads can be configured at any stage of the CI/CD pipeline. For example, the DevOps team as a whole might agree not to run containers as root, even if it’s only in pre-deployment.
    • Enabling runtime protection by scanning for vulnerabilities that appear within applications and environments once they are live.
    • Securing data at all stages of the CI/CD pipeline and scanning data for signs of intrusion or malicious code.
    • Performing continuous security monitoring and vulnerability detection (both pre-deployment and post-deployment) to catch issues as quickly as possible, even if they have slipped through the cracks of earlier security tests.

    Conclusion

    It would be nice for developers if workload security was not their responsibility. But in the age of CI/CD and DevOps, they no longer can hand off that burden to the IT team. The IT team still has an important role to play in making sure workloads are deployed securely, but effective workload security for DevOps starts early in the CI/CD pipeline—with developers. Code moves too quickly down the pipeline for developers to assume that they can safely do one thing with a workload and have the IT team change it before the workload is deployed.

    Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

    Sign up for a free trial of Symantec CWP.

    — Chris Riley

  • Value Stream Optimization: Putting Business in the Driver’s Seat

    Value Stream Optimization: Putting Business in the Driver’s Seat

    How value stream can be a major driver of DevOps success in today’s software-only world

    Even as DevOps reaches a pinnacle in acceptance (as of 2018, only three percent of firms had not adopted DevOps and had no plans to do so), many organizations are still struggling to get high-quality software out the door. DevOps has been promoted by many experts and consultants as a solution to the cumbersome inefficiencies that were common with waterfall methods. However, as is common for many operational activities, applying a new approach or technology doesn’t automatically resolve entrenched problems.

    Nowhere is this more obvious than in value stream management (VSM). This approach, which focuses on removing the waste from processes to increase their efficiency, sounds like a panacea for resolving software delivery challenges. In practice, it often falls short of its goals.

    Why is this? There is nothing wrong with the concept of the value stream. The idea of breaking down a complex process into its components and optimizing each one of them, thereby optimizing the chain, is a long-recognized pillar of lean production. In my view, the problem isn’t with VSM or even DevOps.

    The problem is that in moving from waterfall to DevOps and/or agile, many organizations figuratively “throw the baby out with the bathwater.” They are uncertain how to adjust for the extreme acceleration that occurs when teams move from rudimentary software processes to modern ones, so they either jettison important elements of software engineering or adapt them incompletely.

    Why Continuity Matters

    By way of example, consider measurements and metrics. The traceability and proactive remediation enabled by measurements and metrics are two of the most important aspects of software development. However, it’s not just the development and test metrics that matter, but also the business metrics—metrics of quality, user acceptance, security and ease of use. Since the dawn of software development, those two groups of data have been inextricably linked, but some modern software teams appear to have forgotten that lesson.

    No amount of process improvement metrics can ensure a software release is secure or that users will like it. Yet, if a major software upgrade is flubbed, it can impact operations so negatively that sales momentum stalls. (If the company sells the software it develops, the ripple effect is even stronger.) Even more disconcerting, after a major data breach, a firm can find itself out of business.

    Don’t get me wrong. I am not suggesting that flow and other DevOps metrics don’t matter, because they do—very much. I am suggesting that many teams and their development managers have become too divorced from the business metrics, which can have staggering negative consequences.

    From There to Here

    In the days of waterfall, development artifacts, defects and other data were warehoused in an offsite location, and after each release (which might take days, weeks or even months), teams would engage in several days of data extraction. Then, a separate team would attempt to map the development artifacts to the defects and enable traceability. After hours or days of organization and cross-mapping in Excel spreadsheets, reports would be generated for management and the C-suite. Once stakeholders and management completed their evaluation, the team would be cleared to make adjustments before the next release cycle.

    Now, our development paradigm has changed so dramatically that many teams aren’t giving metrics their due. That’s an issue with defect metrics that could impact the user experience or software reliability. It’s a serious, potentially game-ending problem when the metrics are related to security.

    Completing the Value Stream

    To create and administer the complete value stream, software teams must be supported in three areas beyond the traditional DevOps framework where iterative development activities are the primary driver of traceability measurements. With these elements in place, management can map their software teams’ efforts to the business metrics that are the final measurement of success:

    • Organizations must have a mechanism for integrating development and testing tools so that defect measurements can flow back to the development team in real-time—matching the speed of DevOps.
    • Critical software activities that still take place outside of development and testing processes, such as generation and approval of change orders, must also be monitored for inertia, with approvers being held accountable for holding up paperwork that delays releases.
    • Security defects must be given parity with, and preferably priority over, all other code defects. All defects that impact the user side, such as functionality and launch speed, are important business metrics. But security must be paramount.

    If you are a development team member reading this, or even a development manager, you may think business metrics and the related activities that happen outside your purview, don’t apply to you. I urge you to think again. Software has become a critical pillar of many companies’ operational success, and that connection is only growing stronger by the day. Everyone involved in software development, from the developer to the VP of Operations and on to the CEO, must view the entire process through the lens of business.

    — Joe Schulz

  • Sauce Labs Acquires Screener Visual Testing Tool

    Sauce Labs Acquires Screener Visual Testing Tool

    At the SauceCon 2019 conference, Sauce Labs today revealed it has acquired Screener to add a visual testing tool to its portfolio of automated testing tools.

    Lubos Parobek, vice president of product for Sauce Labs, said the addition of Screener will make it possible for DevOps teams to not only test functions and performance using existing Sauce Labs tools, but also now confirm things such as the colors of a visual element of an application are being rendered correctly, for example.

    In addition to building their own visual tests, DevOps teams can employ Screener to automate the running on those tests and store baselines in the cloud to create a visual testing life cycle.

    At the same time, Sauce Labs announced the general availability of Sauce Headless, which leverages container technologies to make it possible to leverage a cloud service through which developers can now run tests via a Chrome or Firefox browser every time they commit code. Parobek said the goal is to make it easier for organizations to embrace continuous testing as an extension of the pipelines constructed using a continuous integration/continuous deployment (CI/CD) platform.

    The acquisition of Screener, he said, is part of an ongoing Sauce Labs effort to extend the reach of its testing portfolio beyond functional testing. Sauce Labs earlier this month launched Sauce Performance, its first set of application performance testing tools.

    The rise of DevOps is challenging traditional approaches to application testing as organizations move to combine various types of testing into a single continuous process. To meet that requirement, Sauce Labs is expanding its portfolio of automated testing tools at a time when the emergence of microservices-based applications is significantly increasing the level of dependency between all the components that make up an application. That increased level of dependency will require DevOps teams to rely more on automated testing tools. In fact, Parobek said the day is not far off when DevOps teams will include digital assistants that leverage machine learning algorithms to enable DevOps teams to continuously run those tests at the right moment in an extended DevOps pipeline. Those digital assistants will not replace the need for human testers anytime soon, but they will augment their capabilities to make is feasible to implement continuous testing at scale, he noted.

    In the meantime, as application testing continues to shift further left in the DevOps process, more developers will be building and running their own tests during earlier stages of the application development process. At some point, either another developer or dedicated tester still will need to evaluate that code to provide an unbiased opinion. But the number of common mistakes making it into the latter stages of the application development process should be substantially reduced. Ultimately, that shift to the left should result not only in more development projects meeting deadlines, but just as significantly higher levels of overall application quality. The challenge now, of course, is figuring out how to implement a best DevOps practice that pushes application testing as far to the left as possible.

    — Mike Vizard

  • Gremlin Brings Chaos Monkey Testing to Spinnaker CD Platform

    Gremlin Brings Chaos Monkey Testing to Spinnaker CD Platform

    Gremlin this week announced it will integrate its hosted chaos engineering service with continuous delivery platforms starting with the open source Spinnaker project developed by Netflix.

    Chaos engineering traces its roots to a resiliency testing philosophy that posits applications should be able to keep functioning regardless of any service or infrastructure failure. Most IT organizations, however, don’t have the expertise required to build the tools required to testing resiliency based on those “chaos monkey” principles that randomly turn services off to see if an application fails.

    Matt Jacobs, principal software engineer for Gremlin, said the decision to integrate with Spinnaker is being driven by the need to infuse chaos monkey resiliency testing directly into the application development and deployment pipeline at a more granular level. That capability is now a bigger requirement than ever because as organizations embrace microservices to build the next generation of cloud-native applications, it’s simply not possible for DevOps teams to manually track every dependency, he said, adding resiliency testing based on chaos monkey principles is just another type of testing that should be automated as part of a larger continuous integration/continuous delivery (CI/CD) platform to ensure an application doesn’t fail completely.

    Integrating with a Spinnaker project that has drawn support from Google, Microsoft and Oracle provides the easiest path to achieving that goal. Spinnaker is also now a core element of a Continuous Delivery Foundation led by Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    The Gremlin service is accessed via a user interface and comes in two forms: a free edition and an enterprise edition, which comes with support from Gremlin. While the concept of chaos monkey testing has been around for some time among the most advanced DevOps practitioners, enterprise IT organizations, which tend to be more conservative when it comes to introducing anything that might deliberately break their applications, will need a considerable amount of hand-holding. Gremlin is designed to learn the application environment in a way that introduces chaos in a controlled fashion before an application is deployed in a production environment.

    On the positive side, resiliency testing based on chaos monkey principles tend to accelerate the rate at which IT staff learn how an application has been architected, said Jacobs. That can prove especially invaluable when training new members of a DevOps team, he noted.

    Ultimately, the decision to embrace resiliency testing comes down to how proactive an organization wants to be when it comes to preventing downtime. When mission-critical applications are offline, there is a direct impact on the amount of revenue an organization generates. There are plenty of functional and performance testing tools, but the real difference between having an issue and a catastrophic event that requires DevOps teams to get out of bed in the middle of the night often comes down to how truly resilient any given mission-critical application really is.

    — Mike Vizard

  • Sauce Labs Combines Functional and Performance Testing

    Sauce Labs Combines Functional and Performance Testing

    Sauce Labs announced it is now moving beyond functional testing, adding a front-end testing tool it has dubbed Sauce Performance to make it easier to accelerate testing within the context of a DevOps process.

    Lubos Parobek, vice president of products for Sauce Labs, said the goal is to enable developers or testers to begin testing both how well application functions work and perform much earlier in the DevOps process using the same testing tool.

    Parobek said that as organizations embrace modern application development architectures based on microservices, it’s become crucial to test the capabilities of any module within an application because the number of interdependencies between modules continues to increase. That approach accelerates the rate at which applications can be developed. However, any flaw that impacts how the application works or performs can have a debilitating impact on any number of microservices that make up the application, he noted.

    Sauce Performance makes use of debugging and performance trace logs to identify the root cause of an issue in addition to capturing metrics such as Time to First Meaningful Paint, Time to First Interactive, Page Weight and Speed Index. Sauce Performance also employs algorithms to automatically establish a baseline that can be used for regression testing.

    Parobek said Sauce Performance serves to streamline testing processes as well. Most existing front-end performance testing solutions require integration with a load/stress testing tool or a separate application performance monitoring (APM) tool. However, Sauce Performance allows developers to use their existing Selenium test scripts to capture both functional and performance test data.

    In addition, Sauce Performance has been designed to integrate with multiple continuous integration/continuous deployment (CI/CD) platforms to make it possible to feed test results directly back to developers, which can then decide to prioritize issues that need to be addressed.

    Sauce Performance is available as part of the Sauce Labs Continuous Testing Cloud.

    Parobek said organizations want to be able to make it easier for developers to test their own code as part of their DevOps best practices. That doesn’t eliminate the need for dedicated testers for evaluating functions, but potential performance issues today are being addressed often long before applications are deployed in a production environment.

    One of the reasons applications are not as thoroughly tested as they might be is that many organizations require developers to learn how to use tools that have different user interfaces and then switch between testing tools. The result is a complex testing process that makes it more tempting to short-shrift elements of the testing process as application delivery deadlines loom.

    More challenging still, many organizations still don’t continuously test applications after they are deployed to ensure new functionality does not adversely impact the user experience.

    For as long as applications have been built, tension has existed between the developers who create applications and the people who test them. That debate may never be resolved, but everyone agrees in this age of DevOps that it’s better to test early and often.

    — Mike Vizard

  • Compuware Advances DevOps on Mainframes

    Compuware Advances DevOps on Mainframes

    Compuware has updated its Topaz for Total Test suite to enable organizations applying best DevOps practices to the development of mainframe applications to combine unit, functional, integration and regression testing within a single test scenario.

    In addition, Compuware is making it easier to test multiple applications simultaneously. The latest update to Topaz for Total Test adds the ability to not only orchestrate a sequence of steps, but also design tests to measure how programs interact with each other and various data sets.

    Also added is the ability to automate several testing functions, including the ability to launch functional tests within a browser and execute unit, functional and integration tests without having to manually create their own Job Control Language (JCL). According to Compuware, testers now can design test cases upfront based on program specifications before developing a program. What’s more, Topaz for Total Test has been integrated with the DevOps pipeline management platform developed by XebiaLabs.

    Finally, Compuware announced that the Topaz 3270 Emulator now makes it possible complete one-off “green screen” tasks without leaving Topaz. Initiating a CICS transaction or accessing REXX utilities through the Emulator within Topaz, for example, makes it simple for developers to quickly resume Eclipse-based tasks without having to exit its testing environment or toggle between tools.

    Compuware CEO Chris O’Malley said the pace at which IT teams in mainframe environments have been adopting DevOps practices has accelerated considerably in the past year. Not only are applications being developed and deployed faster, the quality of those applications has increased because DevOps tools provided by Compuware make it easier to both visualize a complex application development process and then test those applications as they are being developed. Given the often mission-critical nature of mainframe applications, it’s crucial that any increase in development velocity doesn’t have a negative impact on application quality, he noted.

    DevOps has become a greater imperative in mainframe environments, O’Malley added, as organizations look to leverage investments in existing mainframe applications rather than try replicating functionality that already exists on a mainframe in a distributed computing environment. That approach helps to reduce sharply the amount of technical debt an organization needs to service when they duplicate functionality across two or more platforms. Mainframe teams that historically have relied on waterfall developments process have been challenged by keeping pace with the rate of change. As applications that are deployed on a distributed system look to invoke a mainframe application function, organizations that have deployed those applications need to keep pace with a much faster rate of development, especially when it comes to application programing interfaces (APIs).

    It may take a while longer for DevOps practices on mainframes to become adopted widely. But as the rate of innovation continues to increase, thanks to the rise of various digital business transformation initiatives, it’s apparent that mainframe application development will need to become more agile. The challenge at this point is not so much the availability of DevOps tools for the mainframe, but rather training the teams that build and deploy those applications on when and how to implement DevOps practices.

    — Mike Vizard

  • Perfecto Applies AI to Writing Test Scripts

    Perfecto Applies AI to Writing Test Scripts

    Artificial intelligence (AI) is starting to be applied to the writing and update test scripts. Perfecto has unfurled Perfecto Codeless, which employs machine learning algorithms to automate writing of test scripts in a way that allows them to not only run continuously, but also adjust to changes made to the application.

    Eran Kinsbruner, chief evangelist for Perfecto, a unit of Perforce, said writing test scripts is still largely a manual process, which means as the number of applications being developed continues to escalate, the testing process becomes highly constrained.

    To address that issue, Perfecto has created a codeless approach delivered via a cloud service as part of the company’s Smart Automation platform. If any code within an application gets deleted, moved or changed, the changes will automatically be reflected in the test script. That capability eliminates the need for DevOps teams to wait for a developer to update the test script.

    Exactly who in an organization is writing those test scripts varies: Kinsbruner noted that many developers now prefer to write their own test scripts during the development process before their code is reviewed by a peer. That approach eliminates many of the more routine errors, enabling more time to be spent on optimizing code. Other organizations employ dedicated testers who spend most of their time writing test scripts. But many of those organizations are finding that testers cannot keep pace with the current rate at which applications are being developed in the DevOps era.

    There’s no doubt machine learning algorithms are about to play a much bigger role in application testing and DevOps at large. AI is not going to replace DevOps teams anytime soon, but many mundane functions such as the writing of test scripts can be automated using machine learning algorithms. Arguably, testing is one of the areas that lends itself most to emerging AI-based platforms and services. After all, if testing becomes a bottleneck, the chances that applications with issues are deployed in a production environment increase substantially. Many of those issues can be fixed easily, but many times at the risk of annoying end users who increasingly are unforgiving when it comes to application experiences. It’s not uncommon for users to discontinue using a mobile app if the first experience isn’t immediately gratifying.

    Of course, many DevOps teams already view machine learning algorithms with a certain amount of skepticism. But the rise machine learning algorithms within DevOps is now all but inevitable. IT leaders, however, should realize it may take a while for those algorithms to learn the environment. The return on investment for any AI project is not likely to be immediate because a significant amount of time needs to be invested in training the algorithms. The good news is, those algorithms never take a day off and suddenly don’t resign one day to take a better-paying job elsewhere.

    — Mike Vizard