Hi Gabe;
I have a few quick comments:
1. 'We' are very dependent on IVPs provided by the suppliers when we first
install or upgrade system software products into a sandpit LPAR.
'We' also have a certain level of locally-developed integration testing
processes to follow, still in the sandpit.
There is a restricted list of responsible individuals who are then
invited to play in the sandpit.
2. Once the sandpit appears to be working to plan, the software can then
be rolled out into progressively more sophisticated (and sensitive)
environments.
Ideally, this is non-disruptive, or at least allowing easy fallback to the
current/working version.
Obviously more disruptive if we have to re-IPL to fall back to another level of
the OS.
There's a big difference between changes that can be tested at a higher level
concurrently with ongoing utilisation at a lower level, versus changes that
require some form of outage to fallback.
It all comes under risk management.
3. The number of levels in the hierarchy of sandpit > 'regression testing'
> QA > 'load testing' > production varies according to each use case.
'We' still use TPNS for load and regression testing of critical apps; there are
multiple ways to skin those cats
4. Not to mention the old adage: "Users are there to provide a test load
for system changes"
(Not so funny any more)
Regards; Phil Jones
Department of Human Services, ICT Infrastructure Division: Service Operations
Branch
Mainframe Infrastructure, Infrastructure as a Service
W/S # MG-W030, Ground Floor Millar Building, 134 Reed Street, Greenway, ACT 2900
W: +61 2 6191 9263 M: +61 412 658 580
[email protected]
HSR(-elect) DHS Canberra Work Group 8 - Main Building, Millar Building &
Computer Building
CPSU Delegate
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Gabe Goldberg
Sent: Thursday, 2 May 2019 5:45 AM
To: [email protected]
Subject: Fwd: Query for article on testing mainframe systems, applications,
networks
I've had a small number of great responses to this but nothing like the number
I usually get to queries. Surprising, I thought this would be an interesting
topic with many people commenting...
Testing -- what's that? How do you test/validate z/OS
systems/applications/networks?
-------- Forwarded Message --------
Subject: Query for article on testing mainframe systems, applications,
networks
Date: Mon, 29 Apr 2019 12:41:17 -0400
From: Gabe Goldberg <[email protected]<mailto:[email protected]>>
Query for article on testing mainframe systems, applications, networks
This is for website/magazine I'd not seen before: https://increment.com/ It's
described: Increment is a print and digital magazine about how teams build and
operate software systems at scale.
It has an interesting approach, devoting issues to topic themes such as
internationalization, security, documentation, programming languages, etc. My
article is for an issue on testing.
---
Modern systems -- especially mainframes and everything connected to them
-- require modern testing tools and procedures. The days are gone when it was
sufficient to SYSGEN, IPL, (maybe) run a few test batch jobs or interactive
scripts, and wait for user feedback. (The old joke, of course, was that users
existed to test system programmers' system
programs.)
Testing is often misunderstood and neglected when it should be a combination of
creative art and rigorous engineering. In these days of distributed,
mixed-platform, and cloud-hosted applications, potentially targeting millions
of users, developers casually testing their own code is also folly.
Comprehensive test suites and cumulative regression tests are essential tools
for preventing everything from ugly interfaces to catastrophic visible failures.
How widely used - and effective -- are techniques such as continuous
integration (https://en.wikipedia.org/wiki/Continuous_integration -- the
practice of merging all developer working copies to a shared mainline several
times a day) and DevOps (https://en.wikipedia.org/wiki/DevOps -- a set of
software development practices that combines software development and
information technology operations)?
Do testing practices differ for GUI-developed applications? Or GUI apps
themselves -- same as for complex spreadsheets -- is the second "G" in GIGO
"gospel" or "garbage"?
So -- what are current best practices for testing mainframe (z/OS, z/VM, z/VSE,
Linux) technology? This covers everything from applying one PTF to installing a
new operating system release/version, and from verifying batch/TSO operation to
validating end-to-end transaction processing across networks and multiple
servers.
Besides testing system updates and local applications, how do you test IBM
program products and ISV products?
ISVs -- how do YOU test products across supported environments?
While the article isn't explicitly about tuning or performance, surely those
are critical assessments too when making changes. And, to keep this topic
manageable, it does NOT include debugging when tests fail.
As usual, please copy replies to me directly to avoid them being buried in list
digests.
Thanks.
--
Gabriel Goldberg, Computers and Publishing, Inc.
[email protected]<mailto:[email protected]>
3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegold Twitter: GabeG0
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected]<mailto:[email protected]> with the message:
INFO IBM-MAIN
**********************************************************************
IMPORTANT: This e-mail is for the use of the intended recipient only and may
contain information that is confidential, commercially valuable and/or subject
to legal or parliamentary privilege. If you are not the intended recipient you
are notified that any review, re-transmission, disclosure, dissemination or
other use of, or taking of any action in reliance upon, this information is
prohibited and may result in severe penalties. If you have received this e-mail
in error please notify the sender immediately and delete all electronic and
hard copies of this transmission together with any attachments. Please consider
the environment before printing this e-mail
**********************************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
