Everything You Need to Know About Green Screen Automation

In this blog post, we’ll explain - in simple terms - what green screens and green screen automation are, and how you can do green screen automation.

If you’re looking for a robust and secure, yet simple-to-use green screen automation solution, make sure to download our Guide to Mainframe Automation.

What is a green screen?

Simply explained, green screens let you talk to a mainframe. A bit like how a user interface lets you talk to your PC.

Green screens have been around for many years, just like mainframes. As the mainframe technology has evolved, the meaning of a green screen has also changed.

In the past, working in green screen referred to using a stationary keyboard and monitor (called a “terminal”) to interact with a mainframe. Nowadays, people still type commands into a green screen to enter and find information stored in a mainframe. The main difference is that green screen software runs on a PC, “emulating” (copying) what an old-school terminal used to be used for

Wondering why anyone would need to use green screen? A lot of important processes still rely on employees looking up information this way. For example, someone working in a bank might use it to check your credit score if you want to take out a loan. Someone working in a warehouse might use it to check inventory levels. And a medical professional might record test results with a green screen.

In short, green screens = terminal emulators.

Related reading: The Complete Guide to Mainframe Automation

What about mainframes, mid-sized servers, and mainframe emulators?

When it comes to the subject of automation, terms are often used interchangeably. So it’s important to know in advance that “green screen automation”, “terminal automation”, and “mainframe automation” all refer to the same types of testing.

That said, let’s break down a few terms:

• A mainframe is a high-end server from IBM that runs centralized applications and can store lots of data, such as bank accounts and insurance policies. Mainframes are like servers on steroids - they are bigger, faster, and more expensive. An example of a mainframe is IBM’s Z Series.
• A mid-sized server often performs the same function as a mainframe, with the main difference being that it’s usually less powerful (and thus less expensive). Examples include the IBM AS/400 and iSeries, and DECsystems
• While mainframes and mid-sized servers evoke images of fridge-like machinery stored in a basement, an alternative is to run mainframe emulator software on a PC. While this has nowhere near the processing power of the first two, it is a feasible solution for many smaller companies. An example is Hercules, a type of mainframe emulator software that takes advantage of virtual drivers in order to store data.

In brief, green screen (a.k.a. terminal emulator software) runs on employee PCs, and connects to either a mainframe, mid-sized server, or mainframe emulator via an encrypted connection:

Related reading: What is Mainframe Automation?

Why green screen automation?

As with any software, mainframes need to be tested.

Mainframes are commonly used in banking, financial services, and insurance (BFSI) organizations, who have complex processes and data security at stake, and who can use test automation to minimize risk.

Automation is used to reduce risk and overcome common challenges in connection with testing and quality assurance:

• The risk of an update interrupting business (e.g. a banker not being able to look up the financial profile of a customer applying for a loan): It’s not uncommon for updates of central applications to take place a few times a year due to, for example, new banking (e.g. IBAN) standards or government regulations.
• The risk of losing data due to synchronization errors between the legacy environment and cloud-based systems (e.g. Salesforce): If data doesn’t sync properly across systems, business-critical processes can be brought to a standstill.
• The cost of repetitive work: Manual, repetitive tasks can cost a lot of work hours and waste valuable resources. For example, manually updating hundreds of thousands of insurance policies or manually triggering letters to customers who don’t pay on time.
• The cost of increasingly rare experts: Green screen runs on legacy programming languages such as COBOL, and it’s a challenge to find people who understand them. Most companies either test manually or use an automation tool.

How to automate green screens

To automate green screens you need an automation tool or framework. These will typically rely on either code, OCR (Optical Character Recognition), or built-in support for specific terminal emulators.

Code-based tools require knowledge of a programming language. For this reason, code-based tools are more resource-heavy than tools with OCR and built-in support.

Optical Character Recognition (OCR)

OCR is a technology that uses computer vision to identify characters on a screen. It’s used to validate that the UI and visual elements on the green screen appear as intended.

OCR is often used in automation because it uses the UI to find elements and can therefore be utilized across various technologies where the underlying code is difficult to access. A lot of the time, it does the job well enough.

That said, green screen testing that relies solely on OCR can be cumbersome to create and maintain. The reason for this is that the OCR engine will look for the character in the same place as it did when the test was created. If the character moves, the engine may not be able to find it, and hence the test will fail. This means that, in general, when the same test is run on different emulators or with different resolutions, there’s a risk that the test will fail, even though the green screen or mainframe may still work as intended.

Built-in support for terminal emulators

As an alternative to OCR, you can use a platform that supports the terminals used in your setup. For example, your organization might require support for IBM i Access Client solutions, IBM, or Personal Communications MicroFocus Rumba+ Desktop. More specifically, certain “modes” might be required by different types of organizations. IBM 3270, for example, is required by many large financial institutions, whereas 5250 is commonplace in SMEs. In some cases, a combination of emulators and modes might be required.

Depending on your needs, built-in recorder support can offer a more stable way of creating and maintaining automated test cases for green screens. Recorders let you capture elements easily step-by-step, and then turn them into tests automatically that you can schedule or run at any time.

Learn more about green screen automation

Download our guide to mainframe automation to learn more about recorders and how to automate green screens.