Types of Software Testing, Slides of Software Engineering

Download Types of Software Testing and more Slides Software Engineering in PDF only on Docsity!

Levels of Testing

• Component Testing (White Box)
• Integration Testing
• System Testing
• Acceptance Testing

Component Testing

• Unit, module and program testing.
• Searches for defect and verifies function of software items.
• It includes database component, database tables, joins, views,procedure etc.

Component Testing

• Individual components are tested.
• It is a path test.
• To focus on a relatively small segment of code and aim to exercise a high percentage of the internal path.

Component Testing

• Algorithms and logic
• Data structures (global and local)
• Interfaces
• Independent paths
• Boundary conditions
• Error handling

Component Testing

• Uses stubs and drivers.
• A stub is called from the software component to be tested.
• Driver call component to be tested.
• Defect are fixed as soon as they found without formally recording incident.

Integration Testing

• It interfaces between component
• Interaction to different parts to system such

as OS, file system and hardware.

• All program are integrated one by one and

test is carried out after each step.

• In this incremental approach, defect are

found at early stage.

Integration Testing

• Top-down Integration Test
• Bottom-up Integration Test

Top-down Integration Test

• The control program is tested first. Modules are integrated one at a time. Emphasize on interface testing
• Advantages: No test drivers needed Interface errors are discovered early Modular features aid debugging

Top-Down Integration

1. The main control module is used as a driver, and stubs are substituted for all modules directly subordinate to the main module.
2. Depending on the integration approach selected (depth or breadth first), subordinate stubs are replaced by modules one at a time.

Top-Down Integration (cont’d)

3. Tests are run as each individual module is integrated.
4. On the successful completion of a set of tests, another stub is replaced with a real module
5. Regression testing is performed to ensure that errors have not developed as result of integrating new modules

Problems with Top-Down Integration

• Many times, calculations are performed in the modules at the bottom of the hierarchy
• Stubs typically do not pass data up to the higher modules
• Delaying testing until lower-level modules are ready usually results in integrating many modules at the same time rather than one at a time
• Developing stubs that can pass data up is almost as much work as developing the actual module

A B T T T A B C T T T T Top-down Testing

Bottom-up Integration Test

• Allow early testing aimed at proving feasibility Emphasize on module functionality and performance
• Advantages: No test stubs are needed Errors in critical modules are found early
• Disadvantages: Test drivers are needed Interface errors are discovered late

Bottom-Up Integration

• Integration begins with the lowest-level modules, which are combined into clusters, or builds, that perform a specific software subfunction
• Drivers (control programs developed as stubs) are written to coordinate test case input and output
• The cluster is tested
• Drivers are removed and clusters are combined moving upward in the program structure

Problems with Bottom-Up Integration

• The whole program does not exist until the last module is integrated
• Timing and resource contention problems are not found until late in the process

Test Drivers Level N Level N- 1 Level N- 1 Level N Level N Test Drivers Test Drivers Test Drivers Test Drivers Bottom-up testing

System Testing

• Concerned with behavior of whole product.
• It includes risk analysis reports, system, functional,

and SRS.

• It check system to be delivered meets the

specification and its purpose may be to find as

many as defects.

17

System Testing

◼ In some organization it is carried out by

third party.

◼ It investigate both functional and non-

functional requirement.

◼ Non-functional includes performance

and reliability.

System Testing

◼ It is executed by development

organization.

◼ It starts with black box technique.

◼ It must be in controlled environment

and this environment correspond to

final target.

Acceptance Testing ◼ When development organization completes development and bugs are removed then they moved to acceptance testing. ◼ It is based on ◼ User requirement ◼ System requirement ◼ Use cases ◼ Business process ◼ Risk analysis report

Acceptance Testing

◼ It can following question

◼ Can the system be released? ◼ Has development meet requirement?

Acceptance Testing ◼ It is validation type of testing ◼ Focuses on functionality and validating fitness for use. ◼ Performed by user and application manager. ◼ Operational acceptance test involves ◼ Backup/restore ◼ Data load ◼ Migration task ◼ Disaster recovery ◼ User management ◼ Maintenance task ◼ Periodic check of security vulnerability

Objective of Acceptance Testing

• Confirm that the system meets the agreed upon criteria
• Identify and resolve discrepancies, if there is any
• Determine the readiness of the system for cut- over to live operations 23

Acceptance Criteria

• Functional Correctness and Completeness
• Accuracy
• Data Integrity
• Data Conversion
• Backup and Recovery
• Competitive Edge
• Usability
• Performance
• Start-up Time
• Stress
• Reliability and Availability 24 - Maintainability and Serviceability - Robustness - Timeliness - Confidentiality and Availability - Compliance - Installability and Upgradability - Scalability - Documentation

Acceptance Testing

• Acceptance testing is a formal testing conducted to determine whether a system satisfies its acceptance criteria
• There are two categories of acceptance testing: - User Acceptance Testing (UAT) - Business Acceptance Testing (BAT) 25