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 testprocess 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 Requireme

nts

DesignSoftware

Build Software

InstallSoftware

Operate & maintain software

STEP 7Post

implementation analysis

STEP 1Organizing for

testing

STEP 2Developing the

Test PlanSTEP 3

Verification Testing

STEP 4Validation Testing

STEP 5Analyzing &

Reporting Test Results

STEP 6Acceptance & 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 ProcessTesters face three major challenges when testing in a multiplatform environment:1. Determining the type of platform that users operate for the processing2. Determining which software packages are available to those users3. Determining the type of processing users will perform in a multiplatform environment.

Testers must make judgments on the most likelyplatforms 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 testersneed 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 amultiplatform 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.

Work paper 1

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.

Work Paper 2

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 onlyX 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 themif 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 identifythese structural components.

Work Paper 3

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 tovalidate whether the interface is impacted by the platform.This same test for a single interface may have to be performed on multiple platforms.

Work Paper 4

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 challengethe 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

Work Paper(continued)

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.

ReferencesEffective Methods for Software Testing

(William E. Perry, Third Edition)