{"id":331604,"date":"2025-12-05T20:04:50","date_gmt":"2025-12-05T20:04:50","guid":{"rendered":"https:\/\/peraltafinancing.com\/uncategorized\/the-new-frontier-of-automated-tests-is-machine-learning-nonteek\/"},"modified":"2025-12-05T20:04:50","modified_gmt":"2025-12-05T20:04:50","slug":"the-new-frontier-of-automated-tests-is-machine-learning-nonteek","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=331604","title":{"rendered":"The new frontier of Automated Tests is Machine Learning \u2013 Nonteek"},"content":{"rendered":"


\n<\/p>\n

\n

The long wave of Artificial Intelligence hits Testing Automation too<\/h2>\n

In the DevOps era, the discussion about the integration between the world of Dev (eloper) and Op (eration) s is often animated.\u00a0The emphasis is almost always on automating builds, unit tests, releases.\u00a0But in a context where development cycles become shorter and shorter, where releases are directly released in production, manual testing risks becoming a bottleneck.\u00a0<\/p>\n

\"\"\/
The hard life of testing to keep up with the pace of increasing complexity and change.
<\/figcaption><\/figure>\n

On the other hand, the automation of the tests, which prescribes both the development and release of scripts, should be rightfully included in the cycle. But since it\u2019s not about new functionalities, it is taken for granted, often ending up outside the plans.\u00a0The result is that it becomes increasingly difficult to keep automation scripts aligned with application releases, and an unaligned test is an unusable test.\u00a0Furthermore, we should not forget that all the phases of the SDLC (Software Development Life Cycle) should be tested, therefore it follows that whenever we talk about Continuous Development and Continuous Integration, we should introduce the concept of Continuous Testing.<\/p>\n

\"This
Continuous Testing in the DevOps
<\/figcaption><\/figure>\n

The message here is that at the foundation of the concept of testing<\/i> automation<\/em>\u00a0lies a problem: in order to create them<\/g> we need engineers.\u00a0The tools for testing automation are so many now that there are also\u00a0Anaconda-<\/a>style distributions\u00a0claiming to integrate them.\u00a0The situation now in QA is that of a sort of smoky border of DevOps, where complicated test cases are developed with heterogeneous sets of tools such as\u00a0Cucumber<\/g><\/a>\u00a0,<\/g>\u00a0Jenkins<\/g><\/a>\u00a0,<\/g> and even ad-hoc scripting languages like\u00a0Gherkin<\/g><\/a>\u00a0.<\/g>\u00a0The problem now is that we need developers to test (not just develop) new code.<\/p>\n

But if the DevOps has the mission to integrate the whole development cycle, how is it possible that testing has become another phase of development?\u00a0The reason lies in the fact that the frameworks and tools used (first of all\u00a0Selenium<\/a>\u00a0), do not have any kind of intelligence within them.\u00a0It follows that, although they are very effective at automating, they are only good for a developer.<\/p>\n

The \u201cThird Wave\u201d:\u00a0that is, Artificial Intelligence and Continuous Testing<\/h3>\n

Today most of the GUI (Graphical User Interfaces) are developed with Javascript and Node.js, and automated tests are mainly implemented with frameworks like\u00a0Selenium\u00a0<\/a>and\u00a0Appium<\/a>.\u00a0The problem with those approaches is that they require a large amount of scripting, they are often difficult to maintain, and it is hard to keep them updated with the continuous releases and the changes that come with them.<\/p>\n

The introduction of Machine Learning in automated testing introduces some crucial points:<\/p>\n