Mainframe Testing Services

In the current economic scenario, IT budgets are constantly under pressure and there is an expectation to get good quality applications with less cost. Testing clearly has taken on an increasingly important role in application development and is one of the biggest drivers of the overall development cost and quality. As business application development becomes more dynamic and component-based, new approaches are needed in testing to help deliver quality business applications. HCL helps customers with its testing framework to achieve this. Necessity of Mainframe Testing:
y

y y y y y y y y y y

Mainframe applications, product suites and architectures are entirely different from the distributed environment. Moreover, these applications control critical business flows as well With emerging business needs, mainframe applications are changing continuously, be it SOA, SOI, Cloud, etc. Due to new technologies, the mainframe testing scope and scenarios became more complex and require more focused testing Retiring mainframe workforce increases the risk of non-SMEs making changes to application. This may result in a large number of defects The cost of quality and impact cost due to erroneous testing is very high when it comes to mainframe applications The focused testing methodology for mainframe applications would yield high benefits. Various Legacy Scenarios get tested Since legacy is at the core of the business, impact on other interfacing applications can also be tested End-to-end test coverage, spanning platforms Reduced cost of quality Automation in mainframe testing can help in reducing time-to-market for future projects

Mainframe Migration Fundamentals:

Migration Strategies

Four primary strategies are available for mainframe migration. The deciding factors when choosing an appropriate strategy include understanding the scope of the migration project, the resources and skills affected and required, the short and long term goals of the organization, and the level of complexity and commitment involved in implementing the strategy. It is necessary to fully understand the interests driving the migration from the information gathered before beginning a migration.

Although the four strategies are listed individually in the following text, several of them may be required simultaneously to achieve the desired results. For example, migrations that are initiated with a business-level or application-level scope, where the application being migrated consists of many different components, more than one strategy may be used. Careful consideration should be taken when selecting the applications to migrate. It must be determined in advance whether to migrate a single application or all applications, and which specific applications are the most critical to migrate. For example, the drivers for migrating applications may be a combination of cost reduction or avoidance as well as the need to modernize capabilities. An Application Value Assessment (AVA) is recommended to help select and confirm the candidate applications for migration. For example, a "lower value" application is at lower risk for failure and usually migrates quicker but benefits the organization less. However, a "higher value" application is at a higher risk for failure and is generally more complex and therefore more timeconsuming, but provides a greater return on investment. Note AVA is beyond the scope of this book, but is a service supplied by many consulting firms and supported by various software packages.
Integration: Moving Part of an Application

Integration involves moving one or more components of an application to the Windows platform. For example, one scenario may be to move executable components, but leave a database shared with other applications on the mainframe. Application components such as reporting job streams, high volume printing, or read-only queries may be separated from the rest of the application and migrated on an individual basis. Integration will often be the first step an organization takes in migrating an application, because it mitigates costs and risks. However, this strategy may not deliver a sufficient degree of benefit commensurate with the required investment when compared to other available strategies that potentially eliminate the mainframe.
Code Migration: Moving an Entire Application

Code migration involves recompiling or converting the application source code to the new platform. Many third-party tools are available to ease this process, especially for applications written in COBOL. When using this technique, it is important to decide whether to migrate existing bugs associated with the code or fix them as the code is recompiled. This strategy is an extended and complex process that can easily be underestimated because a large number of different technical components must be migrated. Recompiling code may not adequately address the needs of changed business processes, which may be the real benefit of the new application.

Replacement: Adopting a New Windows Application

The replacement strategy takes advantage of the availability of relatively inexpensive Windows versions of many off the shelf software packages. The old application is withdrawn from service and its functionality is replaced by the newly adopted Windows application. The issues in this strategy center on the adaptation of the business processes to the capabilities of the new applications, which are unlikely to exactly duplicate those of the old application.
Evolution: Begin to Develop Applications in the Windows Environment

The evolution strategy advocates using the existing application as a starting functional specification, and then rebuilding the application using modern programming languages and tools. The challenge here is to maintain existing applications and infrastructure as required while creating new applications and infrastructure. This may be an effective strategy to employ when you need a major new application without eliminating the older application.

How to test a Mainframe application? Mainframe Testing is similar to client-server applications testing, but you have to know how to operate basic TSO and ISPF commands and menus, view mainframe files, look at and use SDSF or other output tool, log on CICS and transactions, use FTP or another transfer protocol, submit the batch job - it's for QA testing of mainframe applications. And plus, unlike the QA testing for another platform, like WEB and/or client-service, the mainframe is usually back-end. It can be learned pretty quickly, but it needs an access to mainframe. There are various kind of tests : integration tests, performance tests, volume tests, regression tests, stress tests etc. You can test a all cluster of programs or a whole day or night of production. You need to know the expected results, discuss with business analysts, with system team, with Capacity team, .And you will have to know a lot of tools or technic : Strobe, File Aid, Ecomp, CA7, report Excel, Word, DB2, CICS, zOS, Sort, backup, recovery, etc. As part of mainframe testing you could be testing a COBOL application on a DB2 database, or a Peoplesoft application using an Oracle database, or the application could be a CICS application using QA Hyperstation to automate the testing. The QA principles do not change, however the skillsets differ to some extent. You may be required to know JCL, ISPF and TSO and have a basic understanding of COBOL. You should know how to write SQL queries to test any databases. There may also be networking issues to consider when testing large system environments. Mainframe applications run on the mainframe and clients access the mainframe through a terminal emulator. The terminal emulator is the only software that needs to sit on the client machine. Changes to the software (COBOL, JCL, etc) are made on the mainframe and as a mainframe tester you don't need to worry about migrating them to the client. If it works through one terminal emulator it should work on them all. Client/Server Testing Vs Mainframe Testing concepts Client/server architecture allows some of the processing to be done by the client. However, since there is code to ship to the client, you have to worry about the code being installed properly, working on their OS, playing well with the other applications on the desktop, security, and performance. Inside a

company, you probably know the number of users, types of environments (OS, RAM, connection speed), so it's not as extensive as web testing, but it has more variables than mainframe testing. Also, while usability should not be ignored on mainframe applications, it seems to be more of an issue with client/server applications since they also generally have GUIs. Mainframe Test Tools Some of the tools that are used for mainframe testing are as follows: 1. Test Director 2. QTP (Quick Test Professional) 3. Claim Repository 4. Foundation Testing Tool (FTT) 5. TN3270 Plus 6. Hiperstation 7. Load Runner Skill set specific to mainframe testing 1. COBOL 2. DB2 3. JCL 4. CICS 5. Assembler 6. VSAM 7. ISPF/TPF Is Mainframe testing a good job? Mainframe testing skill is a quite niche skill. Though many organizations are trying to move from less user friendly mainframe applications to modern client/server applications but it will still exist for a while. since the mainframe testing is difficult and trainings are not easily available so the demand of a mainframe tester is great in the market.