TCS recently introduced 360 Degree Assurance (360), an AI-based IP, based on analyzing data gathered from several sources across the IT software development life-cycle. Current use cases cover defect root cause analysis and for test case optimization.

360 follows the introduction last year by TCS Assurance Services Unit (ASU) of NETRA, proprietary IP which helps automate the Dev-to-Ops cycle. NETRA pre-integrates with testing tools used for test execution and DevOps and provides test support (e.g. environment management, service virtualization, test data management. For more information, please refer to “DevOps Testing; TCS Takes the IP Way”).

The next step logically is feeding back application-related production data back to development and testing, in short, formalizing the Ops-to-Dev process, and further automating this process. This is where TCS ASU’s 360 Degree Assurance comes into play. It is based on the rationale that a defect in an application in production will trigger a number of events, which has an impact on production monitoring systems or cause an end-user interaction to the service desk.

360 Degree Assurance connects to ITSM tools to access tickets recorded by the service desk along with configuration data management tools and access production environments (from database and application server logs). Once this event data is collected, 360 collects defect-related information from several systems including HP ALM/QC, other defect management tools (Atlassian JIRA), also with other tools (including open source tool SonarQube, for static code quality analysis, and the TCS Mastercraft series of SDLC tools).

NLP Approach

With information from both sides of the story (on defects and code quality and their impact on production and service desk), 360 starts looking to identify the root cause of a defect. Analytics and AI, taking a NLP approach, come into play. 360 goes through all the defects and incidents recorded in the ITSM tool (based on sentence detection in ALM tools), and one and more keywords (“regex”), and aggregates them into clusters. Cluster examples are lack of compliance with coding procedures, and lack of code maintainability due to outdated code. This provides a bottom up understanding of defects and a high-level root cause analysis.

This is still early stages of a journey: TCS ASU is looking to progress further with automated root cause analysis and achieve more granularity in the analysis. It is working on integrating 360 Degree Assurance with other tools, including Continuous Integration open source tools such as Jenkins.

NelsonHall will continue to monitor and report TCS’ progress in this initiative. TCS is ahead of the curve in investing in Ops-to-Dev automation; it probably has a six-to-twelve month lead.

Adaptive Neural Networks Approach

TCS has another story with 360 Degree Assurance; this one is about test suite optimization.

Currently, most activity around test case number optimization is based on statistical approaches, based on the pair-wise approach, or on combinatorial based testing (CBT).

TCS is taking a different route, using AI, taking an Adaptive Neural Networks approach, going through each test case and identifying patterns from test case-related meta data. This analysis aims to support decision-making.

This process starts small (up to ten test cases initially), and under the supervision of a SME (to validate decisions by the AI to use/not to use a given test case) and is highly iterative (in test lab conditions, TCS is finding up to nine iterations, for a test suite with up to 1,000 test cases, are necessary). And the number of test cases that can be reduced is vast: up to 60% of test cases of a given estate. That’s huge (and overall in line with what the statistical approaches suggest). Again, it is still early days: TCS has only started working with clients on beta implementations.

Looking ahead, the objective of 360 is to make further use of new technologies such as AI, machine learning or cognitive and bring new perspectives on software testing/ assurance analytics. It will be interesting whether this AI approach overlaps with or is complementary to statistical approaches. In the meantime, let’s not spoil the party: whichever techniques are used, this is about drastically reducing the estate of test cases, thereby reducing both automation effort and also maintenance effort. This is good news: making testing activities more automated, faster and more inexpensive is exactly what digital transformation projects require. The growing adoption of agile will drive this need for shorter builds periods: Google itself releases its beta versions of Chrome, the world’s most used browser, every two to three weeks. This is the new objective for build and test activities.