Ai-driven method and system for autonomous software test management during software lifecycle

Abstract

A method and system for autonomous test case management of a software application using artificial intelligence. The method includes generating natural language statements associated with testing of the software application based on user actions performed by a user on an interface of the software application using a trained visual language model, and generating a plurality of test cases corresponding to the test case scenarios using a first trained artificial intelligence model. The method includes identifying one or more defects associated with the software application based on execution of the plurality of test cases using a second trained artificial intelligence model and managing one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is ready to be shipped.

Description

AI-DRIVEN METHOD AND SYSTEM FOR AUTONOMOUS SOFTWARE TEST MANAGEMENT DURING SOFTWARE LIFECYCLECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority from the Indian Provisional Application No. 202441078767 titled “AI-DRIVEN METHOD AND SYSTEM FOR AUTONOMOUS SOFTWARE TEST MANAGEMENT DURING SOFTWARE LIFECYCLE” filed on October 17, 2024, the contents of which are hereby incorporated by reference in their entirety for all purposes.TECHNICAL FIELD

[0002] The present disclosure generally relates to the field of software lifecycle management, and more particularly to a method and system for artificial intelligence-driven autonomous software test management during software lifecycle.BACKGROUND

[0003] With the increasing reliance on software in our daily lives, delivering high-quality products has become essential for software companies to meet consumer demands. Software development follows a continuous lifecycle, consisting of multiple stages such as planning, development, testing, deployment, and maintenance. Among these stages, testing is critical and needs to be an ongoing, integrated process across all phases of the software lifecycle. A rigorous and continuous testing process directly influences the overall quality of a software product, ensuring that the software product meets user expectations and performs reliably in a real-world environment. A continuous integration (CI) process in a software lifecycle is depicted in FIG. 1. A software development environment 102 is an environment in which software development takes place based on a user requirement. The software development includes writing code and modifying code in a programming language. Once the software code is ready, it is committed to a source control system 106 for versioning and collaboration with other team members. The source control system 106 manages and tracks changes to the codebase. When developers commit their code changes, it is stored and versioned in the source control system 106. Commonly known examples of source control systems are GitHub, GitLab, and Bitbucket.

[0004] The CI server 104 fetches latest code changes from the source control system 106 to automatically build and test a software application. The CI server 104 automates the process of building and testing the software application. The CI server 104 periodically fetches the latest code from the source control system 106 and triggers the build process, where the application is compiled and prepared for testing. After building the software application, the CI server 104 automatically runs a test suite to ensure that the new software code does not introduce bugs or break existing functionality. The results from the tests (pass / fail) are generated by the CI server 104 and sent back to the software development environment to inform the software developers of any issues or bugs in the new code. If the tests fail, the software developers may fix the issues and recommit the updated code, restarting the CI process. This workflow represents a standard continuous integration setup, where code changes are continuously built and tested, ensuring that the software remains stable and reliable as it evolves. The process also accelerates bug detection, improves code quality, and allows developers to get immediate feedback on their changes.

[0005] Thus, in the case of modern software development, ensuring comprehensive and efficient testing is a critical challenge. Traditional approaches to test case design, execution, and defect management often rely on manual processes, which are time-consuming, error prone, and limited in their ability to achieve full test coverage. Human-driven test case generation may miss important scenarios, while manual execution and defect detection lead to delays in identifying and addressing issues. As a result, defects can remain hidden, reducing the overall quality, safety, and reliability of the software application.

[0006] Additionally, ensuring the safety of software products has become increasingly important, especially in sectors such as healthcare, automotive, aerospace, and financial services, where software failures / malfunctions can have serious consequences. Safety-critical systems require rigorous testing from time to time to identify potential hazards, validate that the software application performs reliably under various conditions, and mitigate risks associated with defects that could lead to system malfunctions or security vulnerabilities.

[0007] The growing complexity of software systems and the dynamic nature of development environments exacerbate the difficulty in maintaining consistent test coverage and adapting to changes in the software application. Post-deployment, systems may often lack real-time monitoring and adaptive testing mechanisms, making it challenging to continuously track user behaviour and ensure that all potential defect and safety-related paths are covered. Re-testingfixed defects may add an additional burden to manual processes, delaying the release of stable and safe software versions.SUMMARY

[0008] A method and system for autonomous test case management of a software application using artificial intelligence are disclosed. In one aspect, a method includes generating natural language statements associated with the testing of the software application based on a plurality of user actions performed on a graphical user interface (GUI) of the software application by a user using a trained visual language model. The natural language statements are generated corresponding to one or more test case scenarios. The method includes generating a plurality of executable test cases corresponding to the test case scenarios using a first trained artificial intelligence model based on the natural language statements associated with the testing of the software application, and identifying one or more defects associated with the software application are based on execution of the plurality of test cases using a second trained artificial intelligence model. The method includes managing one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is rendered ready for shipment.

[0009] In generating natural language statements associated with testing of the software application, the method may include capturing multiple GUI images and a user interaction log in response to the plurality of user actions performed by the user on the GUI of the software application and generating at least one semantic graph consisting nodes and edges based on the GUI images and the user interaction log using the trained visual language model. The nodes correspond to the GUI elements and the edges correspond to the user interactions.

[0010] In generating the plurality of test cases corresponding to the test case scenarios, the method may include generating, using the first trained artificial intelligence model, one or more of temporal or topologically ordered sequence of interactions based on an analysis of the semantic graph using the first trained artificial intelligence model, and capturing local and global dependencies of the plurality of nodes and edges of the semantic graph. The method may include generating a plurality of test cases in a natural language based on the captured local and global dependencies and the generated sequence of interactions using the first trained artificial intelligence model.

[0011] In identifying the one or more defects associated with the software application, the method may include identifying executable test actions associated with the test scenariosby parsing a plurality of test cases in the using a fourth trained artificial intelligence model and converting the identified test actions into a plurality of machine-executable commands capable of testing the software application on a test execution platform. The method may include executing the plurality of machine-executable commands within a software application environment using the test execution platform and identifying the one or more defects in the software application by analysing execution logs and runtime artifacts of the executed machine-executable commands using the second trained artificial intelligence model.

[0012] The method may include determining a failed element of a test step of a failed test case during execution based on execution of the machine executable commands in the software application environment and analysing a plurality of images of the graphical user interface using the second trained artificial intelligence model. The method includes predicting an alternate element in the GUI corresponding to the failed element using the second trained artificial intelligence model based on pattern recognition and semantic similarity between the failed element and candidate elements in the GUI, modifying the test step of the failed test case using the predicted alternate element in the GUI, and executing the modified test case using the second trained artificial intelligence model.

[0013] The method may include determining defects that have transitioned to a resolved state by interfacing with one or more defect tracking systems and verifying an availability of a software build containing the defect fix by analysing build artefacts and metadata from a software management system. The method may include automatically identifying a set of regression test cases associated with the resolved defects based on a graphbased representation of the software application and performing regression-based impact analysis using the third trained artificial intelligence model based on a probability of being affected by the defect fix.

[0014] The method may include executing the prioritised subset of regression test cases using a test execution module and generating a regression test report comprising test results, regression summaries, traceability updates, and audit logs that include user credentials and timestamps.

