Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • 3 Performance Challenges as Chatbot Adoption Grows

    3 Performance Challenges as Chatbot Adoption Grows

    Today, many organizations are starting to use voice or text-enabled chatbots for the first time or already have chatbot systems in place. In fact, Gartner said 25% of organizations are predicted to make chatbots their primary customer communication channel by 2027. This is because consumer behavior has shifted to primarily digital interactions and away from traditional customer support channels.

    As a result of today’s digital landscape, consumers are now accustomed to immediate gratification and expect instant responses and resolution from customer support, which makes chatbots an ideal solution for brands to rapidly serve customers. Due to this rising demand for instant customer service, chatbot systems have become more sophisticated and consumers’ reliance on them is increasing. This increase in adoption has led to higher performance expectations for bots and if those expectations are not met, customer satisfaction and brand loyalty will suffer.

    Below, we’ll look at three major challenges tied to the growing popularity of chatbots as they handle larger and more diverse groups of customers, and how business leaders developers and DevOps and customer experience (CX) teams can tackle these common challenges with a continuous testing approach.

    The Pain Points of Adoption: 3 Key Challenges as Chatbot Usage Grows

    As the popularity of chatbots explodes for customers around the world, the underlying systems that handle natural language processing (NLP), latency, data security and other functions need to be stronger. This is due to a growing and increasingly diverse demographic of users, many of whom are sharing more of their personal information to address a wider range of customer needs. Common chatbot pain points can be summarized by three overarching challenges.

    Challenge #1: Chatbots must contend with a larger and more diverse base of customers

    Chatbots that are voice or text-enabled must be smart enough to operate securely while navigating countless variations in spelling, a wide range of spoken accents and vernacular, background noise, static from bad connections and more. Even in a single language, there may typically be only four or five “intents” from most customers in engaging a chatbot, but those intents may be phrased in hundreds of different ways. Now, the global growth in adoption raises the chance of poor connections and exponentially increases the number of languages and variations in phrasing that a chatbot must understand and interpret.

    Challenge #2: Customers are trusting chatbots with more personal and sensitive data

    As chatbots become smarter and more trusted by customers to meet their needs, people are getting more comfortable giving their personal data to chatbots. That increases the number of situations where chatbots are working with personally identifiable information (PII) or other highly sensitive data. Especially given GDPR and other data privacy regulations being enacted worldwide, there’s added pressure to ensure a chatbot system’s handling of this data remains secure and compliant across all use cases and geographic regions.

    Challenge #3: Modern chatbots require 24/7 availability and reliability

    In an era of flexible work and millennial and Gen Z audiences interacting with bots after business hours and on weekends, chatbots can’t afford to work in shifts. Users may be spread across many time zones or around the world, meaning there’s always a sizable portion of customers awake, online and looking for fast and efficient service. Because of this, chatbots must be able to handle spikes and heavy traffic 24/7.

    The executive takeaway from these challenges is that modern chatbot investments must be built around dynamic systems capable of adjusting to shifting customer usage and performance requirements.

    A Continuous Testing Mindset is Required for Top Chatbot Performance

    Fortunately, by honoring a few best practices and making the right strategic technology investments in automated artificial intelligence (AI) and machine learning (ML)-driven systems, C-suite leaders responsible for CX and the teams they manage can deploy chatbots capable of keeping up with the above challenges. Perhaps the most central element for success is to embrace a continuous testing approach.

    For example, when a company is undergoing digital transformation and shifting its contact centers and supporting systems to the cloud, they are moving a significant amount of data, reimagining complex integrations and rearchitecting processes. In order to maintain application stability and existing integrations in the contact center, continuous testing is critical to ensure that an organization’s systems still operate effectively throughout the cloud migration process. With continuous testing, development and testing aren’t separate processes. The testing is automated and quality assurance is involved as developers submit code.

    The most effective approach to continuous testing includes end-to-end analysis across all channels. Testing chatbot behaviors should mimic real-time customer interactions. This should include challenging scenarios such as unexpected user inputs and usage spikes at random times of the day and night. Automation is critical, especially in peak demand scenarios such as Black Friday, Cyber Monday, open enrollment, etc. Load testing up to 1,000-100,000 bot requests per second, or more, can help ensure companies will be able to handle the increased traffic. Ideally, the testing approach should be comprehensive to include automated NLP score testing, conversational flow testing and security testing and performance testing and monitoring.

    By promoting the continuous testing approach across contact center operations, executives can empower their teams to build and maintain chatbots that remain optimized on an ongoing basis and that form an essential part of providing exceptional CX. This will make a huge difference in performance and reliability as systems scale and adapt to the evolving demands of a growing customer base.

    Continuous Testing Elevates Chatbot Reliability and Value

    High-performing chatbots and the continuous testing that keeps them optimized at those performance levels can benefit any company by lowering risks and enhancing revenue. Organizations that become adept at applying continuous testing avoid 90% of the downtime from high-severity (SEV 1) errors, which can result in saving $2.2 million in costs over a three-year period. When continuous testing touches every stage of the development process, it identifies issues earlier and helps strengthen an organization’s ability to innovate faster and service its customers effectively and profitably.

  • How To Build Anti-Fragile Software Ecosystems

    How To Build Anti-Fragile Software Ecosystems

    Just as organisms are susceptible to diseases and viruses, software systems are susceptible to hacks and errors. And within many complex interconnected systems, a minor bug could have a cascading effect across an entire organism, causing it to break. As such, increasing the resiliency of a software ecosystem is something engineers continually strive for. But how do we get there?

    One concept to consider is anti-fragile. Being anti-fragile refers to the ability of a system to thrive in adversity and adapt to change. Specifically, with regard to software, anti-fragile can equate to responsive coding practices, such as auto-scaling or default backups, to mitigate unforeseen events. Chaos engineering, for example, is one method to expose edge cases and build with adaptability in mind. And with the introduction of intelligent automation, often fueled by machine learning (ML) and artificial intelligence (AI), it’s becoming more and more feasible to build anti-fragile software systems.

    I recently met with Asim Razzaq, co-founder and CEO of Yotascale and former head of platform engineering at PayPal, to discover what it takes to build anti-fragile software. According to Razzaq, anti-fragile represents the next evolution of reactive, resilient software systems. And introducing anti-fragile concepts into your application networks can be done with just a few (relatively) simple steps. Below, we’ll define what anti-fragile is and see how this concept can be applied to software development and DevOps.

    Understanding Anti-Fragile

    As the adage goes, “What doesn’t kill you makes you stronger.” And it’s true—many natural systems tend to thrive under inhospitable conditions. As described by Nassim Nicholas Taleb in the book ‘Antifragile: Things That Gain from Disorder,’ anti-fragile systems thrive in adversity. For example, consider how human muscle grows under stress and load. Immune systems similarly adapt and respond to new viruses and improve the body’s resilience over time. So, how does this relate to software development?

    Well, organizations need to develop highly-tolerant software systems to meet rising digital consumer expectations. Especially when under extreme loads, systems must be elastic to adapt and survive. To meet high user demands, as well as specific service-level objectives (SLOs) and agreements (SLAs), most software companies are already investing in cloud-native tools that improve reliability. For example, a hallmark of site reliability engineering (SRE) is introducing automation to enhance the stability of applications.

    One example of gauging anti-fragile in software environments is chaos engineering, says Razzaq. Chaos engineering is the act of throwing a wrench into the machine. You randomly introduce bugs and malformed requests and attempt to create as much havoc as possible to see what happens. This could mean pulling out cables and restarting servers to gauge how software systems respond.

    “Software that can respond the best adapts the best,” said Razzaq. For example, if you manually remove a few nodes from the cluster but the system knows it needs seven to function, it could automatically spin up additional nodes. Or if the whole cluster goes down, ideally, the system would automatically restart and scale to the necessary requirements. In essence, anti-fragile software systems can understand and adapt to new environments without much, or any, human input.

    Tips to Construct Anti-Fragile Software Systems

    So, how can we construct anti-fragile software systems — especially when real-world challenges are often unpredictable? Razzaq shared helpful advice to consider when crafting anti-fragile software architecture.

    1. Start With Your Most Critical Systems First

    First, introduce chaos engineering to your most absolute critical systems. Define these vital components at the heart of your product which must remain functional. For a payments processor SaaS, for example, this would be the infrastructure supporting its transactional engine, such as the login and payment microservices.

    2. Determine How to Test Fragility

    Once you’ve identified this critical infrastructure, figure out how to test for fragility in your environment. Introduce chaos engineering to the component to see how it behaves. For example, returning to our payment platform example, this may include switching off a payment transaction type to see how the system functions in an extreme scenario.

    3. Decouple Components

    If systems are too closely coupled, errors and outages can ripple across multiple software services. To avoid that, it’s a good practice to prevent tight coupling between components—especially between critical systems and non-critical ones.

    4. Introduce Alternate Paths

    One method to decouple is by introducing alternate paths. For example, if a credit card verification component goes offline, the system should naturally accept other forms of payment and automatically suggest another form, such as a bank transfer. If all systems are down, the system could still accept unverified payments in a queue and let this continue until the threshold reaches a certain risk level.

    5. Learn From Past Events

    The next frontier of designing anti-fragile architecture is developing self-learning, autonomous systems. Of course, there is a limit to how automation can respond to unforeseen issues. But by feeding a machine learning model with more and more experiences, it could deal with untested new scenarios more gracefully. Of course, AI has the potential to make harmful decisions and even introduce unintentional bias, so organizations should have accountability for the algorithms they oversee, cautioned Razzaq.

    Benefits of Building With Anti-Fragile in Mind

    The goal is to able to thrive and function even under duress. By identifying the elements of core infrastructure to keep alive and putting it through the wringer, you can discover frailties before they cause significant consequences. And by decoupling components and introducing alternate paths, software systems can be better equipped for whatever may come. Uplevelling system operations with increased automation and AI is likely the future of constructing more fault-tolerant applications.

    “Software is everything in this day and age,” said Razzaq. “It increasingly plays a critical role in life-enhancing capabilities.” As such, the end benefits of developing an anti-fragile style could have hugely positive effects. In health care situations, it could make a difference in saving lives. For other less dire scenarios, increased fault tolerance leads to less lost revenue during peak traffic times and more consistent end-user experiences.

  • Let the Machines Do It: AI-Directed Mobile App Testing

    Let the Machines Do It: AI-Directed Mobile App Testing

    AI has been in the news a lot lately. We’ve all heard a lot about ChatGPT and you’ve no doubt encountered the end result of a variety of other advances in AI technology of late, such as Lensa. But there’s also a much quieter and less visible shift happening behind the scenes during the development of your favorite apps—AI-directed mobile app testing. Let’s take a look.

    Behind the Scenes

    It’s no secret that every product, no matter the industry, goes through a gauntlet of tests before it’s unleashed on the general public. This goes for everything from a simple object like a cardboard box, for example, to a far more complex product, such as the latest electric vehicle.

    The same goes for the mobile apps on your phone. And if you haven’t given that much thought, then good! It means that the QA team behind the app’s functionality did its job, producing a seamless experience that functioned without a hitch, exactly as you wanted and expected.

    But that’s not always the way it goes, and mobile app testing is only growing more complex. That’s a growing problem that AI will eventually resolve.

    If your app didn’t perform as expected, you—and many other users like you—may delete it and move on to the next app that promises to do the same thing. While this may not seem like a big deal to you as the user, it’s a total disaster for the tireless teams working behind the scenes to ensure a successful app launch or update.

    The adage ‘You only get one chance to make a first impression’ is very true in the mobile app market. It’s a big, crowded and cutthroat mobile app world out there, and users simply have no incentive to put up with an app that doesn’t do exactly what it’s supposed to do. After all, for every single app, there are often several others standing by to scoop up your unhappy (former) users.

    This issue is by no means restricted to small development teams strapped for resources. I’m sure you can think of some high-profile software releases from major companies that have launched in a disastrous state over the past few years (particularly in the tremendously profitable arena of video games).

    So why is it that some teams cut corners when it’s time for testing, only to dearly wish they hadn’t?

    Well, the answer is pretty simple: Up until very recently, mobile app testing has traditionally been time-consuming, complex and bewildering, all too frequently delaying releases and flabbergasting QA teams.

    To understand this ongoing problem, let’s take a look at what this kind of mobile app testing entails and how this landscape has recently started to shift, as well as what’s on the horizon to make it all more efficient.

    Cutting Corners = Consequences

    Once upon a time—in an era that seems like it was really just yesterday—software testing was performed manually, entirely by hand. This was possible because quality assurance personnel only needed to consider a very limited set of variables: There were only so many use cases and form factors to consider, and programs were only expected to do so much.

    It’s hard to imagine testing a modern app manually and having the result be effective. The approach is only reasonable under very limited circumstances. Nowadays, teams use automated tests, which save them a tremendous amount of time, effort and resources.

    Yet these automated tests come with their own problems. Most of these automated tests are hand-coded, meaning that they must be set up and adjusted by specialists with a background in computer programming. Such specialists are not only costly and in demand, but they’re also needed for later aspects of the software development cycle, such as developing new product features and overseeing other aspects of production.

    And this is where companies start to cut corners and miss problems and issues, both large and small. Instead of what is known as shifting left (that is, testing as early in the cycle as possible), many teams, unfortunately, view testing as a burden or afterthought. Only when things go haywire and they have a full-blown crisis on their hands does the need for rigorous app testing become apparent.

    Testing, Machine-Made

    This is where machine learning and artificial intelligence enter the picture. For several years, we’ve known that testing performed by machines will be more and more necessary to handle increasingly complex apps, and it won’t be long before the cost associated with the complex testing scenarios will simply become too much for many developers.

    Fortunately, advances continue to appear on the horizon. These include the much-discussed no-code revolution, which abstracts away much of the noise associated with software development and opens the door to a much wider testing base.

    AI- and machine-learning-based testing is also on the horizon, yet there’s a significant challenge that must be overcome before this can happen at speed and scale. To develop mobile app tests with true intelligence and maximum efficiency, machines must be capable of autonomously completing the following steps:

    1. Comprehension: Draw from the ability to understand what’s changing in an app. For example, the machine must be able to detect differences and issues in a signup sequence or a checkout screen change.
    2. Impact analysis: The machine must know what test cases can cover that change. This sort of identification can be quite tricky.
    3. Test case generation: Next, the machine must possess the ability to generate test cases related to steps one and two. To do this, the machine must draw from several data sets. These include:
      1. Extent test collateral/test cases with product code
      2. Data from actual customer usage so that numbers one and two above may be identified
      3. What user environments look like, including information like how many users are active in the United States and in Europe
      4. Automatic execution: Perhaps the most crucial need is that the machine can perform testing entirely by itself. With the ability to self-execute tests, we’ll have reached a new era in testing.
      5. Reports: Before the testing cycle can begin again, the machine must be able to produce detailed reports that make sense to its human handlers. When it comes to test results, the more detail the machine can provide in as approachable a manner as possible, the better.

    Problems and Solutions

    Some testing platforms are now capable of many of the tasks I highlight above, and quality assurance teams that move away from self-coding tests and toward the future of testing stand to benefit from these solutions (particularly when their competitors do not).

    Partially enabled by AI and ML, no-code solutions provide a stopgap solution until machines can really get a handle on the above five steps. At this point, it’s really just a matter of time: We can already see glimpses of a wholly automated testing cycle where human input is limited and machines do the heavy lifting.

    It’s easier than ever to imagine a world where there’s no need for testing to be an afterthought and software disasters have become a thing of the past.

  • Harness Acquires Propelo to Surface Software Engineering Bottlenecks

    Harness Acquires Propelo to Surface Software Engineering Bottlenecks

    Harness this week announced it has acquired Propelo, a provider of an analytics tool that identifies bottlenecks in software engineering processes. Terms of the acquisition were not disclosed.

    The Propelo offering will be made available as a module, dubbed Harness Software Engineering Insights, that organizations can choose within the company’s overall continuous integration/continuous delivery (CI/CD) platform.

    Scott Sanchez, chief marketing officer for Harness, said Propelo is unique in that all the integration required to collect data from a wide range of DevOps platforms is already baked into the tool. As a result, DevOps teams can instantly collect telemetry data from not just the Harness platform but also CI/CD platforms such as Jenkins, GitLab and Azure. In addition, there are integrations with more than 40 third-party tools, such as the Jira project management software from Atlassian.

    Those integrations enable the Harness Software Engineering Insights module to surface insights aligned with the DevOps Readiness Assessment (DORA) metrics from Google and the satisfaction, performance, activity, communication and efficiency (SPACE) frameworks.

    In an uncertain global economy, there is more focus than ever on increasing the productivity of DevOps teams, noted Sanchez. More organizations are going to be reluctant to hire as many full-time employees as they once did, so more attention is being paid to getting the most out of existing investments, he added.

    That focus on productivity will naturally lead to a re-examination of workflows to identify bottlenecks in DevOps workflows that, if eliminated, would help increase the pace at which software is being developed, said Sanchez. In some instances, the software development life cycle (SDLC) processes companies are using are as much as 20 years old, he noted.

    The acquisition of Propelo is the latest addition to a portfolio of DevOps tools designed to be deployed alongside existing platforms, noted Sanchez. Organizations that have been using platforms such as Jenkins are not going to rip and replace overnight, he added. The Harness portfolio is designed to be deployed alongside existing platforms to enable organizations to modernize their DevOps workflows in a much less disruptive way than rival DevOps platforms, said Sanchez.

    Harness initially developed a CD platform before acquiring Drone to add a complementary CI capability. It then acquired ChaosNative to add a chaos engineering tool, based on the LitmusChaos open source tool, that is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    It’s not clear how quickly organizations will modernize legacy DevOps platforms. Still, in many cases, workflows and pipelines that were designed for a different era of application development are not able to support the pace at which modern cloud-native applications are being developed. It will, of course, be up to each DevOps team to determine whether adding additional DevOps tools and platforms makes economic sense; application developers tend to naturally gravitate toward organizations that reduce as much development friction as possible.

    In an era where organizations are counting on developers to drive digital transformation initiatives, the underlying DevOps tools and platforms employed to build applications can easily make the difference between success and failure.

  • Why Can’t We Be Friends? Improving Developer-Tester Alignment

    Why Can’t We Be Friends? Improving Developer-Tester Alignment

    Sometimes coding can be such an art form that it deserves to be a masterpiece in a museum. Developers are proud of their code—at least until the so-called art critics (aka testers) step in with their critiques. And then the rapport can swiftly become as messy as a painter’s palette. You have probably seen this scenario play out time and again at your organization. In the mad dash of a software release, the relationship between developers and testers can quickly become stressful and strained. And while your teams know about helpful tools that can streamline collaboration, you may not be aware of other steps you can take that go beyond the screen to ensure an even better developer-tester relationship.

    Full disclosure: At my organization, we’re in the software testing business and we’re not playing favorites when it comes to testers versus developers. We’ve just learned a thing or two about what makes a happy collaboration for all the parties involved. And we’ve seen that organizations that improved their developer-tester alignment not only accelerate a smoother release cycle but also leave no hard feelings on the table for the next time.

    Leave the Keyboard, Take the Cannoli

    Developers and testers will find that if they move their interactions away from the keyboard, they’ll discover that sweet spot of improved communication and transparency. Whether at your daily standup, over a cup of coffee or by simply picking up the phone, spending a few minutes chatting can address miscommunications before they become major problems that can delay your release.

    If something seems off, bring it up as early as possible. Take, for example, the classic case of missed requirements. One of our customers recently shared a story with us that really hit home. At the top of the sprint, a particular user story included only seven acceptance criteria–which caught the attention of one of the developers. He pointed it out in a conversation with the testers and business analysts on the project. Together, the group identified four additional acceptance criteria missed during the initial scoping.

    Without that conversation, the team would have assumed those seven acceptance criteria were the only ones that tests needed to be written against. A number of defects would have slipped into production, and it wouldn’t have been the software developers’ or the testers’ fault. Instead, the testing team realized significant gaps in test coverage and their test plan grew from seven to 40 test cases.

    The takeaway? Make sure that developers, testers and business owners are clear on how business requirements align with what software developers plan to build, as well as how testers plan to test against them. Have this conversation before the sprint begins—and don’t forget the cannoli.

    You Complete Me: In-App Test Management

    “I love documenting test plans in spreadsheets!” said no one, ever. All that manual work just takes time, introduces errors and leads to frustrations among developers and testers who have to go digging for the information they need. Adding a Jira app, for example, for test management can be the key to completing the alignment between teams.

    In-app test management gives both teams real-time data for decision-making and collaboration with built-in reporting on testing. That means that software testers can fully plan, design, track, and analyze testing activity within the same workflows that developers and testers are already using. For developers, there’s no need to ask testers for status updates or results. And testers can quickly see how tests align to requirements, which helps them brainstorm additional tests and provides developers better context and information to develop around.

    The cherry on top? The entire team can maintain true traceability between requirements and test coverage, which both minimizes finger-pointing and ensures that everyone has a clear picture of what’s required before the release is ready to ship.

    There’s an Awful Lot you can Tell About a Person by Their Software

    As Mama always said, shoes tell where someone is going and where they’ve been (mic drop, Forrest). By talking the talk and walking the walk in a counterpart’s shoes, developers and testers can better understand each other’s worlds. In-app test management can give developers a window into the tester’s thought process, because it shows them not only test status but also how a tester arrived at a particular defect. After gaining this familiarity, developers may be more open to inviting testers to sit in on traditionally dev-focused activities.

    Take unit testing or code reviews, for example. Most QA teams tend to steer clear. But by joining in, testers can ask questions and grasp which pieces will be validated at the unit, integration, and functional levels. A bonus is that testers get an inside look at the codebase, helping them develop more technical knowledge, as well as collaborate with developers on how the unit tests they plan to run–gasp!–fit into the overall picture of quality and release readiness.

    Remember, the true purpose of QA is to provide information that verifies that the application works well enough to be put in front of customers. By understanding the testing that’s going on at the unit level, QA can be more efficient by focusing on what’s not being covered in unit tests.

    The result? A more cohesive, effective test plan and a release that the whole team–developers, testers and business owners–can be proud of. In other words, a release masterpiece.

  • Devs Increasingly Rely on IaC to Manage Multiple Clouds

    Devs Increasingly Rely on IaC to Manage Multiple Clouds

    A survey of more than 300 DevOps professionals conducted by Firefly, a provider of a platform for automating cloud provisioning, found that more than a third of organizations (36%) have allocated the equivalent of two or more full-time engineers per month to writing infrastructure-as-code (IaC) templates.

    A full 82% are also deploying the templates within the context of a DevOps pipeline, with 68% reporting more than half of their cloud instances are now managed using IaC tools, according to the survey. A total of 27% reported they are now managing every aspect of IT as code.

    The challenge is that 61% of respondents also admitted they can’t automatically detect configuration drift over time, with more than a third (35%) spending days or weeks remediating IaC templates. Well over half of respondents (56%) said they are also retrofitting existing cloud instances using IaC tools.

    Cindy Blake, vice president of marketing for Firefly, said this issue is likely to become more challenging to address as the number of clouds in use continues to increase. The survey found 44% of respondents already use multiple cloud providers. Overall, 42% reported having more than 10 cloud accounts.

    The top IaC benefits identified by survey respondents are improved efficiency (75%), increased reliability (55%) and easier compliance (52%) and simpler troubleshooting (49%).

    Not surprisingly, the survey identified knowledge (46%) followed closely by complexity (43%) as the top challenges organizations face when using code to manage cloud infrastructure. Factors increasing complexity included cost and complexity (70%), followed by security (61%).

    In addition, only 14% of respondents reported that all their engineers are IaC literate. More than a third (36%) said they only have one IaC-literate engineer. As a result, many organizations are now attempting to navigate IaC bottleneck issues that could be alleviated if they relied more on automation that can be integrated within a continuous integration/continuous delivery (CI/CD) platform, noted Blake. She added that many organizations are already allocating too much engineering time to manually writing IaC templates.

    Those manual efforts often result in misconfigurations that are easily exploited by cybercriminals, added Blake. Many developers using IaC tools such as Terraform have had little to no cybersecurity training, so the odds they will make a mistake are high.

    At a time when more organizations are focused on the productivity of DevOps teams and ensuring the integrity of software supply chains, there is a clear need to automate processes that increasingly span multiple clouds. More organizations than ever are employing multiple clouds to ensure application availability in the wake of a series of outages over the past few years, Blake said.

    Regardless of the motivation, multi-cloud computing is here to stay. Developers opt for different clouds based on the performance capabilities they can provide for various classes of workloads. There may be one cloud platform that runs the bulk of the workloads, but the number of organizations that have standardized on a single cloud are comparatively few. The issue is finding the best way to manage multiple clouds that doesn’t require as much manual effort so organizations can reduce the total cost of managing IT environments.

  • Broadcom Survey Reveals Spike in VSM Adoption

    Broadcom Survey Reveals Spike in VSM Adoption

    Value stream management (VSM) is gaining traction as organizations look to find ways to engage customers more efficiently via digital business transformation initiatives.

    A survey of 500 executives, IT and business leaders conducted by Dimensional Research on behalf of Broadcom published this week found 39% of respondents implemented a VSM platform with another 16% having some equivalent capability. Another 31% said their organizations is moving in the direction of adopting a VSM platform. A total of 60% of respondents indicated that they will be using VSM to deliver products in 2023, with 95% of organizations that have adopted VSM also engaged in digital transformation.

    Laureen Knudsen, chief transformation officer for Broadcom, said the primary goal is to close the divide that has emerged over the years between software development teams and the rest of the business. More than two-thirds of respondents (68%) reported there are disconnects between the business and software development.

    Overall, the Broadcom survey identified increasing customer value (58%), improving product quality (55%), reducing costs (51%), adding more customers (50%, increasing profits (49%) and increasing speed to market (45%) as the top strategic issues organizations face in 2023.

    The top benefits derived from investing in VSM were increased transparency (42%), improved organizational alignment (39%), faster solutions to customers (38%), data-driven decision-making (37%) and improved access to data (36%).

    VSM traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved and organizations realize how dependent they are on software, there is a growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business. At their core, VSM platforms aggregate DevOps metrics and then match them to a set of key performance indicators (KPIs) defined by business leaders. Once those metrics are gathered and correlated, organizations can apply advanced analytics. The goal is to apply algorithms and other forms of predictive analytics that will enable organizations to more easily identify the precise impact software development processes have on the business.

    Knudsen said the survey makes it clear a lack of discipline when it comes to software engineering now needs to be addressed as organizations realize how dependent they are on applications to engage customers. Many organizations have, for example, adopted flawed approaches to agile development that wind up creating chaos across the software development life cycle, she noted.

    Many organizations, for example, are unsure how much time development teams are spending on retiring the technical debt accrued within legacy applications versus actually working on developing new applications, Knudsen added.

    Business conditions tend to change rapidly, so aligning software development with corporate goals is difficult. Nearly three-quarters (72%) of respondents said they are frustrated by the state of the business and constant changes to strategy. Digital business transformation initiatives, however, will require organizations to adopt a more structured approach to software engineering, said Knudsen.

    The issue, of course, is the pace at which businesses are already being digitally transformed. The accelerated pace requires almost immediately re-engineering software development processes for them to succeed.

  • The Time for Automated Testing is Now

    The Time for Automated Testing is Now

    Skilled software testers continue to be in high demand, and it appears that trend won’t change any time soon. The current labor shortage and a looming recession is giving software development leaders good cause to think about how to attract and keep qualified personnel and, more importantly, enable them to work as efficiently as possible. Added to this scenario is a trend in the software development cycle toward shift left testing, which has put increased pressure on developers to take on testing responsibilities that often require taking on new perspectives and using new tools. Automated testing solves these problems by making it easier to learn how to build a consistent, reliable testing program in less time, requiring less maintenance.

    Add to this the future promise of artificial intelligence or AI-augmented testing platforms and current machine learning (ML) capabilities, such as self-repairing of test scripts, and you have a platform that both levels the learning curve and accelerates efficiency. The sooner organizations can transition from manual to automated testing, the better they can withstand internal and external market fluctuations.

    A Developer and a Tester Walk Into a Bar …

    Traditional software testing is a manual process in which testers are employed to replicate users and are expected to bring that perspective to their work. As such, software testers have a very different mindset than software developers. Where developers are protective of their creative output, software testers are driven by a curiosity to probe the limitations of a system. It stands to reason that the qualities that make someone excel at either of these roles is, likewise, not the same. And yet, with the trend toward shift left testing and continuous integration/continuous development (CI/CD), the industry has blurred the distinction between coder and tester to the dismay of both sides.

    Automated testing removes much of the monotonous work associated with repetitious test plans. It allows testers to focus on writing better scripts, extending the scope of their testing plans and scheduling more powerful load tests. From the organization’s perspective, once you have established a library of reusable test scripts, your testing program will be protected from future turbulence in the employment market, including recession and attrition.

    Low-Code/No-Code

    Regardless of the tool you use, code will be created if you are creating software — even test scripts. Ideally, however, a low-code/no-code tool can hide some of the complexity and promote best practices. Using a low-code/no-code tool can relieve a tester from creating test scripts from scratch by recording manual interactions and offering suggestions. In the case of shift left testing, a low-code tool can eliminate the need to learn entire testing frameworks while still enabling a developer to access code when desired. Automating testing also eliminates the human error inherent in repetitive manual tests. In short, test automation does not diminish the value of skilled software testers and developers; it increases it.

    Placed in the hands of skilled testers, automated testing will only become more powerful, more effective and more critical to your development cycle. It elevates the skills of testers and makes them more productive, accurate and thorough. Test automation also makes for a smoother transition to shift left testing, allowing developers to spend less time testing their software and more time doing the creative work that makes them thrive. In a market where attracting and keeping top talent is only going to get more difficult, anything you can do to lighten the burden on your employees and make them more productive will be a big win for your business. So, the question is not whether you should transition from manual to automated testing but when.

  • Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    20 Years of Neglect Led to ‘Meltdown’

    Last month’s débâcle of canceled flights was caused by decades of technical debt. That’s the analysis of Columbia University professor Zeynep Tufekci. (more…)

  • Best of 2022: Agile/Scrum is a Failure – Here’s Why

    Best of 2022: Agile/Scrum is a Failure – Here’s Why

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to The Long View—where we peruse the news and strip it to the essentials. Let’s work out what really matters.

    This week, something a bit different: I’m devoting my entire column to Agile and Scrum. They’re increasingly getting a bad reputation, being associated with the worst aspects of toxic workplace culture: Sexism, racism, burnout, micromanagement. (more…)