Ppt 2 testing throughout the software life cycle
- 1. TESTING THROUGHOUT THE SOFTWARE LIFE CYCLE
- 2. SANTI SURYANI 11453201759 http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/ Pekanbaru, SISTEM INFORMASI SAINS DAN TEKNOLOGI UIN SUSKA RIAU
- 3. SOFTWARE DEVELOPMENT MODELS V-model The V-model was developed to address some of the problems experienced using the traditional waterfall approach
- 4. The four test levels used, each with their own objectives, are: Searches for defects in and verifies the functioning of software components (e.g. modules, programs, objects, classes etc.) that are separately testable. Tests interfaces between components, interactions to different parts of a system such as an operating system, file system and hard ware or interfaces between systems concerned with the behavior of the whole system/product as defined by the scope of a development project or product. The main focus of system testing is verification against specified requirements. validation testing with respect to user needs, require ments, and business processes conducted to determine whether or not to accept the system. Component Testing Integration Testing System Testing Acceptance Testing
- 6. Iterative Life Cycles Not all life cycles are sequential. There are also iterative or incremental life cycles where, instead of one large development time line from beginning to end, we cycle through a number of smaller self-contained life cycle phases for the same project. A common feature of iterative approaches is that the delivery is divided into increments or builds with each increment adding new functionality. The initial increment will contain the infrastructure required to support the initial build functionality. The increment produced by an iteration may be tested at several levels as part of its development. Subsequent increments will need testing for the new functionality, regression testing of the existing functionality, and integration testing of both new and existing parts. Regression testing is increasingly important on all iterations after the first one. This means that more testing will be required at each subsequent delivery phase which must be allowed for in the project plans. This life cycle can give early market presence with critical functionality, can be simpler to manage because the workload is divided into smaller pieces, and can reduce initial investment although it may cost more in the long run. Also early market presence will mean validation testing is carried out at each increment, thereby giving early feedback on the business value and fitness-for-use of the product
- 8. Testing within a life cycle model for every development activity there is a corresponding testing activity; each test level has test objectives specific to that level; the analysis and design of tests for a given test level should begin during the corresponding development activity; testers should be involved in reviewing documents as soon as drafts are avail able in the development cycle.
- 9. TEST LEVELS Component Testing Component testing, also known as unit, module and program testing, searches for defects in, and verifies the functioning of software (e.g. modules, programs, objects, classes, etc.) that are separately testable. Component testing may include testing of functionality and specific non- functional characteristics such as resource-behavior (e.g. memory leaks), performance or robustness testing, as well as structural testing (e.g. decision coverage). Test cases are derived from work products such as the software design or the data model.
- 10. Integration testing Integration testing tests interfaces between components, interactions to different parts of a system such as an operating system, file system and hardware or interfaces between systems. Note that integration testing should be differentiated from other integration activities. Integration testing is often carried out by the integrator, but preferably by a specific integration tester or test team. System testing System testing is concerned with the behavior of the whole system/product as defined by the scope of a development project or product. It may include tests based on risks and/or requirements specification, business processes, use cases, or other high level descriptions of system behavior, interactions with the operating system, and system resources. System testing is most often the final test on behalf of development to verify that the system to be delivered meets the specification and its purpose may be to find as many defects as possible.
- 11. Acceptance Testing The goal of acceptance testing is to establish confidence in the system, part of the system or specific non-functional characteristics, e.g. usability, of the system. Acceptance testing is most often focused on a validation type of testing, whereby we are trying to determine whether the system is fit for purpose. Finding defects should not be the main focus in acceptance testing. Although it assesses the system's readiness for deployment and use, it is not necessarily the final level of testing. For example, a large-scale system integration test may come after the acceptance of a system.
- 12. TEST TYPES: THE TARGETS OF TESTING Test types are introduced as a means of clearly defining the objective of a certain test level for a programme or project. We need to think about different types of testing because testing the functionality of the component or system may not be sufficient at each level to meet the overall test objectives. Focusing the testing on a specific test objective and, therefore, selecting the appropriate type of test helps making and communicating decisions against test objectives easier.
- 13. Testing of function (functional testing) The function of a system (or component) is 'what it does'. This is typically described in a requirements specification, a functional specification, or in use cases. There may be some functions that are 'assumed' to be provided that are not documented that are also part of the requirement for a system, though it is difficult to test against undocumented and implicit requirements. Functional tests are based on these functions, described in documents or understood by the testers and may be performed at all test levels (e.g. test for components may be based on a component specification)
- 14. Testing of software product characteristics (non-functional testing) A second target for testing is the testing of the quality characteristics, or non-functional attributes of the system (or component or integration group). Here we are interested in how well or how fast something is done. We are testing something that we need to measure on a scale of measurement, for example time to respond. Non-functional testing, as functional testing, is performed at all test levels. Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing. It is the testing of 'how well' the system works.
- 15. The characteristics and their sub-characteristics are, respectively: which consists of five sub-characteristics: suitability, accuracy, security, interoperability and compliance; this characteristic deals with func tional testing as described in Section 2.3.1; Functionality which is defined further into the sub-characteristics maturity (robustness), fault-tolerance, recoverability and compliance Reliability which is divided into the sub-characteristics understandability, learnability, operability, attractiveness and compliance; Usability Efficiency which is divided into the sub-characteristics understandability, learnability, operability, attractiveness and compliance; Maintainabili ty which consists of five sub-characteristics: analyzability, changeability, stability, testability and compliance Portability which also consists of five sub-characteristics: adaptability, installability, co-existence, replaceability and compliance
- 16. Testing of software structure/architecture (structural testing) The third target of testing is the structure of the system or component. If we are talking about the structure of a system, we may call it the system architecture. Structural testing is often referred to as 'white-box' or 'glass-box' because we are interested in what is happening 'inside the box'. Structural testing is most often used as a way of measuring the thoroughness of testing through the coverage of a set of structural elements or coverage items. It can occur at any test level, although is it true to say that it tends to be mostly applied at component and integration and generally is less likely at higher test levels, except for business-process testing. At component integration level it may be based on the architecture of the system, such as a calling hierarchy. A system, system integration or acceptance testing test basis could be a business model or menu structure.
- 17. Testing related to changes (confirmation and regression testing) The final target of testing is the testing of changes. This category is slightly different to the others because if you have made a change to the software, you will have changed the way it functions, the way it performs (or both) and its structure. However we are looking here at the specific types of tests relating to changes, even though they may include all of the other test types
- 18. MAINTENANCE TESTING Once deployed, a system is often in service for years or even decades. During this time the system and its operational environment is often corrected, changed or extended. Testing that is executed during this life cycle phase is called 'maintenance testing'. Note that maintenance testing is different from maintainability testing, which defines how easy it is to maintain the system.
- 19. •Usually maintenance testing will consist of two parts: •1. Testing the changes •2. regression tests to show that the rest of the system has not been affected by the maintenance work. 1.Planned modifications 2.Ad-hoc corrective modifications Impact analysis and regression testing Triggers for maintenance testing
- 20. THANK YOU