testing in multiplatform environment

Click here to load reader

Download Testing in multiplatform environment

Post on 07-Aug-2015




1 download

Embed Size (px)


  2. 2. 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
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. Workbench for testing in multiplatform environment
  14. 14. 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.
  15. 15. 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
  16. 16. It is better to include two or more people because of the powerful synergistic effect i.e. synergism which means one individuals 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.
  17. 17. 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.
  18. 18. Work paper 1
  19. 19. 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.
  20. 20. Work Paper 2
  21. 21. 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.
  22. 22. 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).
  23. 23. 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 wont 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