[0015] In another aspect, a system for autonomous test case management of a software application using artificial intelligence is provided. The system may include a processing unit and a memory coupled to the processing unit. The memory includes an autonomous test management platform configured to generate natural language statements associated with testing of the software application based on a plurality of user actions performed by a user on a graphic user interface (GUI) of the software application using a trained visual languagemodel. The natural language statements correspond to one or more test case scenarios. The autonomous test management platform configured to generate a plurality of executable test cases corresponding to the test case scenarios using a first trained artificial intelligence model based on the natural language statements associated with the testing of the software application, and identify one or more defects associated with the software application based on execution of the plurality of executable test cases using a second trained artificial intelligence model. The autonomous test management platform configured to manage one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is ready to be shipped.

[0016] In generating the natural language statements associated with testing of the software, the autonomous test management platform configured to capture multiple GUI images and a user interaction log in response to the plurality of user actions performed by the user on the GUI of the software application, and generate at least one semantic graph comprising nodes and edges based on the GUI images and the user interaction log using the trained visual language model, wherein the nodes correspond to the GUI elements and the edges correspond to the user interactions.

[0017] In generating the plurality of test cases corresponding to the test case scenarios, the autonomous test management platform configured to generate one or more of temporal or topologically ordered sequence of interactions based on an analysis of the semantic graph using the first trained artificial intelligence model. The autonomous test management platform configured to capture local and global dependencies of the plurality of nodes and edges of the semantic graph and generate a plurality of test cases in a natural language based on the captured local and global dependencies and the generated sequence of interactions using the first trained artificial intelligence model.

[0018] In identifying the one or more defects associated with the software application the autonomous test management platform configured to identify executable test actions associated with the test scenarios by parsing a plurality of natural -language test case descriptions using a fourth trained artificial intelligence model and convert the identified test actions into a plurality of machine-executable commands capable of testing the software application on a test execution platform. The autonomous test management platform configured to executing the plurality of machine-executable commands within the software application environment using the test execution platform and identifying the one or more defects in the software application by analysing execution logs and runtime artifacts of the executed machine-executable commands using the second trained artificial intelligence model.

[0019] In identifying the one or more defects in the software application using the second trained artificial intelligence model, the autonomous test management platform configured to determine a failed element of a test step of a failed test case during execution based on execution of the machine executable commands in the software application environment and analysing a plurality of images of the graphical user interface using the second trained artificial intelligence model. The autonomous test management platform configured to predict an alternate element in the GUI corresponding to the failed element using the second trained artificial intelligence model based on pattern recognition and semantic similarity between the failed element and candidate elements in the GUI, modify the test step of the failed test case using the predicted alternate element in the GUI and execute the modified test case using the second trained artificial intelligence model.

[0020] In managing one or more defects associated with the software application, the autonomous test management platform configured to determine defects that have transitioned to a resolved state by interfacing with one or more defect tracking systems and verify the availability of a software build containing the defect fix by analysing build artefacts and metadata from a software management system. The autonomous test management platform configured to automatically identify a set of regression test cases associated with the resolved defects based on a graph-based representation of the software application. The autonomous test management platform configured to generate a prioritised regression test suite using the identified set of regression test cases using the third trained artificial intelligence model based on a probability of each test case being affected by the defect fix, execute the prioritised regression test suite, and generate a regression test report comprising test results, regression summaries, traceability updates, and audit logs that include user credentials and timestamps.

[0021] In yet another aspect, a non-transitory computer-implemented storage medium that stores machine-readable instructions, that when executed by at least one processing unit, cause the processing unit to perform a method described above.

[0022] Therefore, the features and advantages of the present disclosure may be appreciated from a review of the following detailed description of the present disclosure, along with the accompanying figures in which like reference numerals refer to like parts throughout.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings illustrate the various embodiments of systems, methods, and other aspects of the disclosure. It will be apparent to a person skilled in the artthat the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element shown as an internal component of one element may be implemented as an external component in another, and vice versa.

[0024] Various embodiments of the present disclosure are illustrated by way of example, and not limited by the appended figures, in which like references indicate similar elements:

[0025] FIG. 1 is a block diagram of an example of a software lifecycle;

[0026] FIG. 2A is a block diagram illustrating an example system of an Al-driven autonomous test management during a software lifecycle, according to one embodiment;

[0027] FIG. 2B is a block diagram illustrating an automated test management platform of the Al-driven autonomous test management system, according to one embodiment;

[0028] FIG. 3 is a block diagram of a data processing system for Al-driven autonomous software test management during the software lifecycle, according to one embodiment;

[0029] FIG. 4 is a block diagram of a data processing system for Al-driven autonomous test case management during the software lifecycle, according to one embodiment;

[0030] FIG. 5 is a block diagram of a data processing system for Al-driven autonomous test case management during the software lifecycle, according to one embodiment;

[0031] FIG. 6A is a process flowchart depicting an exemplary method for test management during the software lifecycle, according to one embodiment;

[0032] FIG. 6B is a process flowchart depicting an exemplary method of defect retesting and regression testing, according to one embodiment;

[0033] FIG. 7 illustrates a screen associated with an example graphical user interface (GUI) associated with the automated test management platform, according to one embodiment;

[0034] FIG. 8 illustrates a screen associated with an example graphical user interface (GUI) associated with the automated test management platform, according to one embodiment; and

[0035] FIG. 9 illustrates a screen associated with an example graphical user interface (GUI) associated with the automated test management platform, according to one embodiment.

[0036] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of embodiments is intended for illustration purposes only and is, therefore, not intended to necessarily limit the scope of the disclosure.DETAILED DESCRIPTION

[0037] Examples described herein may provide an Al-driven autonomous software test management during the software lifecycle. Various embodiments are described with reference to the drawings, wherein like reference numerals are used to refer the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident that such embodiments may be practiced without these specific details.

[0038] The terms “software application”, “application”, and “software system” are used interchangeably throughout the document.

[0039] The terms “graphic user interface (GUI)”, “user interface (UI)”, and “interface” are used interchangeably throughout the document.

[0040] The terms “test management platform,” “platform,” and “test platform” are used interchangeably throughout the present disclosure and refer to the same or functionally equivalent system or component unless expressly stated otherwise.

[0041] In the present disclosure, a method and system are provided for an Al-driven autonomous software test case generation, execution, and defect management during the software lifecycle. The system is capable of autonomously generating software test cases, ensuring maximum test coverage, automating test case execution, and managing defects using artificial intelligence based on a zero-code product philosophy.

[0042] FIG. 2A illustrate a block diagram illustrating an embodiment of a computing environment 200 in which certain embodiments can be implemented, according to one embodiment. FIG. 2A illustrates an exemplary computing environment 200 for implementing an autonomous test management system. The computing environment 200 includes a network 210 communicatively coupling an automated test management platform 220, a software management platform 230, a continuous integration / continuous deployment (CI / CD) platform 250, and one or more end-user devices 240 operated by users 242.

