Enterprise Testing
This is the first post in this series on system and application testing on enterprise systems. On mainframes, there are two kinds of programmers—application programmers and system programmers. They are both developers but they operate in different circles because their jobs are fundamentally different. They collaborate with each other, especially when system programmers launch a new middleware release or when application programmers are deploying a major new application. Testing is a place where they need to come together, otherwise there can be serious finger pointing when things don’t go well and there are availability or performance problems with a system or enterprise application.
Testing Was A Sore Spot for Many Programmers
If my experience is any measure, 40 years ago application testing was not a very mature idea. When I began as an application programmer, program specs had barely a paragraph on testing. On top of this, our test systems were often wholly insufficient. We tried to test new application with basic mapping support outputs and we had no 3270 displays on the test system so we tested in production. When the test system came up in the morning, everybody signed on to test and it immediately went down. Those were the days when COBOL programmers had CICS BAL Macros (see Macro-level programming) in their programs and had direct addressability to the TCA, CSA, TIOA and other control blocks. When you interviewed for a new job, you asked the potential employer about their test systems because you wanted some assurance if you left one job for another you would at least have an adequate chance to test you programs.
How Has Testing Changed Over The Years?
Flash forward to today and testing has evolved into a separate and mature discipline. This didn’t just happen, it was driven by many factors involving risk, cost and timeliness. Many enterprise applications became mission critical so effective testing was a major way to lower the risk of a application failure. As enterprise applications increased in complexity, multi-phase testing was employed to catch problems at the earliest step—finding problems at unit testing were cheaper to fix than finding them at system test. Techniques like continuous testing emerged as a way to rapidly deploy changes—many times daily—without needing days to QA the change from test to integration to system then to production.
Testing has developed into a discrete profession and this is reflected on the popular job-finding sites. Indeed.com lists more than 150 jobs for a mainframe tester. Glassdoor.com lists about 75 mainframe jobs. Salaries range from $40 to $100K. Titles are diverse—Mainframe Tester, Manual Tester, Automation Tester, Big Data Tester and Business Analyst/Quality Assurance Tester are examples. The Career Path of A Software Tester infographic is useful in understanding the potential steps in the profession of a tester.
Want to Read More About Testing as a Discipline?
For more information try these sources below. The first source is an article and the second is a presentation. Software Testing Primer from Software Project Manager covers the topic by exploring more that 50 ideas in the discussion of most aspects of testing.
Product Manager “Primer” for Software Testing & Quality by Bob Galen is a comprehensive presentation that discusses different types of testing, setting meaningful testing milestones, risk from a testing perspective and managing test automation and other topics.
What’s Next?
In the three posts to come, I’ll explore the different testing used by system and application programmers and write about some interesting tools that have emerged to help testing to be even more effective. Testing is not standing still. As new demands are placed on enterprise applications, testing responds with new approaches and tools.