Focus on Application Testing
This is the third post in this series on system and application testing on enterprise systems. In this post, I discuss the daunting job of being a mainframe application programmer and how he or she goes about testing. The testing scope can cover everything from deployment of a new release of ISV software to a specific fix made to an in-house application. What is daunting about the job of mainframe application programmer? What does that person do?
Application Programmers Need a Strong Set of Skills
The textbook description of application programmers indicates that they design, build, test and deliver mainframe applications for the company’s end users. Based on requirements gathered from business analysts, the application designer creates a design specification that the programmer uses to construct application programs. In addition to creating new application code, programmers are responsible for maintaining and enhancing the company’s existing mainframe applications. Today, this is often the main job for many mainframe application programmers. Recently, The New York Times reported, “More than 200 billion lines of COBOL code are now in use and an estimated 2 billion lines are added or changed each year, according to IBM Research.”
When you look at the job openings for mainframe application programmers you see, firsthand, why the job can be characterized as daunting. Application programmers are expected to have domain experience (e.g., credit card or retail banking experience for financial services and banking companies). Application programmers are expected to have mature personal attributes like being self-motivated and a quick-learner that can take the full ownership of designs from concept to support. They need to understand stakeholder’s expectations and objectives, work independently and ensure processes are followed at all System Development Life Cycle stages and more.
Regarding specific technology, they need to know the IBM mainframe and z/OS plus COBOL, JCL, VSAM, TSO, ISPF, File Manager, BMC, Expeditor for Batch and Online, CA-7 and others. They also need to know how to develop and test complex batch and online COBOL programs utilizing both DB2 and VSAM. This is just a sample of the specific software related skills required. Interesting, challenging and daunting all at the same time.
What Test Activities With Applications?
Enterprise applications often exist in a business context with other applications—they interact and need to work together. To support this, the designer and programmer typically interact with other IT people in the organization. For example, a programmer might work on a team with other programmers who are building interface modules for related application programs. When development of an interface module is completed, this module would be passed through a testing process including function, integration and systemwide tests.
Following these tests, the application programs must be acceptance tested by the user community to determine whether the code actually satisfies the original user requirement. This narrative describes a flow that supports a waterfall approach but certainly could pertain to other approaches as well. Doesn’t every development approach need to determine whether the code actually satisfies the original user requirement?
The difference between systemwide tests and the testing done during the development phase is that programmers and users are now testing the application as a whole, and how it works with other related applications. User testing is being performed to check the application for functionality and usability. The purpose of integration testing is to make sure the new application is tested together with other applications to see if they work together as expected. Performance or stress testing is often done using real production data or real production data volume to see how well the application performs when there’s high demand.
Issues coming out of these tests need to be addressed before going into production. Sometimes, fixing problems can take more resourcefulness than the initial effort of creating the necessary parts of the application.
How Many Application Programmers?
Of course, the answer is “it depends.” Generally, the number of application programmers depends on the number of enterprise application and their modules and the role of the developers. Developing and maintaining in-house applications is different than administering a suite of ISV applications to support an enterprise. Like with systems programmer, skill specialization is also a factor. An application developer with strong database skills best supports applications that make diverse used of a DBMS. Any casual database user who has ever tried to code a rich SQL statement knows this to be true.
SHARE, the mainframe user group, represents more than 20,000 individuals from nearly 2,000 companies including state and federal government agencies, universities, retail, energy, manufacturing, banks and insurance companies. SHARE reports that in 2013:
- 96 of the world’s top 100 banks, 23 of the 25 top U.S. retailers, and 9 out of 10 of the world’s largest insurance companies run IBM Z
- Seventy-one percent of global Fortune 500 companies are IBM Z clients
- Nine out of the top 10 global life and health insurance providers process their high-volume transactions on an IBM Z mainframe
- Mainframes process roughly 30 billion business transactions per day, including most major credit card transactions and stock trades, money transfers, manufacturing processes, and ERP systems
This doesn’t directly answer the question—how many application programmers, however, it gives a strong message that the opportunities are there for a long career in mainframe IT. In the next post, I will finish up this discussion about system and application on enterprise systems.