[0043] The example computing environment 200 depicted in FIG. 2A includes a network 210 over which various network-connected computing devices and systems arecapable of communicating with each other. Network 210 can include a single distinct network or can include a collection of distinct networks operating wholly or partially in conjunction to provide connectivity between network-connected computing systems. For example, network 210 may include one or more of a wired or wireless local area network (LAN), a wired or wireless wide area network (WAN), a cellular data network, or any other appropriate communication network. Further, the one or more networks can include open networks (e.g., the Internet) and / or private networks (e.g., an intranet and / or an extranet). Communication between network-connected computing systems over network 210 may be over any known communication protocol or model such as the Internet Protocol Suite (i.e., TCP / IP), the Open System Interconnections (OSI) model, the User Datagram Protocol (UDP), the File Transfer Protocol (FTP), etc.

[0044] The automated test management platform 220 may include one or more server computer systems 222 with processing capabilities for performing embodiments of the introduced technique. The automated test management platform 220 may also include non- transitory processor-readable storage media or other data storage facilities for storing instructions that are executed by a processing unit and / or storing other data utilized when performing embodiments of the introduced technique. The server 222 executes one or more artificial-intelligence-based modules configured to perform natural-language test case generation, autonomous execution, defect analysis, and regression management.

[0045] For example, the automated test management platform 220 may include one or more data storage 224 for storing data related to autonomous software test management. Data storage 224 may represent any type of machine-readable instructions capable of storing structure and / or unstructured data. Data stored in the data storage 224 may include, for example, requirement data, semantic graphs, natural language test cases, automation scripts, execution logs, defect and coverage analytics, regression mappings, model training datasets, configuration or integration metadata, etc. Note that the term “data storage” is used for illustrative simplicity to refer to data storage facilities, but shall be understood to include any one or more of a database, or a data repository.

[0046] While FIG. 2A illustrates a single server computer system 222 and associated data storage 224, many implementations may employ two or more server computer systems 222 and / or data storages 224. Further, the server computer systems 222 depicted in FIG. 2A may represent physical computing devices and / or virtualized devices instantiated at one or more physical computing devices at a single physical location or distributed atmultiple physical locations. Similarly, data store 224 may represent multiple data stores, each of which may be distributed across multiple physical computing devices.

[0047] The software management platform 230 (e.g., Jira, Azure DevOps) maintains application requirements 232 and defect reports representing functional and non-functional specifications of a software application under test. The automated test management platform 220 may access the application requirements 232 and defect reports from the software management platform 230 via the network 210 to derive test design inputs, validation objectives, and defect reproduction scenarios. Based on the retrieved application requirements 232 or defect reports, the automated test management platform 220 may automatically generate a plurality of test cases, test scenarios, or automation scripts using one or more trained artificial intelligence models.

[0048] The automated test management platform 220 may be fully integrated with other brownfield environments including existing enterprise ecosystems. In various embodiments, such integration may include, but is not limited to, integration with requirements tools, planning tools, defect management tools, and continuous integration / continuous deployment (CI / CD) tools. It should be understood that the specific tools or environments described herein are merely illustrative, and the disclosed system may interoperate with any equivalent or alternative software management ecosystem.

[0049] The continuous integration and continuous deployment (CI / CD) platform 250 (e.g., GitHub, Jenkins, or GitLab) may manage software build pipelines and deployment workflows, including one or more application versions 252 corresponding to compiled or packaged releases of the software application. The automated test management platform 220 may interface with the CI / CD platform 250 to automatically trigger test execution on the deployed application versions 252, retrieve build artifacts and metadata, and perform regression and impact analysis based on code or configuration changes. The application version 252 may be associated with a graphical user interface (GUI) configured to receive user inputs and present visual outputs for interaction and monitoring purposes. The GUI of the CI / CD platform 250 may be accessible through various computing devices such as end-user devices 240, including desktop computers, laptop computers, server systems, smartphones, tablet computers, wearable devices, augmented reality (AR) or virtual reality (VR) devices, or any other computing device capable of communicating with the network 210. The application version 252 may be accessible via a web browser, desktop application, mobile application, or over-the-top (OTT) application, or any other type of application at the user device 240.

[0050] FIG. 2B illustrates a block diagram of an automated test management platform 220 of the autonomous software test management platform, according to one embodiment. The automated test management platform 220 may include a generation module 202, an execution module 204, and a defect management module 206.

[0051] The generation module 202 is configured to automatically generate test case designs in a natural -language. The generation module 202 is configured to use a visual language model to operate as both a guide module 212 and an assistant module 214 for generating natural language statements corresponding to a plurality of test scenarios associated with the software application. The visual language model is trained to analyse software requirements, user stories, and captured user interactions from one or more graphical user interfaces (GUIs) and generate natural language statements corresponding to the plurality of test scenarios for the software application.

[0052] In one embodiment, a user (e.g., human or a bot) may interact with the software application. The generation module 202 captures series of interactions in the form of screenshot images and / or as a video. During execution, the user performs one or more operations on graphical user interface (GUI) of the software application. Each interaction with a GUI element is recorded in real time. Each GUI element may correspond to a specific functional type such as a text or input field for data entry, a clickable button for triggering an event or navigation, a drop-down list for selection, a checkbox for enabling or disabling a parameter, a hyperlink or API call link for invoking backend processes, or any other interactive control element displayed within the interface. In one embodiment, the GUI element may initiate a backend call or connect to another linked page.

[0053] Each performed function or event is translated into a corresponding naturallanguage statements describing the action. For example, “User enters email address,” “User clicks Submit button,” or “System retrieves data from API endpoint.” The natural-language statements are sequentially stored as part of an interaction log within the data storage 224.

[0054] The generation module 202 extracts visual and textual components of the software application from the captured images and / or video frames. The trained visual language model encodes the visual and textual components of the software application into a semantic graph containing nodes which represent GUI elements and edges which represent user interactions or action flows. Each node is characterized by a node embedding vector that captures the visual, spatial, and textual attributes of the GUI element, while edges are represented as interaction embedding describing the contextual relationship and event type between nodes. Using the generated semantic graph, the trained visual language modelanalyses topological and temporal relationships between the nodes and the edges to extract patterns of user interactions, and outputs natural language statements corresponding to various test scenarios of the software application based on the topological and temporal relationships.

[0055] The generation module 202 generates one or more test cases in natural language by applying the generated natural language statements corresponding to various test scenarios to a first trained artificial intelligence model. In an exemplary implementation, the first trained artificial intelligence model may be a transformer model. The transformer model is a deep learning model which is specifically trained to generate test cases in natural language corresponding to test scenarios for the software application using large datasets. For example, the transformer model may encode the natural language statements corresponding to the test scenario into sequence of vectors using a self-attention mechanism (i.e., by learning relationship between words in the natural language statements). The transformer model may decode the sequence of vectors into test cases in a natural language using a self-attention mechanism and recurrent neural network (RNN).

[0056] In some embodiments, the transformer model is configured to generate new test cases based on requirement coverage gaps and recommend variations of existing test cases, including negative, boundary, and exceptional flows. For example, when the guide module 212 receives requirement from the test management platform 220 and determines that a particular set of test cases relating to a part of the requirement received were missing, the guide module 212 may suggest additional test cases to the user, enhancing test coverage.

[0057] In other embodiments, boundary test cases (i.e., comer test cases) which are missed by the user while preparing the test cases for the software application under test. In an example, if a requirement specifies an input field accepting integer values between 1 and 100, the guide module 212 may detect that boundary values such as “0” or “101” were not covered in the existing test cases. In response, the guide module 212 may recommend additional boundary test cases to verify the system’s response to these out-of-range inputs, ensuring that both functional and robustness testing objectives are adequately addressed.

