The software testing/QA industry relies on three steps for functional testing:

• Defining test requirements (what do I need to test?)
• Test case creation (creating detailed instructions)
• Test scripts (using these test cases to develop scripts operated by a functional test execution tool, e.g., Micro Focus QTP, Tricentis Tosca, and Selenium Grids).

Broadly, these three steps have remained the foundation of how functional testing operates. This is true even for agile projects, for which organizations are accelerating their automation efforts. However, these three steps have their limitations, mainly in terms of time and effort to create and maintain test scripts.

BDD, MBT, and record-and-playback automate test case & script creation

Of the various approaches to challenge this three-tiered foundation, Behavior-Driven Development (BDD) has been the most widely adopted. BDD relies on creating a standardized English test case language, Gherkin. Because it is standardized, BDD helps to automatically create scripts immensely. Yet, the adoption of BDD to date has not been as spectacular as expected.

Model-Based Testing (MBT) had a promising value proposition. It aimed to create business process flows/diagrams representing a business transaction on an application. Once defined, the business process flows are standard and can automatically be transcribed into test cases or scripts. However, MBT’s adoption was limited, possibly because MBT relies on adding another level of test artifacts, which in turn need to be maintained. However, MBT has had some success for applications such as COTS, with standard business processes. Industries such as communication services providers and financial services have also found MBT helpful.

And then, there is AI. AI has helped modernize record-and-playback tools. These tools mark down all the steps performed by a user when completing a transaction on an application. They then repeat the transaction and execute it in a functional execution tool. However, records are rigid and will fail when developers make minor changes such as a field name or location adjustment. AI helps deal with such minor changes and has improved the effectiveness of record-and-playback tools. The adoption of such tools is not widespread, but their value proposition is enticing.

With OAE, TCS brings it all together

We recently talked with TCS about its new automation initiative, TCS CX Assurance – One Automation Ecosystem (OAE). With OAE, TCS has aggregated its next-gen record-and-playback (TCS’ ScriptBot), MBT, and testing framework capabilities into one central tool. OAE brings together several approaches for automating the creation of test artifacts.

The beauty of OAE is that three tools are integrated and interoperable: a change in one immediately impacts the other two. OAE engineers can change views between the three tools and verify/edit conditions or edit the business process flow/test case/test script. For instance, a test engineer may modify recently recorded test cases and add new conditions in the test framework view. The tool interoperability also means that different personas can use OAE: test engineers, of course, and business analysis for creating business processes and power-users for recording transactions. This is a step toward test script creation democratization, one of the QA industry’s priorities to decrease costs and spread tool usage.

There is another benefit: with the three tools, OAE focuses on test artifact creation before the test script level, at the business process, or test case level. TCS can then use these artifacts to create the test scripts in its technology of choice, e.g., Selenium for web applications, Appium for mobile apps, a TCS IP for APIs, and Micro Focus for ERPs, mainframe and client-server applications. The approach minimizes the level of test script maintenance and pushes it back earlier in the automation process. TCS highlights that the conversion of test cases into scripts is instantaneous: it has not witnessed any performance issues in the conversion.

OAE also helps test transactions involving several applications running on different technologies. Typically, a transaction may start on a mobile or a web application/website and include testing APIs (for shipment) and even mainframe (payments). In short, OAE makes end-to-end testing much more accessible.

OAE requires the same discipline as for any testing framework. For instance, users still need to componentize test artifacts. An example is application login, which OAE users must set up as a test component shared across all tests. Also, to help with the discipline, OAE uses NLP: users creating a test artifact will be notified by the system when their artifact in creation already exists.

OAE integrates with other TCS IPs and benefits from some of these. One example is UX testing, where TCS can include accessibility and compatibility testing scripts in its functional ones. Another UX testing example is usability testing, which is the pixel-by-pixel and AI-based comparison of web pages to identify browser rendering differences.

Looking ahead, TCS has several development priorities for OAE, including accessibility on mobile app, integrating with functional automation tools such as Test Café/Cypress.io as an alternative to Selenium. TCS will also use its IP, SmartQE AI Studio, to collect application data during the SDLC and assess its quality. AI remains a priority.

OAE is a new IP, and TCS recently started promoting it among clients. NelsonHall welcomes TCS CX Assurance – TCS’ One Automation Ecosystem initiative for automating the creation of test cases and scripts. This is the future of functional testing, and it is AI-based. TCS is at the vanguard here.