Welcome to System z Platform Test, also known as Integration Test.
We'd like to explain to you exactly what we mean by
"integration test" and how that concept works for z/OS and Linux.
The concept behind integration test is pretty simple:
if two software products are going to run together on the same
operating system platform, they have to be tested together with
a focus on their interactions.
When you're working with an operating system
such as z/OS (which itself is comprised of numerous elements
and features, and on which many other products must run and
coexist) or Linux, the testing becomes considerably more complex--and
considerably more important--but the concept is the same.
All the elements and features of z/OS must work together
and because nobody runs just an operating system,
we have to make sure it works with a multitude of other products
and functions.
At IBM, product testing is and always has been extensive.
Integration test is not a replacement for other IBM test efforts.
We still perform what we think of as three classical test phases:
unit test, function test, and system test--you might know them
by other names in your own environment.
These test phases mainly focus on an individual
product or function, or on a subset of products and functions.
To further enhance quality, we built on the foundation provided
by unit, function, and system test by adding an additional
test effort--integration test.
With integration test, there's greater emphasis on the customer
experience, cross-product dependencies, and sensitivity to end
users.
System z Platform test is the final verification of a z/OS release
prior to its becoming generally available to customers. If you'll allow
us to borrow a famous phrase, the buck stops here.
Our job as members of the System z Platform test team is to ensure that
all the elements and features of z/OS work seamlessly together and can
support true production, mission-critical work while also providing all the
industrial-strength z/OS advantages you're depending on:
reliability, availability, serviceability.
Our objective is to validate the System z software platform in a manner
such that you, our customers, might use it. That means doing much more
than just ensuring that products work together--it means understanding
what it takes to introduce, implement, and effectively use new products
and functions in a full production environment while thousands of end
users are expecting constant availability. In other words, we want to
experience for ourselves the challenge of integrating various solutions
into a business environment. And we want to experience it first, so we
can hopefully save you some pain!
We document the results of our testing (including any pain we've
experienced and how you can avoid that pain) in our
test
reports. We provide
tested
examples, both in our test reports and here on our Web site,
that span multiple products and have been run in what we call a
pseudo-production environment.
Does all of this mean you
will never again find a bug in an z/OS release? Well, nothing
would make us happier! But that's a claim we cannot possibly
make--we don't believe any software test organization could
truthfully make such a claim about their product. The claim we
can make is this: we endeavor to provide you with
the most stable operating system platform available in the
marketplace--z/OS.
So, what do we mean by a
pseudo-production environment? Well, we've set ourselves up to be
as customer-like as possible. Our team is organized in a way that
many IT shops are, and our team members take on the roles of system
programmers, operators, database administrators, and so on. We
focus on providing availability of applications to end users, and
we pay attention to service level agreements and performance
objectives. We look at the recovery aspects and behavior of our
systems from an end user's perspective.
Our goal, like yours, is to have our workloads up
24 hours a day, 7 days a week (24 x 7). We have workloads that exercise
the sysplex, networking, and application enablement characteristics of
our configuration.
For details about our workloads, see the Our Workloads topic in
our test reports.
For details about our test configuration, see the hardware configuration, software configuration,
and networking configuration topics in
our test reports.
|