Test activities: - planning and control - choosing test conditions - designing and executing test cases - checking results

- evaluating testing criteria - reporting on the testing process and system under test - finalizing or completing closure activities after a test phase has been comple ted - reviewing documens, including source code - conducting static analysis Testing objectives - finding defects - gaining confidence about the level of quality - providing information for decision making - preventing defects Development testing -> main objective: cause as many failures as possible so tha t defects in the software are identified and can be fixed Acceptance testing -> main objective: confirm that the system works as expected, to gain confidence that it has met the requirements Maintenance testing -> includes testing that no new defects have been introduced during development of the changes Opreational testing -> main objective: assess system characteristics such as rel iability or availability Testing principles 1.Testing shows presence of defects 2.Exhaustive testing is impossible 3.Early testing 4.Defect clustering 5.Pesticide paradox 6.Testing is context depening 7.Absence-of-errors fallacy Fundamental test process - main activities: 1.Test planning and control -> the activity of defining the objectives of testin g and specification of test activities in order to meet the objectives and mission 2.Test analysis and design -> the activity during which general testing objectiv es are transformed into tangible test condifions and test cases 3.Test implementation and execution -> the activity where test procedures or scr ipts are specified by comining the test cases in a particular order and including any other information needed for test execution, the environment i s set up and tests are run 4.Evaluating exit criteria and reporting -> the activity there test execution is assesed against the defined objectives (should be done for each test level) 5.Test closure activities -> collect data from completed test activities to cons olidate experience, testware, facts and numbers (occur at milestones) A common type of V - model uses four test levels: Component(unit) testing Integration testing System testing Acceptance testing

In any life cycle model, there are several characteristics od good testing: - 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 th e corresponding development activity - testers should be involved in reviewing documents as soon as drafts are availa ble in the development life cycle Test levels: 1. Component(unit) testing -> searcges for defects in, and verifies the function ing of, software modules, programs, objects, classes, etc., that are separately testable Test basis: - component requirements - detalied design - code Typical test objects: - components - programs - data conversion / migration programs - database modules Component testing mat include testing of functionality and specific non - functi onal characteristics. 2. Integration testing -> tests interfaces between components, interactions with different parts of a system or interfaces between systems Test basis: - software and system design - srchitecture - workflows - use cases Typical test objects: - subsystems - database implementation - infrastructure - interfaces - system configuration and configuration data Testing if specific non-functional characteristics may be ingluded in integratio n testing as well as functional testing. 3. System testing -> is concerned with the behavior of a whole system/product, t he testing scope shall be clearly addressed in the test plan for the test level. Test basis: - system and software requirement specification - use cases - functional specification - risk analysis reports Typical test objects: - system, user and operation manuals - system configuration and configuration data System testing should invesitgate functional and non-functional requirements of the system, and data quality characteristics. 4. Acceptance testing - > the main goa is to establish confidence in the system, parts of the system or specific non- functional characterisitcs of the system Test basis: - user requirements

- system requirements - use cases - business processes - risk analysis reports Typical test objects: - business processes on fully integrated system - operational and maintenance processes - user procedures - forms - reports - configuration data Typical forms of acceptance testing: I. User acceptance tesing - verifies the fitness for use of the system by business users II. operational tesing - testing of backup/ restore - disaster recovery - user management - maintenance tasks - data load and migration tasks - periodic checks of security vulnerabilities III. Contract and regulation acceptance testing - performed against a contract acceptance criteria for producing custom-develope d software IV. Alpha ad beta (or field) testing - Alpha -> performed at the developing organization's site but not by the develo ping team - Beta -> performed by cursomers or potential customers at their own locations Test Types - Functional testing -> "what" the system does; functional tests are based on fu nctions and features and their interoperability with specific systems, and may be performed at all test level; considers the external behavior of the softw are (black box testing) - Non functional testing -> includes but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing; "how" the system works; may be perf ormed at all test levels; in most cases uses black-box test design techniques - Structural testing -> (white box) testing may be performed at all test levels; best used after specification based techniques, on order to help measure the thoroughness of testing through assessment of coverage of a type of structure; i f coverage is not 100% then more tests are needed. - Testing related to changes: re-testing and regression testing I. Re-testing - confirmation that a defect has been successfully removed. II. Regression testing - the repeted testing of an alreadt tested program to dis cover if any defects introduced or uncovered as a result of the changes; may be performed at all test levels Maintenance testing - id done on an existing operational system and is triggered by modifications, m igration or retirement of the software or system. Static testing techniques -> manual examination (reviews) and automated analysis of the code or other project documentation without the ececution of the code Activities of a formal review 1.Planning 2.Kick-off 3.Individual preparation 4.Examination/evaluation/recording of results - review meeting

5.Rework 6.Follow-up Roles: manager, moderator, author, reviewers, scribe (or recorder) Types of revirews: 1. Informal review -> no formal process 2. Walkthrough -> led by author 3. Technical review 4. Inspection -> led by trained moderator (not the author)