[0058] The assistant module 214 is configured to update existing test cases in response to changing requirements or execution feedback of the software application, and to maintain traceability between generated test cases and originating requirement identifiers. The changing requirements may include adding, modifying, or removing features from the software application.

[0059] The execution module 204 is configured to autonomously execute a set of generated test cases associated with the software application. The execution module 204 isconfigured to generate executable test actions by parsing the plurality of test cases in natural language using a fourth trained artificial intelligence model. For example, the execution module 204 implements a trained transformer model to transform the test cases in natural language corresponding to the test scenarios for the software application into executable test actions. The execution module 204 converts the executable test actions into a plurality of machine-executable commands. The execution module 204 executes the plurality of machineexecutable commands within the software application environment using the test execution platform.

[0060] In some embodiments, the execution module 204 includes a guide module 216 and an assistant module 218. The guide module 216 implements a fourth trained artificial intelligence (Al) model to dynamically execute test scripts, monitor runtime outcomes, and perform self-healing operations in response to detected test failures. The guide module 216 is configured to execute machine executable commands that have been generated and prioritized during regression testing based on an analysed impact area of the relevant tests, and to generate a prioritized execution plan accordingly.

[0061] The assistant module 218 is configured to receive a predefined set of planned test cases either from a user or from the guide module 216 and to execute such test cases. The planned test cases may include time of execution of test cases. The assistant module 218 is configured to execute the test cases in the defined time. For example, the time of execution may be scheduled, pipelined using the CI / CD platform, and immediate execution at the same instant. The scheduled test cases may be executed at the scheduled time. The pipelined test cases are executed at regular interval and the test cases are kept in a pipeline till the time of execution arrives.

[0062] The defect management module 206 is configured to identify defects in the software application using a second trained artificial intelligence model. In an exemplary implementation, the defect management module 206 is configured to determine a failed element of the software application based on execution of the machine-readable commands in the software application environment, and analysing a plurality of images of the graphical user interface using the second trained artificial intelligence model. For example, the second trained artificial intelligence model may be supervised learning model such as classification model which classify log entries post execution of the machine-executable commands corresponding to test cases into pre-defined defect type. The supervised learning model may compare the outcome of the machine-executable commands from the log reports with the requirements ofthe software application and output a probability of outcome being a defect corresponding to a test scenario of the software application based on the comparison.

[0063] The defect management module 206 is configured to manage defects associated with the software application using a third trained artificial intelligence model. The defect management module 206 may include an assistant module 226 implementing a second trained Al model to analyse execution outcomes, identify test case failures, and generate defect reports. The defect reports may include test coverage and automation coverage metrics. The defect management module 206 is configured to autonomously verify resolution of software defects encountered in real-time while the software application is being used by one or more users, thereby ensuring post-fix stability and continuous quality assurance of the software application. During execution of test cases, the defect management module 206 may operate with either synthetic data or live data, depending on the testing context and deployment stage.

[0064] In conventional systems, one synthetic data representing simulated, artificially generated datasets is predominantly used for training and validating models, as it mimics user behaviour and operational conditions without exposing real production data. However, such synthetic environments often fail to capture the full variability and edge-case scenarios that occur in live production use. In contrast, in the present invention, live data collected from actual software usage is utilized in conjunction with or as an enhancement to synthetic datasets, thereby significantly improving the realism, depth, and quality of the test cases generated. The incorporation of live data allows the autonomous test management platform 220 to continuously learn from real operational behaviour, improving the adaptability, precision, and relevance of the generated test cases beyond the limitations of conventional synthetic data- based models.

[0065] The defect management module 206 may include an assistant module 226, which implements the third trained artificial intelligence (Al) model to determine and execute appropriate re-testing or regression operations. When one or more defects are transitioned into a “fixed” state within a defect tracking platform, such as JIRA, the assistant module 226 is configured to retrieve current defect state from the defect tracking platform and verify that the defect has been marked as fixed based on metadata or status information maintained in the defect tracking platform. The assistant module 226 verifies that a new build package including corresponding defect fix is available from a build management or CI / CD platform. Upon confirmation of build availability, re-test agent either coordinates with CI / CD tools to trigger a re-test operation or initiates an autonomous execution sequence in cases where such CI / CD facilities are not available.

[0066] The assistant module 226 is configured to automatically identify and fetch test cases associated with the defect under test from a test case repository and execute the same on the new build. The automation performed by the assistant module 226 significantly reduces the need for manual intervention that is typically required in conventional systems for defect verification and regression testing. In addition to executing the directly associated test cases, the assistant module 226 employs Al-based correlation and graph-based dependency analysis to identify related regression test cases that may be indirectly impacted by the applied defect fix. The assistant module 226 performs targeted regression testing on these related areas to ensure that no unintended side effects have been introduced due to the defect fix. The neighbourhood of the element corresponding to the fixed defect is analysed to determine related components, functions, or modules that could be affected. The test cases related to the determined components may be executed using the guide module 216. The combined use of Al models and graph-based analysis allows selective regression testing, thereby improving efficiency and accuracy of the re-testing process while maintaining comprehensive test coverage.

[0067] In operation, the automated test management platform 220 provides an end-to- end intelligent testing framework, where outputs from the generation module 202 are supplied to the execution module 204 for autonomous test execution, and execution results are analysed by the defect management module 206. This closed-loop architecture enables a self-sustaining, adaptive, and autonomous test lifecycle with minimal human intervention.

[0068] FIG. 3 is a schematic representation of a data processing system 300 for AI- driven autonomous software test management during software lifecycle, according to one embodiment. Particularly, the data processing system 300 includes a cloud computing system 302 configured for providing cloud services for Al-driven autonomous test management during software lifecycle.

[0069] The cloud computing system 302 includes a cloud communication interface 306, cloud computing hardware and OS 308, and a cloud computing platform 310. The cloud communication interface 306 enables communication between the cloud computing platform 310 and user devices 312A-N, such as a smartphone, tablet, computer, etc. via a network 304.

[0070] The cloud computing hardware and OS 308 may include one or more servers on which an operating system (OS) is installed and includes one or more processing units, one or more storage devices for storing data, and other peripherals required for providing cloud computing functionality. The cloud computing platform 310 is a platform that implements functionalities such as test case generation, test case execution, defect management,visualization of defects on the cloud hardware and OS 308 via APIs and algorithms, and delivers the aforementioned cloud services using cloud-based applications (e.g., autonomous software testing application).

[0071] The cloud computing platform 310 employs the generation module 202 configured to generate a plurality of test cases in natural language based on project requirements and natural language statements from user interactions using a first trained artificial intelligence (Al) model. The generation module 202 may include monitoring module for monitoring the functioning of a software system and generating natural language statements indicating functioning of the software application using a trained visual language model.

[0072] The cloud computing platform 310 employs the execution module 204 configured to execute the generated test cases on the software application under test using a fourth trained artificial intelligence model. The cloud computing platform 310 may employ the defect management module 206 for identifying defects in the software application during the software lifecycle using a second trained artificial intelligence model. The cloud computing platform 310 may employ the defect management module 206 for managing the defects associated with the software application suing a third trained artificial intelligence model. The cloud computing platform 310 may include a combination of dedicated hardware and software built on top of the cloud hardware and OS 308.

