Copyright © 2026 Authors retain the copyright of this article. This article is an open access article distributed under the Creative Commons Attribution License which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

@article{209029,
        author = {Punam Kailas Kale and Vaishnavi Jalindar Khalate and Pratiksha Ramkisan Jadhav and Prof. Pallavi Gholap},
        title = {Context-Aware Predictive Self-Healing Test Automation Using Failure-Causality Analysis for IoT-Enabled Cloud Robotic Systems},
        journal = {International Journal of Innovative Research in Technology},
        year = {2026},
        volume = {13},
        number = {no},
        pages = {761-768},
        issn = {2349-6002},
        url = {https://ijirt.org/article?manuscript=209029},
        abstract = {Robots, sensors, edge devices, machine-learning components, communication protocols, APIs, and cloud back-ends all sit inside a modern IoT-enabled cloud robotic system, and that mix is exactly what makes automated testing harder here than for an ordinary web or desktop application. When a test fails, the reason is often nothing to do with a code defect at all a dropped packet, a slow network hop, a jittery sensor reading, a broken MQTT session, a slow API response, or a cloud service that is briefly unreachable can all produce the same red mark on a test report. Treating every one of those red marks as a confirmed bug leads to false alarms, wasted reruns, sluggish CI/CD pipelines, and hours of manual triage that didn't need to happen. To deal with this, the paper puts forward CAPS-TA short for Context-Aware Predictive Self-Healing Test Automation a framework built around one idea: look at the circumstances surrounding a failure before deciding what to do about it. It pulls in live signals from Raspberry Pi or Arduino hardware, IoT communication channels, APIs, cloud endpoints, test logs, and the outcomes of past runs, then runs a lightweight causal model over that evidence to judge what probably caused the failure, whether the problem is likely to pass on its own, and which fix makes sense. From there, a decision layer picks among several options retrying under controlled conditions, re-establishing the communication link, shifting execution to the edge, waiting and rerunning later, or simply flagging a human rather than defaulting to one fixed behaviour. What sets this apart from a plain retry-until-it-passes strategy is that the diagnosis is linked directly to how much the next action would cost and whether it's actually appropriate. The remainder of the paper walks through the architecture, how information flows through it, the recovery algorithm, metrics for judging performance, a plan for injecting faults on purpose, and a CI/CD experiment design meant to be repeatable by others. Because none of this has been run yet, the paper stops short of reporting experimental numbers it stays at the level of a proposed, testable design.},
        keywords = {Self-Healing Testing; IoT; Cloud Robotics; Failure Causality; Predictive Testing; Raspberry Pi; Arduino; AI; CI/CD; Fault Injection; Edge Computing; Automated Software Testing.},
        month = {September},
        }