Addressing the challenges of multichannel testing: moving between interfaces, from moving to the Web and back

Multiple-channel descriptions are applications that have multiple interfaces. As we evolve from the desktop to web-based computing and even mobile computing, multi-channel is becoming more common. Because of the combination of devices (tablets, mobile phones, laptops, desktop computers) and the way devices interact (device-specific "applications", browsers, and traditional client applications), the interface of the same application is growing. For example, a WEB application that uses the same business logic, a mobile application, or even a CLI (command-line interface) banking application. Because of the growing popularity of service-oriented architectures (SOA) and Web services, in many cases the integrator's job is to regroup the service with the new front-end. But business logic (also called services) remains the same.

With development teams reusing code to reduce maintenance costs and improve productivity in the same way, to keep up with the development team, the Test team needs some way to reuse the test scenarios and automate them.

Challenges with multichannel testing

A few years ago, I was an automated test architect who was responsible for building all of the automation for two (not one) applications with multiple interfaces. Both have legacy "local" user interfaces, using Microsoft Windows 32-bit MFC (Microsoft Foundation Class) controls, a WEB interface that uses JavaScript, ASP, and JSPs (acti ve Server pages and JavaServer pages), a new (updated) Eclipse SWT (Standard Widget Toolkit) interface, and a command-line interface. Of course, it's impossible to find an automated tool that works for all of these interfaces, but we can put it aside for a while.

When programming, you tend to focus on reducing the amount of code that needs to be maintained by promoting reuse. With object-oriented programming and refactoring, there is little reason to have the same code in multiple places. But you need to design a schema so that I can consider how to solve multiple interface tests from a single test automation code base. First, although they are all interfaces of the same application, not all interfaces will have the same functionality, let alone use the same approach. But there are also a number of customer-centric scenarios (use cases) that make sense to test across all interfaces.

However, the test teams that are responsible for designing test cases and test plans do not consider their tests in this way. In fact, they are separated and separated by shafts according to the interface they are dealing with. The team that built and tested the CLI thought they needed only a small number of customer scenario tests. They focus primarily on unit testing and do not really consider a customer flow through the CLI. The Test team responsible for the Eclipse UI wants a large number of UI features and automated functionality. They have a long list of test cases that need to be executed, and to achieve this, they need to be fully focused on the customer stream. But why can't we use the information that was painstakingly done by the subject matter expert (SME) to test all the interfaces?

A hierarchical approach

Typical test automation frameworks that use object-oriented programming (OOP) typically abstract the implementation details of the control set rather than the conceptual actions expressed through the control. This is actually the way many commercial GUI automation tools are used. For example, all text fields accept text, define a text field class with the SetText (string) method, and use it on all versions of the application. However, this does not apply to all scenarios where automated tests are built across interfaces. What happens when one GUI uses a radio button and the other uses a check box? You can't actually rely on the same interface for the same operation. This traditional OOP approach is shown below.

Figure 1. GUI Control Hierarchy

In our example, the interface varies greatly, but the operations and business processes represented are essentially the same. To maximize reuse, we selected a business logic hierarchy (see Figure 2) to reuse test scenarios across multiple interfaces. This not only maximizes our code reuse, it also means that the test tools will be relied upon to manage the GUI interface, which is what they were designed to do. Figure 2 shows this way, and you may have identified this abstract factory pattern.

Figure 2. Business logic Hierarchy