[0073] The user devices 312A-N include graphical user interfaces 314A-N for receiving a command to test the software system in a test environment. For example, the graphical user interfaces 314A-N may visualize defects to a software developer. Also, the graphical user interfaces 314A-N may visualize natural language statements related to monitored functionality of the software system. The user devices 312A-N include graphical user interfaces 314A-N for accessing a functionality of the software system. Each of the user devices 312A-N may be provided with a communication interface for interfacing with the cloud computing system 302. Users of the user devices 312A-N may access the cloud computing system 302 via the graphical user interfaces 314A-N.

[0074] FIG. 4 is a block diagram of a data processing system 400 for Al-driven autonomous test management during the software lifecycle, according to another embodiment. The data processing system 400 includes a server 402 and a plurality of user devices 406A-N. Each user device of the plurality of user devices 406A-N is connected to the server 402 via a network 404 (e.g., Local Area Network (LAN), Wide Area Network (WAN), Wi-Fi, etc.). The data processing system 400 is another implementation of the data processing system 300 ofFIG. 3, where modules 202 to 206 reside in the server 402 and are accessed by user devices 406A-N via the network 404.

[0075] The server 402 may also include a processor, a memory, and a storage unit. The server 402 may also include a communication interface for enabling communication with client devices 406A-N via the network 404.

[0076] FIG. 5 is a block diagram of a data processing system 500 for Al-driven autonomous test management during the software lifecycle, according to yet another embodiment. The data processing system 500 may be a personal computer, workstation, laptop computer, tablet computer, and the like. In FIG. 5, the data processing system 500 includes a processing unit 502, a memory 504, a storage unit 506, a bus 508, an input unit 510, and a display unit 512. The data processing system 500 is a specific purpose computer configured for Al-driven autonomous test management during the software lifecycle.

[0077] The processing unit 502, as used herein, may be any type of computational circuit, such as, but not limited to, a microprocessor, microcontroller, complex instruction set computing microprocessor, reduced instruction set computing microprocessor, very long instruction word microprocessor, explicitly parallel instruction computing microprocessor, graphics processor, digital signal processor, or any other type of processing circuit. The processing unit 502 may also include embedded controllers, such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, and the like.

[0078] The memory 504 may be non-transitory volatile memory and non-volatile memory. The memory 504 may be coupled for communication with the processing unit 502, such as being a computer-readable storage medium. The processing unit 502 may execute instructions and / or code stored in the memory 504. A variety of computer-readable instructions may be stored in and accessed from the memory 504. The memory 504 may include any suitable elements for storing data and machine-readable instructions, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read-only memory, a hard drive, a removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like.

[0079] In the present embodiment, the memory 504 includes the generation module 204 configured to generate a plurality of test cases based on project requirements and natural language statements using a first trained artificial intelligence (Al) model. The memory 504 includes the execution module 204 configured to execute the generated test cases on a softwareapplication under test using a second trained artificial intelligence model. The memory 504 includes the defect management module 206 for tracking defects in the software system during the software lifecycle using a third trained artificial intelligence model. Method acts performed by the processing unit 502 to achieve the above functionality are described in greater detail in FIG. 6A and FIG. 6B

[0080] The storage unit 506 may be a non-transitory storage medium that stores a test database for storing test results. The input unit 510 may include input devices such as a keypad, touch-sensitive display, camera (e.g., a camera receiving gesture-based inputs), etc. capable of receiving input signals. The display unit 512 may be a device with a graphical user interface displaying test results. The bus 508 acts as an interconnect between the processing unit 502, the memory 504, the storage unit 506, the input unit 510, and the display unit 512.

[0081] FIG. 6A is a process flowchart 600A depicting an exemplary method for test management during the software lifecycle, according to one embodiment of the present disclosure. FIG. 6A and FIG. 6B may be referred to collectively as FIG. 6, for clarity of illustration. Methods 600A and 600B correspond respectively to the embodiments shown in FIG. 6A and FIG. 6B, and together they form portions or variations of an overall method 600.

[0082] The process 600A represents an end-to-end autonomous workflow performed by the autonomous test management platform 220, which is operatively integrated with external systems, including but not limited to a software management platform and a CI / CD platform through secure network interfaces.

[0083] At step 602, application requirements are retrieved from the software management platform through secure Application Programming Interfaces (APIs), webhook connections, or data synchronization mechanisms. The retrieved information may include functional and non-functional requirements, user stories, acceptance criteria, dependency relationships, and associated test reports. The requirements data serve as the foundation for subsequent test generation, ensuring alignment between business objectives and testing intent.

[0084] In one embodiment, a semantic graph representation is generated from the captured requirements and user interaction data. Each node in the semantic graph corresponds to a software feature, component, or graphical user interface (GUI) element, while edges represent logical relationships, user interactions, or event dependencies among these nodes. The semantic graph is normalized into machine-readable tokens that are processed by the VLM or the Al model within the autonomous test management platform 220, enabling semantic understanding and contextual mapping of software behaviour.

[0085] At step 604, the source code of the software application under test is obtained from the CI / CD platform. The source control platform may be configured to further maintains build pipelines, deployment artifacts, and versioned repositories containing metadata such as build identifiers, timestamps, and repository branches. The specific version of the source code corresponding to the current testing cycle is identified and transmitted to the autonomous test management platform 220 for further analysis and validation.

[0086] At step 606, test case scenarios and corresponding test cases are generated using the retrieved requirements, semantic graphs, and user interaction data. A first trained artificial intelligence (Al) model, such as a transformer-based or hybrid sequence-learning model, converts structured requirement data into natural -language executable test scripts. The generated test cases encompass positive, negative, boundary, and exceptional flows, ensuring comprehensive functional and behavioral validation. The Visual Language Model (VLM) interprets GUI components to generate semantic associations, while temporal and logical dependencies are analyzed by the sequence-learning model. The fused outputs of these models yield structured test cases comprising preconditions, test steps, expected outcomes, and verification conditions, all expressed in a human-readable yet machine-executable format.

[0087] At step 608, the generated test cases are executed on the autonomous test management platform, functioning as a test execution platform. This operation is controlled by the Execution Module 204, which utilizes a trained Al model to manage orchestration, monitor runtime behaviour, and detect anomalies or execution failures. During this process, execution metrics such as pass / fail status, execution time, and environment parameters are captured and stored for post-execution analytics.

[0088] At step 610, a test execution report is generated, summarizing the test outcomes, logs, and defect occurrences. The execution report is automatically transmitted to the CI / CD platform, updating the continuous integration pipeline with the latest validation results to maintain synchronization across development and testing environments.

[0089] At step 612, a decision is made to determine whether any failed test cases are detected. If no failures are identified, the process advances to step 626, where the application is marked as successfully tested. If failures are detected, the process proceeds to step 614 for further defect analysis.

[0090] At step 614, the failed test cases are analysed by an Al-driven defect identification model. This model examines execution logs, captured UI screenshots, and event traces to identify probable causes of failure. For instance, when a UI element cannot be located during execution, the platform initiates a self-healing process utilizing a pre-trained VisualLanguage Model (VLM) and HTML locators to attempt correction based on visual and contextual cues.

