Testing in multiplatform environment

PRESENTATION
ON
TESTING IN MULTIPLATFORM
ENVIRONMENT
PRESENTED BY-
Shivani Chauhan
ME CSE (Regular)
CSE Department

Introduction-
 This testing focuses on what should be the major
risks faced in operating a single software
package on many different platforms.
 It is essential that the software to be tested on
multiple platforms be validated prior to
multiplatform testing.
 Combining software validation testing with
multiplatform testing normally will slow the test
process and increase the cost.
 Multiplatform testing is a costly, time-
consuming, and extensive component of testing

Software designed to run on more than
one platform must undergo two tests-
1. The first step is to validate that the
software performs its intended functions.
This involves seven-step testing process.
2. The second step is that the software will
perform in the same manner regardless
of the platform on which it is executed.
This is a six-task testing process.

Seven-Step Process
 The seven step process represents the
software development process and the
seven-step software testing process.
 Both processes commence at the same
time and proceed concurrently through the
end of the project.

Seven-Step Software Testing Process
Define
Requirement
s
Design
Software
Build
Software
Install
Software
Operate &
maintain
software
STEP 7
Post implementation
analysis
STEP 1
Organizing for
testing
STEP 2
Developing the Test
Plan
STEP 3
Verification Testing
STEP 4
Validation Testing
STEP 5
Analyzing & Reporting
Test Results
STEP 6
Acceptance &
Operational Testing

Contd…
1. Organizing for testing-
a. Define test scope- Determine which type of
testing is to be performed.
b. Organize the test team- Determine who should
be assigned to the test team, based on the type of
testing to be performed.
c. Assess development plan & status- Testers will
check the completeness & correctness of the
project plan & estimate the amount of resources
they will need to test the implemented software.

2. Developing the test plan-
a. Perform risk analysis- Identify the test risks.
b. Write the test plan- Test plan should be written
properly and follow the same step as any software
planning process.
3. Verification testing-
a. Test software requirements- Testers must
determine that the requirements are accurate and
complete & do not conflict with one another.
b. Test software design- Tests both external &
internal design through verification techniques.
c. Test software construction- It is cheaper to identify
defects during the construction phase.

4. Validation Testing-
a. Testing of code in a dynamic state.
b. Record the results.
5. Analyzing and Reporting test results-
a. Analyze the test results- Examine the test results
to determine where action is required.
b. Develop test reports- It may be oral & written and
should be reported to appropriate parties as early as
possible so that they can be corrected at the lowest
possible cost.

6. Acceptance and operational testing-
a. Perform acceptance testing- It enables users of
the software to evaluate the applicability and usability
of the software in performing their day-to-day
functions.
b. Test software installation- This tests the interface
to operating software, related software and operating
procedures.
c. Test software changes- Whenever requirements
change, the test plan must change and the impact of
that change on software systems must be tested and
evaluated.

7. Post-implementation analysis-
Test improvements can be achieved by evaluating
the effectiveness of testing at the end of each software
test assignment. It should include developers, users of
the software and quality assurance professionals.

Six-Task Process
Testers face three major challenges when testing
in a multiplatform environment:
1. Determining the type of platform that users
operate for the processing
2. Determining which software packages are
available to those users
3. Determining the type of processing users will
perform in a multiplatform environment.
Testers must make judgments on the most likely
platforms to be used, the most likely software
packages possessed by the users, and the most
likely actions users will perform on a multiplat-
form environment.

In developing a test plan for testing in a
multiplatform environment, the testers
need to make decisions regarding those three
challenges. If a test plan is viewed as a contract,
then in the test plan the testers can state:
■Testing will occur on these platforms.
■Testing will validate that these software
packages are useable in processing in a
multiplatform environment.
■Only a defined number of uses will be tested.
Testers should attempt to identify the risks
associated with not testing on certain platforms,
certain packages, or certain application processes.

Workbench for testing in multiplatform environment

1.Input-
The two inputs for testing in a multiplatform
environment are as follows:
1.A list of the platforms on which software must
execute.
2. The software package(s) to be tested is input to
the test process. This software must be validated
that it performs its functions correctly prior to
multiplatform testing.

Task 1: Define Platform Configuration
Concerns
Develop a list of potential concerns about the
environment and determine their validity.
 Process for identifying concerns is error guessing,
which attempts to anticipate problems within the software
package and its operation.
 Studies by IBM- Same types of software defects occur
with the same frequency from project to project.
(example- problem of data exceeding its allocated field)
Error guessing requires that the error-guessing group
understands how the platform works and knows how the
software functions.
Preferable to involve the group who tested the software
functions as they will know how software works.
2.Do Procedures

It is better to include two or more people because of
the powerful synergistic effect i.e. synergism which
means one individual’s comments spark another
individual to think.
Requires a recorder to write down the ideas
developed.
Each member is allowed time to express what he or
she believes.
After initial-go round, recorder reads back the items
and open or interactive discussion commences.
There can be no criticism of errors raised or the
individual who raised them. All comments must be
stated positively.
Permission of criticism will cease the
communication and value of the process will be lost.
The error guessing process lasts no longer then 15
minutes and rarely exceed 1 hour.

