Author: Coty Rosenblath

  • Generative AI and Software Testing Tools to Manage Technical Debt

    Generative AI and Software Testing Tools to Manage Technical Debt

    It is easy to take a pessimistic view of generative AI and large language models (LLMs), especially when a growing list of AI experts and public figures have voiced concern about their potential to lead to dire consequences—even to human extinction. But we must also consider how these same technologies might mitigate these risks. There is no doubt that we are living in an accelerated cycle of technological progress and repercussions. However, the intelligence, speed and agility of AI—and particularly machine learning (ML)—may be just what we need to roll with the punches.

    As the speed of development outpaces our ability to mitigate potential risks posed by the systems we build, we are set on a path to accruing massive technical debt—the ever-increasing costs associated with modernizing code later rather than sooner. Too often, organizations in the private and public sectors are reluctant to pay off this debt, choosing an “if it ain’t broke, don’t fix it” mentality toward software maintenance and security. The problem is that as technology outgrows and outpaces our critical infrastructure systems, the potential for catastrophe escalates.

    Machine Learning: A Tool for the New “Space Race”

    Automated testing has proven superior in regression testing, especially in visually recognizing potential issues at the pixel level. If, for example, an important element of your interface is missing from the screen after an update, a visual test script can identify that faster than a human can. AI (and in particular, machine learning) generates test plans that provide more comprehensive coverage of the system under test and more practical coverage.

    Traditional testing methods usually begin with a broad and hypothetical analysis of user interactions. Test engineers begin by casting a wide net to cover the many possible user engagement scenarios they imagine. In contrast, AI-assisted systems learn from actual user interaction, building script libraries that focus on known points of weakness and vulnerability. It also does this at speed and scale. This technology is going to be essential to software test engineers as they inevitably find themselves unable to keep up with the abundance of code generated from LLMs using traditional testing methods.

    Technical Debt is Inevitable but not Unsolvable

    Every new iteration of software has the potential to introduce unforeseen problems ranging from glitchy bugs to catastrophic failures. The risks of releasing new software vary immensely between applications: It’s one thing if the latest release of your music streaming app crashes and quite another if the system that runs the regional power grid fails. One will result in unhappy customers; the other, the potential loss of life.

    The most critical systems (e.g., financial, transportation, safety, medical) are more likely to get frozen in time. Once a stable iteration is released, companies are generally not keen to make changes unless absolutely necessary—beginning the cycle of technical debt accumulation that grows until that debt is paid off by modernizing the code.

    Deciding when to pay off technical debt has always been a matter of weighing pros, cons, costs and benefits. But sometimes, such as in the case of an epic failure, that decision is forced. Both the risk of breaking the system and the cost of modernization compel developers to leave well enough alone. Meanwhile, the longer a system remains unchanged, the more isolated, outdated, and obsolete it becomes, setting the stage for failure.

    By introducing generative AI technology to the development stack along with other tools for authoring, compiling and testing software, developers will soon find themselves driving in the fast lane. With the security of knowing that code can be produced rapidly and released safely, owners of aging legacy systems will be more likely to modernize software sooner, helping them to pay off technical debt more quickly. That, in turn, could lead to increasingly rapid software development and release cycles, more work for developers, and more innovation. Such a workflow could very well become the embodiment of accelerating change, taking us from an “if it ain’t broke, don’t fix it” mentality to one where we anticipate the need for new code and avoid future catastrophic failures, or for that matter, human extinction.

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

  • Adopting Shift Left Testing in Software QA

    Adopting Shift Left Testing in Software QA

    I am often asked to recommend best practices for building software testing programs. The problem is that it depends on your definition of “best.” What works for an innovative startup developing software and deploying agile development sprints is not necessarily going to suit an established public company launching a new web product. The software development industry is so broad and diverse that there is no one-size-fits-all set of practices I can recommend. Put simply, the “best practices” are those that produce consistent results over time, meaning that they can be standardized. There has been a trend toward shift left testing in the past decade, and I have a few suggestions for getting the most out of development teams taking on this new responsibility.

    Shifting Left Testing Supports Agile Software Development

    “Shift left testing” means testing software for functional quality during the development phase, rather than waiting for the QA testing phase within the traditional software development cycle. Back when software was packaged for sale and deployment rather than delivered as a service, there was time in the development cycle for a dedicated QA phase. Developers started with a concept, analyzed their requirements and came up with a design before beginning to write the code. Once written, the software code would be integrated within existing systems (if needed) and then the software would be passed on to the QA team. Any bugs were sent back to development to be fixed and sent through the cycle again. All of these phases represented a conceptual move from left to right.

    Shift left is a departure from this cycle in which developers test their own software in an effort to speed up the process. This kind of development works particularly well for dev teams engaged in agile development. By having developers test their software as they go, bugs can be identified earlier in the development process, which saves time and resources and enables more thorough testing.

    Shift Left is Also Problematic

    There are some significant problems with the Shift left method that can’t be ignored. Specifically, developers are being asked to perform functions they were never properly trained to do—and often have no real interest in doing.

    Software developers are creative people by nature. Whether self-taught or formally trained, the majority of them have come to their positions in pursuit of creating something. Quality assurance testing, by contrast, is a destructive process. The goal of the QA engineer is to break things—kicking the tires and carefully documenting their destruction. And when you ask your creators to become destroyers, it doesn’t always go well.

    We can’t fault developers for not wanting to find faults in their code. Just as the best builders are not the best demolition experts, software developers want to create and then move on from one project to the next. So their reluctance to engage in testing is understandable. It’s part of who they are. The truth is that most developers find testing a monotonous chore. We need to learn how to encourage and incentivize them to become good testers of their own code.

    Provide an Encouraging Environment

    The first step toward making developers better testers is to educate them on the importance of testing as part of the development process. They may initially think that you’re only interested in saving money on hiring QA testers, or that they are being asked to perform the work of two employees. Introduce shift left testing as an integral part of the development process, explaining that continuous early testing is key to building high-quality software. By putting testing within the context of elevating software quality, developers will become more engaged in the process, raising the stakes and their involvement in projects.

    Make Software Testing Easier for Your Developers

    Since testing is not likely to be the primary interest of your developers, simplifying the task is going to make it at least more palatable to them. Test automation tools can be a big part of this strategy. Automated test scripts can be run flawlessly, frequently, and with much greater load capacity than with manual testing. You’ll be able to scale your tests to mimic a single user, or thousands of concurrent users, to discover how your software holds up under high demand. Pixel-for-pixel aberrations and errors in your graphic user interface (GUI) can be analyzed more quickly and effectively than with manual testing.

    Automated testing also takes much of the monotony out of testing, preventing burnout and resentment among your employees. Writing scripts also has the benefit of being, inherently, a creative, not destructive, process. By integrating the running of scripts into the normal workday of the developer, and emphasizing their value in building the best software possible, testing becomes a valued task, rather than a mindless chore.

    Providing Other Incentives

    When you adopt shift left testing, you just might be asking your developers to take on a role that they don’t enjoy as much as coding. And they may never enjoy it as much. But that doesn’t mean there aren’t actions you can take. If you want to keep your most valued developers happy and encourage them to stay with you, think about providing other incentives that make the entire job package irresistible. Make your company a great company to work for. From the working environment to other perks and compensation, any way you make your team happy can help them manage integrating new responsibilities.

    Testing Tools Lighten the Load

    As test automation technology gets more sophisticated, testing tools that incorporate aspects of artificial intelligence technologies to assist in test script generation and self-repair will play a larger role in enabling your developers to focus on the more creative aspects of the job — addressing design requirements and functionality (the “what” and “why” factors) in novel ways, and leaving more analytical, procedural tasks (the “how” factor) up to the tools. As testing tools perform more of the monotonous tasks for us, and with greater accuracy, developers will have more time for the creative tasks that keep them happy. These technologies are evolving as we speak and will address many of the issues described above. But you might still want to consider buying some doughnuts for the break room.