[0091] At step 616, graphical user interface (GUI) screenshots corresponding to the failed tests are analysed using the visual language model (VLM). The VLM determines an alternate element locators (for example, HTML locator) or workflow patterns by leveraging semantic correlations and spatial analysis. The proposed locator or workflow may be verified to determine accuracy by execution of the test case with the determined locator or workflow. If the alternate locator found is correct, the process proceeds to step 624. If not, the process proceeds to Al healing using an Al model.

[0092] When the initial self-healing process fails, a pre-trained Al model trained on historical UI data is employed. At step 618, the pre-trained Al model is trained on the visual snapshots of the UI associated with the failed test step. The Al model is a pre-trained model that is configured to interpret graphical layouts and recognise interface components in a manner analogous to human visual understanding. During this process, the Al model captures the spatial coordinates corresponding to the target object within the UI. The captured coordinates are then transmitted to the Document Object Model (DOM) structure of the application under test. The DOM stores the information relating to each element and the address of the elements. The DOM is traversed to identify and map the UI element located at the specified coordinates. This enables accurate identification of the visual component that caused the test failure and facilitates subsequent correction.

[0093] In an Al-based self-repair process, the artificial intelligence model interprets the UI visually using a visual language model (VLM), observes the screen layout to determine the element of interest, and identifies its alternate locator. Based on these coordinates, the corresponding element is fetched and validated within the DOM hierarchy.

[0094] At step 620, an alternate locator for the failed object is identified using the trained artificial intelligence model and DOM information. The alternate locator is then verified by executing the test case with the determined alternate locator. If determined correct, the process proceeds to step 624. If the determination is incorrect, the system checks for an updated test suite within the CI / CD platform at step 622 created by an expert test in case the self-healing and the Al healing does not work.

[0095] At step 624, the test cases are automatically modified based on the identified alternate locator or workflow. This may involve updating the test automation scripts, adjusting interaction coordinates, or modifying UI element references to restore functional accuracy.

[0096] At step 626, the CI / CD platform is updated with the modified test cases. The updated test cases are sent to the appropriate repository branch, enabling the next build and deployment process to include the corrected elements.

[0097] At step 628, the execution results and defect patterns are fed back to the multiple Al models utilized throughout the process to improve subsequent test prediction, defect correlation, and healing capabilities. This feedback loop ensures the system evolves through continual learning.

[0098] At step 630, once all test cases have been successfully executed and validated, the software application is marked as ready for release. The system thus achieves a fully autonomous test lifecycle that integrates requirement analysis, test generation, execution, defect healing, and regression verification without human intervention. Upon successful verification and feedback, the software application is determined to be “Ready to Ship,” completing the autonomous test lifecycle. The feedback-driven loop ensures end-to-end automation, from requirement interpretation, test generation, execution, and healing without requiring manual intervention, thereby accelerating release velocity and improving test reliability.