The group should be removed from normal business
interruptions as the process require total concentration.
The end product is a list of potential error conditions for
additional investigation and testing.
The following is a short list of some questions to
brainstorm during error guessing--
■Does the software have any unusual transactions?
■What are the most common errors that you are now making?
■What would happen if you forgot to perform one of the steps?
■What would happen if you did not enter all of the data in an input
transaction?
■Will you be able to determine who performed what computer operation in
case questions arise regarding the correctness of operations?
 The questions are not intended to be complete, nor do
they need to be answered precisely. Their sole purpose is
to steer you into areas for further exploration regarding
potential errors.

Task 2: List Needed Platform Configurations
The needed platforms are either those that will be
advertised as acceptable for using the software, or
platforms within an organization on which the software
will be executed.
Testers must then determine whether those platforms are
available for testing.
If the exact platform is not available, the testers need to
determine whether an existing platform is acceptable.
If the needed platform is not available, the testers must
make a determination of whether to obtain such a platform
or accept the risk that the software will be released without
testing that specific platform.

Task 3: Assess Test Room Configurations
The testers need to determine whether the platforms
available in the test room are acceptable for testing. This
involves the following two steps:
1. For each needed platform , document the platform to
be used for testing.
2. Make a determination as to whether the available
platform is acceptable for testing. If the platform is not
acceptable, note any actions to be taken.

Task 4: List Structural Components Affected by the
Platform(s)
Structural testing deals with the architecture of the
system. Architecture describes how the system is put
together.
Some of the architectural problems that could affect
computer processing include:
■ Internal limits on the number of events that can
occur in a transaction (example, the number of products
that can be included on an invoice).
■ Maximum size of fields (example, the quantity is only
two positions in length, making it impossible to enter an
order for more than 99 items).
■ Disk storage limitations (for example, you are
permitted to have only
X customers).
■ Performance limitations (for example, the time to
process transactions jumps significantly when you enter
more than X transactions).

Each software system is finite and has built-in
limitations. Sometimes the vendor tells you these
limitations, sometimes you can find them
if you search through the documentation, and sometimes
you won’t know them until they occur.
Structural testing also relates to file-handling problems.
Such file problems include incorrect processing
when the last record on file is updated or adding a record
that will become the first record on a file.
The test team needs to identify the structural
components of functions that will be affected by the
platform. They may want to use the error-guessing
technique described in Task 1 to identify
these structural components.

Task 5: List Interfaces the platform Affects
Systems tend to fail at interface points—that is, the
points at which control is passed from one processing
component to another (for example, when data is retrieved
from a database, output reports are printed or transmitted,
or a person interrupts processing to make a correction).
The purpose of this task is to identify those interfaces
so that they can be tested. Some of these interfaces will
also overlap the software structural components affected
by the platform.
If the test has been included in the structural component
task Work Paper, it need not be duplicated in the test
recommended in this task.

This is a two-part task-
The first part is to identify the interfaces within the
software systems. These interfaces should be readily
identifiable in the software’s user manual.
The second part is to determine whether those
interfaces could be affected by the specific platform on
which the software executes. This is a judgmental
exercise.
The Work Paper should identify the platform on which
the interface may be affected, the interface itself, the
interface both to and from the potential effect of the
platform, and the test(s) that should be undertaken to
validate whether the interface is impacted by the platform.
This same test for a single interface may have to be
performed on multiple platforms.

Task 6: Execute the Tests
The platform test should be executed in the same manner
as other tests are executed in the seven-step software
testing process.
 The only difference may be that the same test would be
performed on multiple platforms to determine that
consistent processing occurs.

3.Check Procedures-
Prior to completing multiplatform testing, determination
should be made that testing was performed correctly.
Work Paper provides a series of questions to challenge
the correctness of multiplatform testing.
A Yes response to those items indicates that
multiplatform testing was performed correctly.
A No response indicates that it may or may not have
been done correctly.
Each No response should be clarified in the Comments
column.
The N/A column is for items that are not applicable to
this specific platform test.

Work Paper 5- For Multiplatform Quality
Control checklist

4.Output-
The output from this test process is a report
indicating the following:
■Structural components that work or don’t work
by platform.
■Interfaces that work or don’t work by platform.
■Multiplatform operational concerns that have
been eliminated or substantiated
■Platforms on which the software should operate
but that have not been tested.
The report will be used to clarify the software’s
operating instructions and/or make changes to the
software.

References
 Effective Methods for Software Testing
(William E. Perry, Third Edition)

Testing in multiplatform environment

Testing in multiplatform environment

Recommended

More Related Content

What's hot (20)

Similar to Testing in multiplatform environment (20)

Recently uploaded (20)

Testing in multiplatform environment