devopsy.kinsta.cloud

Author: Mike Vizard

  • Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi announced today it is expanding the scope of its automation ambitions to make it easier to securely provision cloud infrastructure-as-code.

    Joe Duffy, Pulumi CEO, said the Cloud Engineering Platform enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning in a way that can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice, Duffy noted.

    The Cloud Engineering Platform is now generally available on the Microsoft Azure cloud, while a preview edition of the offering is available on Google Cloud Platform. Support for Amazon Web Services (AWS) is planned for later this year.

    The platform itself is based on version 3.0 of Pulumi, an open source tool that developers have previously employed to manage infrastructure-as-code. Pulumi is also making generally available a tool for integrating its tools with more than a dozen continuous integration/continuously delivery (CI/ CD) platforms.

    That capability, coupled with existing support for integrated testing capabilities and the tools for managing compliance-as-code based on identities, provides IT teams with a more comprehensive approach to managing infrastructure-as-code, said Duffy.

    Most cloud resources today are directly provisioned by developers using open source tools such as Terraform. The issue that organizations have encountered is that developers are prone to making configuration mistakes that cybercriminals then exploit. Pulumi is making a case for an alternative approach to provisioning infrastructure-as-code that makes it easier to validate configurations using testing tools, while at the same time limiting who can access infrastructure resources by including support for the secure access markup language (SAML) and single sign-on (SSO) capabilities.

    It’s not clear at what rate enterprise IT organizations will be shifting toward platforms that enable infrastructure to be managed as code in a more robust fashion. Developers that don’t always have the greatest appreciation for cloud security issues routinely employ tools such as Terraform to provision infrastructure-as-code with little to no supervision. Cloud resource misconfigurations often result in ports left wide open, and cybercriminals now make use of tools to scan for those types of misconfigurations.

    Pulumi Packages provides a means for IT teams to exercise more control over the provisioning process, using vetted reusable components in a way that doesn’t compromise the rate at which developers can spin up cloud resources, noted Duffy.

    As organizations focus more on software supply chains in the wake of some recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security doesn’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Many developers assume the cloud service provider is securing configurations, only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Hopefully, there will come a day when DevSecOps best practices leverage automation to resolve this issue once and for all. The challenge is finding the best way to achieve that goal in a way the average developer will accept and embrace.

  • Perforce Adds Synchronization Tool for Cross-Functional Teams

    Perforce Adds Synchronization Tool for Cross-Functional Teams

    Perforce Software has added a graphical tool, dubbed Helix Sync, that enables individuals, such as artists, to take advantage of the version control capabilities provided by its software development life cycle (SDLC) platform.

    Gerhard Krüger, cloud architect and product manager at Perforce, said that as DevOps workflows continue to evolve in the gaming and automotive industries, the need to manage artifacts such as drawings, for example, alongside software artifacts is becoming more pronounced among cross-functional teams.

    Helix Sync gives those end users access to a desktop client that enables any individual to upload artifacts into a system by dragging and dropping them into the Perforce Helix Core SDLC platform.

    Previously, end users that lacked coding skills would need to share files with developers via cloud services such as Dropbox. The Perforce approach removes the inherent friction development teams would otherwise encounter, while at the same time making sure the artifacts being shared are more secure, said Krüger. In addition, end users don’t have to be concerned about file size limitations imposed by file sharing services accessed via the cloud, noted Krüger.

    It’s not clear how many organizations are looking to centralize digital asset management within the context of an application development process, but the fewer places that artifacts reside, the more productive IT teams tend to be. At a time when the number of application development projects within many organizations has accelerated, there’s a lot more interest in reducing the number of steps any developer has to monitor and track.

    Diagrams and other types of artwork are not the only kinds of artifacts that are finding their way into software development processes. Data scientists are building massive artificial intelligence (AI) models that need to be incorporated into application development and deployment processes. The challenge organizations face is the individuals that create many of these types of artifacts lack the programming skills required to share them via version control platforms typically employed by developers.

    With the launch of Helix Sync, IT teams should assume that, going forward, Perforce will be expanding its overall content management capabilities, Krüger added.

    It’s not clear to what degree workflows will converge as application development continues to evolve. Organizations are starting to appreciate just how dependent they are on software. As that awareness increases, it’s only a matter of time before workflows start to converge around the software development process that are employed to drive multiple digital business transformation initiatives.

    With more of the creators of those artifacts working remotely, the security of those software supply chains has also become more critical. Cybercriminals are becoming more adept at compromising the credentials end users create to access a cloud file service. Software development teams are more likely to employ more rigorous forms of authentication.

    Arguably, there’s never been more artifacts to track during the history of application development than there are today. The thing that makes managing all those artifacts even more challenging is, just like every other piece of software, they are also being continuously updated in ways that aren’t easy to discern.

  • 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.

  • Survey Finds Digital Transformation Outcomes in Doubt

    Survey Finds Digital Transformation Outcomes in Doubt

    The COVID-19 pandemic forced organizations, both large and small, to either launch or accelerate digital business transformation initiatives that, to varying degrees, depend on their level of DevOps acumen to succeed. Value stream management platform provider Digital.ai today published the results of a survey of 200 IT decision makers, 200 security decision makers and 200 business executives in organizations with at least 500 employees which suggests that, while there’s a lot of confidence in those initiatives, the business outcomes those efforts are intended to enable are still very much in doubt.

    The survey finds 95% of respondents believe their digital transformation initiatives are going well, with 22% reporting they have been completed. Just under a third (32%), however, said they still have a lot to accomplish. Just under half (49%) said they have yet to see the results they expected. In fact, more than half of respondents (56%) also noted they are concerned about the return on investment (ROI) of those initiatives.

    Overall, the survey suggest optimism continues to prevail. A full 92% of respondents said they are creating new value for the business, with 93% claiming the business as a whole remains competitive. However, more than half (57%) are concerned that business, IT and security goals might be misaligned. More than half (54%) are concerned about meeting customer needs. Nearly two-thirds are concerned about software vulnerabilities.

    More challenging still, 94% of respondents need software development and delivery to be better aligned to business objectives. Only 54% claim to be strategically aligned. Almost every respondent (99%) needs more visibility into business planning processes, with just over a third (34%) noting they are not especially good at attaining that visibility.

    Not surprisingly, a full 91% said they still need more time to work on their digital business transformation initiatives.

    Derek Langone, head of strategic transformation for Digital.ai., said the survey makes it apparent there is a much greater need for a set of key performance indicators (KPIs) for IT teams that are tied to specific business objectives. As organization of all sizes realize how dependent they have become on software, any delay can have a major impact on revenue and profitability projections, noted Langone.

    Of course, not every digital business transformation project is going to succeed, no matter how optimistic business and IT leaders may be. Many initiatives were hastily conceived during the early days of the pandemic. Others were simply accelerated without enough due diligence. Digital.ai is making a case for a value stream management (VSM) platform that enables organizations to first understand the true status of these projects by synthesizing all the data residing in various DevOps platforms, and then assessing the impact any delays might have on the business.

    It’s not quite clear how many organizations have managed to get as far as they have without at least some VSM platform equivalent. However, as software development continues to become more complex, it’s also apparent that without a VSM capability, the odds various digital business transformation initiatives currently underway will eventually be derailed are substantially higher than many IT and business professionals would like to admit.

  • 1Password Extends Encryption to Automate Secrets Management

    1Password Extends Encryption to Automate Secrets Management

    1Password this week added a Secrets Automation platform to its offerings that enables IT organizations to more easily encrypt, manage and orchestrate credentials, application programming interface (API) tokens, keys and certificates.

    In addition, the company revealed it has acquired SecretHub, a provider of a separate secrets management tool. Terms of the acquisition were not disclosed.

    Carson Brown, senior product manager for 1Password, said the SecretHub team will now focus on the development of the 1Password Secrets Automation platform based on encryption technology previously created by 1Password.

    Finally, 1Password this week also announced an alliance with GitHub under which it will, at some future date, enable DevOps teams to employ SecretsHub to encrypt secrets used to access the source code repository. 1Password already provides integrations with HashiCorp Vault, Terraform, Kubernetes and Ansible, in addition to client libraries written in Go, Node and Python.

    The 1Password platform for managing and securing passwords is already in use by more than 80,000 businesses worldwide. The Secrets Automation platform now extends the reach of the company’s core encryption technology into the realm of DevSecOps best practices, said Brown.

    It’s still early in the cycle of DevSecOps best practices adoption, but it’s clear an initial focus will be secrets management. In the wake of recent high-profile breaches involving software supply chains, there’s now increased scrutiny of secrets management. Cybercriminals have become more adept at scanning for secrets left exposed as plain text. The challenge organizations face is that developers, while building applications, tend to copy secrets for the sake of convenience, which they often forget to delete after an application is deployed in a production environment.

    In response, many IT teams vacillate between overly restrictive and overly permissive access controls that are rarely implemented consistently.

    Of course, it’s now also only a matter of time before auditors start citing all those unencrypted secrets as compliance violations, Brown noted. A set of DevSecOps best practices based on automatic encryption of secrets eliminates those compliance concerns in a way that is transparent to application developers, noted Brown.

    It’s not immediately clear whether it will be DevOps teams that lead the charge to automate the encryption of secrets, or whether cybersecurity teams will take the lead. Regardless of which team assumes responsibility, the number of secrets that need to be tracked keeps expanding as the number of platforms employed increases. Manually keeping track of all those secrets is no longer feasible. Centralizing secrets management is the first step toward regaining control over an IT environment, said Brown.

    Secrets management may not always be the first thing that comes to mind when organizations begin their DevSecOps journey. As it turns out, however, securing secrets may very well turn out to be the first order of business as senior business and IT leaders review their entire software supply chain. After all, once it becomes apparent just how dependent organizations are on software, they quickly realize how much of their intellectual property is one compromised credential away from being stolen.

  • Agile Divide Between IT and Business Is Narrowing

    Agile Divide Between IT and Business Is Narrowing

    A global survey of 1,350 business and IT executives conducted by Jigsaw Research on behalf of NTT Ltd., a provider of IT services, suggests organizations are a lot more agile in the wake of the COVID-19 pandemic, but there’s still a significant gap in terms of prioritizing agility.

    A full 89% of business and IT leaders agree COVID-19 has caused significant changes to their operating processes, with 87% also agreeing it has accelerated their digital transformation strategy. A third of respondents (33%) also noted they pivoted their technology focus to take advantage of a market opportunity or scale their operations.

    However, well over a third of operational executives identified speed and agility as a core component of technology strategy, while only just over half of IT executives agreed (53%).

    Overall, the survey found there is a consensus IT remains a key enabler of business efficiency. A total of 91.4% respondents agreed that enabling business efficiency is a key driver for their technology strategy, with 92% of IT respondents saying their overall technology strategy is aligned either fully or partially with the organization’s business strategy needs.

    However, there’s a significant divide in terms of the importance of IT’s role in driving business efficiency. A technology strategy that drives business efficiency opportunities is seen as being most crucial by 70% of operations teams, yet only 48% of IT teams said the same.

    Sanjay Lakhani, a principal consultant for NTT and head of the IT service management (ITSM) practice for the Americas region said that while the alignment between business operations and IT is not as close as it could be, a lot of improvement has been made. Prior to the COVID-19 pandemic, the divide between IT and the rest of the business was generally wider, noted Lakhani.

    Now that more organizations are realizing how dependent they are on software, there’s a lot more focus on application development with business units, he added. There’s also more pressure on IT operations teams, which are being asked to keep pace with the rate at which digital business transformation initiatives have accelerated, added Lakhani.

    Unfortunately, the survey also highlighted an emerging technology gap. The survey found 92% of business and IT leaders agreed emerging technology is crucial for their technology strategy, but only two-fifths (41%) believed they have the technology to meet their organization’s immediate objectives. Those result suggest a significant transition is underway, both in terms of how software is constructed and the type of IT infrastructure required.

    In the meantime, it remains to be seen to what degree the COVID-19 pandemic has fundamentally altered the DNA of IT operations teams, but it’s apparent enterprise IT will never be the same. Most IT teams have embraced, to varying degrees, agile application development methodologies along with DevOps best practices. The challenge now is aligning the operational cadence IT teams follow with that of the rest of the business in the wake of the pandemic.

  • RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI announced it has added support for the open source Kafka messaging software as another type of application programming interface (API) that DevOps teams can centrally access.

    An open source library provided by RapidAPI, available in beta, makes it possible to discover Kafka clusters and topics, view schemas and test and consume records from a browser via either the RapidAPI Marketplace or the RapidAPI Enterprise Hub. The library is based on Apache Avro and Confluent wire formats found in the open source confluent-schema-registry library. RapidAPI extended that library to add support for JSON and a protocol buffer, which is now being shared with the open source Kafka community.

    RapidAPI CEO Iddo Gino said DevOps teams can now discover all available Kafka clusters and instances in the same location where they find, test and connect to microservices based on REST, SOAP and GraphQL APIs. That effort is designed to complement initiatives, such as the AsyncAPI specification, that is now being advanced under the auspices of the Linux Foundation, Gino noted.

    RapidAPI is adding this capability because usage of Kafka to enable asynchronous communication across event-driven applications has significantly increased, Gino said. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, Gino said reliance on asynchronous messaging platforms such as Kafka became a requirement. In many cases, synchronous communications across highly distributed applications simply isn’t feasible, Gino added.

    That doesn’t mean asynchronous requirements will replace the need for traditional synchronous APIs. Rather, developers will find themselves incorporating a greater mix of both as enterprise IT environments become more distributed, noted Gino. Applications are increasingly become one large puzzle that developers need to construct using various classes of APIs, added Gino.

    The library created by RapidAPI is expected to be generally available in the third quarter. In the meantime, adoption of Kafka continues to accelerate. The open source community that oversees development of Kafka, under the auspices of the Apache Software Foundation, claims more than 80% of all Fortune 100 companies are using the platform for everything from constructing data pipelines to running streaming analytics applications. In some cases, data is being queried directly while in transit versus waiting for it to be stored on-premises or in the cloud.

    Regardless of how Kafka is employed, developers are rediscovering event-driven architectures, that can trace their lineage to the 1980s, for building applications. The difference now is there an open source framework for handling the asynchronous communications required to build and deploy those applications at scale.

    It’s not quite clear how the rise of event-driven applications will impact DevOps workflows, as event-driven applications become more commonly built and deployed. However, as the APIs become more widely employed within the context of these applications, it should become simpler to incorporate them.

    The challenge is event-driven architectures typically requires developers to think differently about how their applications are structured, so it might be a while before Kafka – and other similar platforms – are pervasively employed across the enterprise.

  • Okta Adds Free Developer Edition to AppSec Service

    Okta Adds Free Developer Edition to AppSec Service

    Okta this week lowered the barrier to adoption of DevSecOps best practices by making available an Okta Starter Developer Edition to enable developers to embed Okta authentication, authorization and user management capabilities into applications at no cost for up to 15,000 monthly active users.

    Randall Degges, head of developer advocacy for Okta, said interest in identity management among developers is rising as a method for implementing zero-trust initiatives that better secure application environments. Rather than having to embed and maintain authentication and authorization themselves Okta is making a case for developers to invoke an application programming interface (API) to access a service that provides those capabilities on demand, noted Degges.

    The Okta Starter Developer Edition, announced at an online Oktane21 event, reduces the friction developers encounter as they look to embed identity management capabilities, such as multifactor authentication, into their applications, Degges said. Developers can, for example, access enhanced documentation and sample applications as well as new integrations with Kong, Heroku and Terraform platforms and tools, alongside integrations with multiple continuous integration and continuous delivery (CI/CD) platforms.

    In general, Degges said, the shifting of responsibility left toward developers is happening at a much faster rate because the level of appreciation for security among developers is now a lot higher. Identity management capabilities are simply another API that developers can now invoke as part of a DevOps workflow, noted Degges.

    The Okta Starter Developer Edition comes on the heels of the announcement of the acquisition of Auth0, a provider of authentication and authorization services that can be easily embedded within an application. That $6.5 billion deal, however, is not expected to close until summer.

    In the meantime, Okta is moving forward with the Okta Starter Developer Edition that could eventually create a large pool of applications that will one day consume Okta services for a fee as they scale. The more applications an organization deploys, the more likely it becomes that they will have more than 15,000 active users per month.

    In the meantime, the level of experimentation involving digital business transformation initiatives is likely to increase. Developers will be able to demonstrate to their often skeptical cybersecurity counterparts that their concerns have been addressed before an application is deployed in a production environment.

    It’s not clear what impact access to initially free identity management services might have on the adoption of DevSecOps best practices. In many cases, developers will take advantage of a service like Okta simply to address a requirement. Their appreciation for how that service fits within the context of a larger DevSecOps workflow might not be all that high.

    Nevertheless, the state of application security should improve in the months and years ahead. In fact, some developers may opt to update existing applications that, at present, do not meet zero-trust requirements to take advantage of identity management services that can be invoked via an API. Alternatively, the may also decide to replace authentication capabilities that are challenging for them to maintain and update with an API that calls a service. Regardless of the path forward, the historic divide between developers and cybersecurity teams appears to be finally narrowing.

  • Gitpod Revamps Dev Automation Tool

    Gitpod Revamps Dev Automation Tool

    Gitpod announced today it refreshed the dashboard for its namesake open source tool for automating the deployment of development environments, in addition to making Microsoft VS Code its default tool for editing code.

    In addition, Gitpod has included support for sudo privileges and Docker images using an advanced user namespace to map and limit access to workloads using a built-in Supervisor capability.

    Fresh off raising an additional $13 million in funding, Gitpod CEO Sven Efftinge said now that it’s clear developers will be working from anywhere for the foreseeable future, the need for a tool to automate setting up a developer environment on a local machine outside of an office has become more apparent.

    Gitpod claims there are now more than 350,000 developers using its tool that creates a Kubernetes pod on each developer machine to deploy a complete application development environment, including the integrated development environment (IDE), plugins, compilers, build tools, code generators, databases and application servers. Gitpod makes use of the version control systems provided within, for example, a continuous integration/continuous delivery (CI/CD) platform as the single source of truth for configuring an application development environment.

    The overall goal is to eliminate the time developers waste setting up application development environments so they can write code on their own machines. That approach also makes it simpler for developers to collaborate around the same application development environment regardless of where they happen to be physically located.

    Efftinge said Gitpod provides DevOps teams with a tool to automate setting up development environments across any Git repository that is the equivalent of the Codespaces tool that GitHub recently made available. Rather than having that capability for only one repository, Efftinge noted that most developers work on projects that span multiple types of repositories.

    Automating that process also makes it simpler to align development environments with production environments. One of the reasons why code doesn’t work in a production environment when it is first deployed is because the local development environment has been manually configured in a way that doesn’t accurately reflect the production environment. That issue can become even more problematic when developers are working on multiple projects involving, for example, separate microservices constructed using different repositories.

    In the wake of the COVID-19 pandemic and the acceleration of multiple digital business transformation initiatives there’s naturally a lot more focus on automation and developer productivity. Most developers will be working outside the office for the foreseeable future. Of course, most developers have been writing code outside the office for years. The challenge now is enabling teams of developers to develop applications as efficiently as possible, no matter where they are in the world. In fact, now that development teams have become more distributed, organizations are becoming more comfortable hiring developers wherever they find them.

    Eliminating inefficient manual tasks, such as maintaining development environments, is, of course, going to be a prerequisite for making it possible for those developers to, over time, navigate multiple application development projects without ever having met their colleagues in person.

  • Survey Sees Application Testing Shifting Further Left

    Survey Sees Application Testing Shifting Further Left

    PractiTest, a test management platform provider, published a report today that suggests professional application testers have become more adept at working within DevOps workflows.

    The annual survey of more than 1,000 application testing professionals finds that 80% of all application testing within organizations is being done by test engineers, test leads, testers and automation testers. A full 92% of survey respondents also noted they are working within the context of an agile methodology, while 42% cited DevOps specifically. Half of respondents said they work within the framework of a continuous integration/continuous delivery (CI/CD) platform.

    Significantly, more than half of respondents (59%) said testing is shifting left within their organization, but only a third (33%) said programmers participate in the testing process.

    PractiTest CEO Yaniv Iny said that level of DevOps inclusion suggests that, rather than shifting testing completely left on to the shoulders of application developers, a more nuanced approach to application testing is taking hold as professional testers learn to work within the sprints that make up a DevOps workflow. A full 90% of respondents said testing has become more automated within their quality assurance (QA) processes.

    By now, most application testers have come to terms with automation and, increasingly, AI, said Iny. The assumption now is that large swaths of the testing process will be automated, Iny added. A full 97% of respondents said that functional testing automation was either important or very important for them to succeed, while 96% said test automation patterns, principles and practices are also critical.

    Usage of behavior-driven development (BDD) as a testing model has also increased, with 27% of organizations now employing it to go beyond simply testing functions.

    However, the survey also found that, instead of automation decreasing the size of testing teams, those teams are getting larger. The number of organizations with 16 or more testers increased by 10% to 34% compared to a year ago. That suggests organizations are launching either more complex application development projects or launching multiple projects at the same time as they embrace digital business transformation initiatives, Iny said.

    The survey found nearly 70% of respondents have at least five years of experience. Nearly three-quarters (71%) of respondents reported that their income was not affected by the economic downturn brought on by the COVID-19 pandemic. However, nearly half of respondents (54%) reported that they were concerned about job stability, an increase of more than 30% from a year ago.

    The pandemic did change the way testers acquire new skills. The number of testers reporting that they attended online conferences, meetups and seminars increased to just under half (49.5%), up from 40.5% in 2019. Participation in online communities and forums grew to 44%, while only a third of respondents receiving any kind of formal training.

    Testing professionals with five to 10 years of experience earned an average salary of $89,000 in North America, which compares to $76,000 in Australia/New Zealand, the survey also found.

    Application testing as a distinct discipline doesn’t appear to be fading away anytime soon. Rather, organizations appear to be investing even more in testing to deliver higher-quality applications.