[0099] FIG. 6B is a process flowchart 600B depicting an exemplary method of defect re-testing and regression, according to one embodiment of the present disclosure.[000100] At step 632, changes in the codebase or software application builds are monitored by the autonomous test management platform 220. The platform is configured to detect updates in the source code, configuration files, or build artifacts associated with the software application under test. In some embodiments, the monitoring is performed continuously as the autonomous test management platform 220 is integrated with a continuous integration / continuous deployment (CI / CD) environment hosting the source code repository. The platform may further analyse build metadata or notifications generated by the CI / CD system to determine whether a new build containing code updates or defect fixes has been generated.[000101] At step 634, software elements or user-interface (UI) workflows impacted by the source code changes are identified using dependency graph analysis. The dependency graph is maintained as a dynamic representation of the software system, wherein each node corresponds to a software element and each edge represents an interaction or dependency between elements. A trained third artificial intelligence (Al) model is utilized to detect nodelevel modifications, additions, or deletions that may influence the execution flow or functionality of the application.[000102] At step 636, verification of defects that are in a “fixed” state is performed by the third Al model, implemented as an Al defect retest agent. The defect states are retrieved by the Al defect retest agent from an issue-tracking platform via an authenticated API connection or webhook integration. The issue-tracking platform maintains records of defect identifiers, corresponding states (for example, Open, In Progress, Fixed, Closed), and the build versions of the software application in which the defects are expected to be resolved.[000103] In one embodiment, the third trained Al model may be trained on the correlation of commit messages, defect descriptions, and build logs of the live data of the software application. Through this automated correlation between defect states and build contents, manual verification efforts are eliminated, and initiation of the retesting process is ensured only after confirmation that the corresponding fix has been deployed in the target build.[000104] At step 638, the test cases affected by the fixed defects are identified using the third Al model. The third Al model determines the relevant test cases corresponding to the fixed defects from a test case repository. The selection is performed based on semantic associations determined by the Al model between defect metadata and test case metadata stored within the repository.[000105] At step 640, additional analysis is conducted by the third Al model to determine regression test cases that may have been indirectly impacted by the defect fix. Using the dependency graph, a neighbourhood analysis is performed, wherein the Al model identifies elements that are directly connected to or dependent upon the element where the defect fix was applied. The determined cases are compiled into a regression test suite. The regression test cases associated with neighbouring elements may be prioritized for execution to ensure that the defect fix does not introduce unintended side effects elsewhere in the system.[000106] At step 642, the prioritized regression test suite is executed using the autonomous test management platform 220. Execution results are collected and analysed by the third Al model to determine the success or failure of individual test cases.[000107] At step 644, regression impact reports are automatically updated in a software management platform. The reports include diagnostics of tested modules, execution outcomes, coverage details, and identified impacts on test design. In one embodiment, a dynamic graph of the software application under test is generated, wherein each node corresponds to an element in the application and each edge corresponds to a user interaction sequence. Modifications to nodes or edges are continuously monitored by the Al model to identify potential test design impacts, enabling automated maintenance of test artifacts in response to evolving application changes.[000108] It may be appreciated by those skilled in the art that, although three distinct artificial intelligence (Al) models are described herein for purposes of illustration, the embodiments of the present disclosure are not limited thereto. In certain implementations, one or more of the described Al models may be realized, wholly or in part, by a single trained Al model or shared intelligent engine configured to execute multiple of the functional operations disclosed herein.[000109] FIG. 7 illustrates a screen 700 associated with an example graphical user interface (GUI) associated with the automated test management platform 220, according to one embodiment of the present disclosure.[000110] FIG. 7 shows an example screen 700 of the example tester GUI that may be presented to a testing user 700 when setting up a new automated test. For example, in response to logging in to, or otherwise accessing, automated test management platform 220, a testing user is presented with screen 700 which includes a prompt to add a new application for testing. The example prompt depicted in screen 700 includes an editable field 704 to input a plurality of configuration setups, including an environment setup, a requirement setup, a defect tool setup, and an analytics setup, collectively referred to as project details 702, each configured to establish connectivity and synchronization between the autonomous platform and external enterprise systems. Multiple configurations may be configured by clicking on Add 706. These are just example configuration types shown for illustrative purposes. Once the data in relation to the configuration is filled, this can be saved or cancelled 708 using the button provided. Other application types may similarly be included in the prompt associated with screen 700.[000111] FIG. 8 illustrates a screen 800 associated with an example graphical user interface (GUI) associated with the automated test management platform 220, according to one embodiment of the present disclosure.[000112] A project name 802 is displayed in the GUI, representing an active project or software application being tested within the autonomous test management environment. The bibliographic data 804 section presents metadata and contextual information corresponding to the selected execution run. Such data may include, but is not limited to, identifiers such as build version, test run name, execution environment, tester identity, execution timestamp, and test suite identifiers. The bibliographic data 804 facilitates traceability and historical analysis of executed runs across multiple CI / CD cycles. A test status section 806 is provided to visually represent the execution outcomes of test cases associated with the current test run. The test status 806 may display the number of test cases passed, failed, broken, or pending execution.The graphical representation assists in quickly identifying overall quality trends and areas requiring further investigation.[000113] An executed run panel 808 is presented on the left side of the GUI. The executed run 808 lists all recent or historical test executions, including their execution type (e.g., “Execute Now,” “Scheduled,” or “CVCD”), allowing users or automated agents to navigate between different test runs. Each entry in the executed run panel 808 may be interactively selected to load corresponding test details and analytics. A test suite details section 810 is provided in the main display area. The test suite details 810 list individual test cases belonging to the selected test suite and display associated verification conditions, descriptions, or defect observations. The section may also allow access to test case results, verification objectives, or traceability matrices.[000114] In an example, the GUI 800 may be dynamically updated based on real-time inputs during operation received from the CI / CD platform and the software management platform. The bibliographic data 804 and test suite details 810 may be automatically fetched from the CI / CD platform during test execution, while application requirements, defect reports, and verification objectives may be received from the software management platform.[000115] In certain embodiments, the automated test management platform 220 may employ one or more artificial intelligence (Al) models to analyze the data displayed within the GUI 800, generate insights, or recommend test optimization strategies. The integration of the GUI with backend Al modules, software management tools, and CI / CD systems enables seamless synchronization between requirement management, test design, execution, and defect tracking operations.[000116] FIG. 9 illustrates a screen 900 associated with an example graphical user interface (GUI) associated with the automated test management platform 220, according to one embodiment. The screen 900 displays the defect report in a graphical format that includes test coverage and automation coverage. The dashboard interface represents a centralized view that enables continuous monitoring of testing progress and automation performance across defined time intervals and projects.[000117] A header section displays the active project name 902, such as a specific software application or module under verification, thereby allowing users to navigate between multiple project environments. Below the header, a time period selection interface 904 enables selection of predefined time durations, for example the past seven days, thirty days, or ninety days. The autonomous platform aggregates, filters, and visualizes test execution data corresponding to the selected temporal window, facilitating longitudinal trend analysis andoperational insights. It should be understood that while three time intervals are illustrated, alternative or customized time frames may be configured based on organizational needs or user-defined analytics preferences, without limiting the scope of the disclosure.[000118] An automation coverage section 906 is displayed on the left portion of the interface, showing automation coverage, that is the percentage of automated test cases relative to the total executed test cases during the selected period. This section also compares manual and automated test execution volumes, enabling assessment of automation maturity and identifying areas for optimization. In one embodiment, the automation coverage data may be synchronized in real time with the CI / CD platform or other software management platforms to retrieve test related metadata to generate a test coverage. The coverage may be displayed in a similar format as automation coverage in the form of graphs. Equivalent graphical representations, such as pie charts, tables, or stacked bars, may be used depending on the system configuration.[000119] A graphical analytics section 908 provides a comparative visualization of manual versus automated test cases, displayed along a timeline or categorical axis (e.g., days of the week). This assists quality engineering teams in identifying fluctuations, bottlenecks, or trends in automation performance over time. Additionally, a toolbar section 910 allows users to refresh data, share analytics, or download reports for external review, ensuring traceability and auditability of testing outcomes across software versions.[000120] End-to-end quality engineering is achieved through the use of the automated test management platform 220, ensuring complete traceability from requirements to test design, test execution, test reporting, and defect management. Such traceability provides a comprehensive understanding of test coverage and automation coverage. It should be appreciated that the metrics, representations, and interface layouts described with reference to FIG. 9 are exemplary and may vary across implementations.[000121] The present invention offers several key advantages that significantly enhance the software testing process. Firstly, the presented method reduces the time required for defect detection and resolution, ensuring faster identification and correction of defects. By providing a one-point solution that integrates all aspects of software testing, from requirement capture to defect management, the system streamlines the entire process. The automatic fetching of related test cases eliminates the need for human identification and reduces latency in retesting cycles. Furthermore, by enabling parallel test case generation and execution, the system achieves faster processing speeds, resulting in quicker feedback and improved efficiency. Inaddition, the invention supports testing at integration levels, ensuring comprehensive test coverage and early detection of issues, thereby improving overall software quality.[000122] The above-described examples are for the purpose of illustration. Although the above examples have been described in conjunction with example implementations thereof, numerous modifications may be possible without materially departing from the teachings of the subject matter described herein. Other substitutions, modifications, and changes may be made without departing from the spirit of the subject matter. Also, the features disclosed in this specification (including any accompanying abstract, and drawings), and any method or process so disclosed, may be combined in any combination, except combinations where some of such features are mutually exclusive.[000123] The terms “include,” “have,” and variations thereof, as used herein, have the same meaning as the term “comprise” or appropriate variation thereof. Furthermore, the term “based on”, as used herein, means “based at least in part on.” Thus, a feature that is described as based on some stimulus can be based on the stimulus or a combination of stimuli including the stimulus. In addition, the terms “first” and “second” are used to identify individual elements and may not meant to designate an order or number of those elements.[000124] The present description has been shown and described with reference to the foregoing examples. It is understood, however, that other forms, details, and examples can be made without departing from the spirit and scope of the present subject matter.

Claims

CLAIMSWhat is claimed is:

1. A method for autonomous test case management of a software application using artificial intelligence, comprising: generating, by a processing unit, natural language statements associated with testing of the software application based on a plurality of user actions performed by a user on a graphic user interface (GUI) of the software application using a trained visual language model, wherein the natural language statements correspond to one or more test case scenarios; generating, by the processing unit, a plurality of executable test cases corresponding to the test case scenarios using a first trained artificial intelligence model based on the natural language statements associated with the testing of the software application; identifying, by the processing unit, one or more defects associated with the software application based on execution of the plurality of executable test cases using a second trained artificial intelligence model; and managing, by the processing unit, one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is ready to be shipped.

2. The method of claim 1, wherein generating the natural language statements associated with testing of the software application based on the plurality of user actions performed by a user on the GUI of the software application using the trained visual language model comprises: capturing multiple GUI images and a user interaction log in response to the plurality of user actions performed by the user on the GUI of the software application; and generating at least one semantic graph comprising nodes and edges based on the GUI images and the user interaction log using the trained visual language model, wherein the nodes correspond to the GUI elements and the edges correspond to the user interactions.

