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.
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.
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:
In brief, green screen (a.ka. terminal emulator software) runs on employee PCs, and connects to either a mainframe, mid-sized server, or mainframe emulator via an encrypted connection:
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:
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 the mainframe’s programming language, such as COBOL. For this reason, code-based tools are more resource-heavy than tools with OCR and built-in support.
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.
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.
Download our guide to mainframe automation to learn more about recorders and how to automate green screens.