MindTree has core understanding of testing on Mainframe systems which call for specialized knowledge due to its inherent complexity.
Unlike GUI applications, which have many windows and dialog boxes, terminal emulators have only a single window. Window contents can change, but the physical window remains the same. Testing scripts must contain some form of synchronization command in order to drive the application successfully.
Recognizing completed transactions in the emulator can be difficult, as there are no objects within the window, just text, and this text cannot be treated as a text box. Transactions also do not change window state, only window text. If the testing tool does not 'know' that a transaction is complete, it will continue through the script, sending characters for the next transaction into the emulator. If, at that time, the emulator had not completed the previous transaction, the input from the automation tool will over-run the emulator, which will then lock up. Scripts have also to be instructed to wait for unique screen text before proceeding with the next instruction.
MindTree knows that the solution lies with using emulators. A relatively simple environment, transactions within emulators never involve more than one window; unlike a Web browser transaction that could start in one window, and present results in a different window that dynamically pops up. We believe the best approach is to record transactions in a robot script, and then be prepared to fill gaps by editing this script, separating each transaction into one line in the script.
Unlike GUI applications, which have many windows and dialog boxes, terminal emulators have only a single window. Window contents can change, but the physical window remains the same. Testing scripts must contain some form of synchronization command in order to drive the application successfully.
Recognizing completed transactions in the emulator can be difficult, as there are no objects within the window, just text, and this text cannot be treated as a text box. Transactions also do not change window state, only window text. If the testing tool does not 'know' that a transaction is complete, it will continue through the script, sending characters for the next transaction into the emulator. If, at that time, the emulator had not completed the previous transaction, the input from the automation tool will over-run the emulator, which will then lock up. Scripts have also to be instructed to wait for unique screen text before proceeding with the next instruction.
MindTree knows that the solution lies with using emulators. A relatively simple environment, transactions within emulators never involve more than one window; unlike a Web browser transaction that could start in one window, and present results in a different window that dynamically pops up. We believe the best approach is to record transactions in a robot script, and then be prepared to fill gaps by editing this script, separating each transaction into one line in the script.
Benefits
- Easily repeatable, automated testing has the advantage over manual testing
- Automated testing delivers business gains depending on how test efforts are accommodated
- Supplement choice for increasing throughput
- Shared tools and resources
- Automated test tools can test many areas of system functionality such as user interfaces, system performance, system code, and requirements