3. The method of claim 2, wherein generating the plurality of test cases corresponding to the test case scenarios using the first trained artificial intelligence model based on the natural language statements associated with the testing of the software application comprises: generating one or more of temporal or topologically ordered sequence of interactions based on an analysis of the semantic graph using the first trained artificial intelligence model,capturing local and global dependencies of the plurality of nodes and edges of the semantic graph; and generating a plurality of test cases in a natural language based on the captured local and global dependencies and the generated sequence of interactions using the first trained artificial intelligence model.

4. The method of claim 3, wherein identifying the one or more defects associated with the software application based on the execution of the plurality of test cases using the second trained artificial intelligence model comprises: identifying executable test actions associated with the test scenarios by parsing a plurality of natural -language test case descriptions using a fourth trained artificial intelligence model; converting the identified test actions into a plurality of machine-executable commands capable of testing the software application on a test execution platform; executing the plurality of machine-executable commands within the software application environment using the test execution platform; and identifying the one or more defects in the software application by analysing execution logs and runtime artifacts of the executed machine-executable commands using the second trained artificial intelligence model.

5. The method of claim 4, wherein identifying the one or more defects in the software application using the second trained artificial intelligence model comprises: determining a failed element of a test step of a failed test case during execution based on execution of the machine executable commands in the software application environment; analysing a plurality of images of the graphical user interface using the second trained artificial intelligence model; predicting an alternate element in the GUI corresponding to the failed element using the second trained artificial intelligence model based on pattern recognition and semantic similarity between the failed element and candidate elements in the GUI; modifying the test step of the failed test case using the predicted alternate element in the GUI; and executing the modified test case using the second trained artificial intelligence model.

6. The method of claim 5, wherein managing the one or more defects associated with the software application using the third trained artificial model in such a manner that the software application is ready to be shipped comprises: determining defects that have transitioned to a resolved state by interfacing with one or more defect tracking systems; verifying an availability of a software build containing the defect fix by analysing build artefacts and metadata from a software management system; automatically identifying a set of regression test cases associated with the resolved defects based on a graph-based representation of the software application; generating a prioritised regression test suite using the identified set of regression test cases using the third trained artificial intelligence model based on a probability of each test case being affected by the defect fix; executing the prioritised regression test suite using a test execution module; and generating a regression test report comprising test results, regression summaries, traceability updates, and audit logs that include user credentials and timestamps.

7. A system for autonomous test case management of a software application using artificial intelligence, comprising: a processing unit; and a memory coupled to the processing unit, the memory comprising an autonomous test management platform configured to: generate natural language statements associated with testing of the software application based on a plurality of user actions performed by a user on a graphic user interface (GUI) of the software application using a trained visual language model, wherein the natural language statements correspond to one or more test case scenarios; generate a plurality of test cases corresponding to the test case scenarios using a first trained artificial intelligence model based on the natural language statements associated with the testing of the software application; identify one or more defects associated with the software application based on execution of the plurality of executable test cases using a second trained artificial intelligence model; and manage one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is ready to be shipped.

8. The system of claim 7, wherein in generating the natural language statements associated with testing of the software application, the autonomous test management platform is configured to: capture multiple GUI images and a user interaction log in response to the plurality of user actions performed by the user on the GUI of the software application; and generate at least one semantic graph comprising nodes and edges based on the GUI images and the user interaction log using the trained visual language model, wherein the nodes correspond to the GUI elements and the edges correspond to the user interactions.

9. The system of claim 8, wherein in generating the plurality of test cases corresponding to the test case scenarios using the first trained artificial intelligence model, the autonomous test management platform is configured to: generate one or more of temporal or topologically ordered sequence of interactions based on an analysis of the semantic graph using the first trained artificial intelligence model, capture local and global dependencies of the plurality of nodes and edges of the semantic graph; and generate a plurality of test cases in a natural language based on the captured local and global dependencies and the generated sequence of interactions using the first trained artificial intelligence model.

10. The system of claim 9, wherein in identifying the one or more defects associated with the software application based on the execution of the plurality of test cases using the second trained artificial intelligence model, the autonomous test management platform is configured to: identify executable test actions associated with the test scenarios by parsing a plurality of natural -language test case descriptions using a fourth trained artificial intelligence model; convert the identified test actions into a plurality of machine-executable commands capable of testing the software application on a test execution platform; execute the plurality of machine-executable commands within the software application environment using the test execution platform; and identify the one or more defects in the software application by analysing execution logs and runtime artifacts of the executed machine-executable commands using the second trained artificial intelligence model.

11. The system of claim 10, wherein in identifying the one or more defects in the software application using the second trained artificial intelligence model, the autonomous test management platform is configured to: determine a failed element of a test step of a failed test case during execution based on execution of the machine executable commands in the software application environment; analyse a plurality of images of the graphical user interface using the second trained artificial intelligence model; predict an alternate element in the GUI corresponding to the failed element using the second trained artificial intelligence model based on pattern recognition and semantic similarity between the failed element and candidate elements in the GUI; modify the test step of the failed test case using the predicted alternate element in the GUI; and execute the modified test case using the second trained artificial intelligence model.

12. The system of claim 11, wherein in managing the one or more defects associated with the software application using the third trained artificial model in such a manner that the software application is ready to be shipped, the autonomous test management platform is configured to: determine defects that have transitioned to a resolved state by interfacing with one or more defect tracking systems; verify an availability of a software build containing the defect fix by analysing build artefacts and metadata from a software management system; automatically identify a set of regression test cases associated with the resolved defects based on a graph-based representation of the software application; generate a prioritised regression test suite using the identified set of regression test cases using the third trained artificial intelligence model based on a probability of each test case being affected by the defect fix; execute the prioritised regression test suite using a test execution module; and generate a regression test report comprising test results, regression summaries, traceability updates, and audit logs that include user credentials and timestamps.

13. A non-transitory computer-implemented storage medium that stores machine- readable instructions, that when executed by at least one processing unit, cause the processing unit to perform a method comprising:generating natural language statements associated with testing of the software application based on a plurality of user actions performed by a user on a graphic user interface (GUI) of the software application using a trained visual language model, wherein the natural language statements correspond to one or more test case scenarios; generating a plurality of executable test cases corresponding to the test case scenarios using a first trained artificial intelligence model based on the natural language statements associated with the testing of the software application; identifying one or more defects associated with the software application based on execution of the plurality of executable test cases using a second trained artificial intelligence model; and managing one or more defects associated with the software application using a third trained artificial intelligence model in such a manner that the software application is ready to be shipped.

14. The storage medium of claim 13, wherein the instructions to generate the natural language statements associated with testing of the software application cause the processing unit to perform method steps comprising: capturing multiple GUI images and a user interaction log in response to the plurality of user actions performed by the user on the GUI of the software application; and generating at least one semantic graph comprising nodes and edges based on the GUI images and the user interaction log using the trained visual language model, wherein the nodes correspond to the GUI elements and the edges correspond to the user interactions.

15. The storage medium of claim 14, wherein the instructions to generate the plurality of test cases corresponding to the test case scenarios using the first trained artificial intelligence model cause the processing unit to perform a method comprising: generating one or more of temporal or topologically ordered sequence of interactions based on an analysis of the semantic graph using the first trained artificial intelligence model; capturing local and global dependencies of the plurality of nodes and edges of the semantic graph; and generating a plurality of test cases in a natural language based on the captured local and global dependencies and the generated sequence of interactions using the first trained artificial intelligence model.

Images