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 completed - 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 that 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 reliability 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 testing and specification of test activities in order to meet the objectives and mission 2.Test analysis and design -> the activity during which general testing objectives are transformed into tangible test condifions and test cases Major tasks:

3.Test implementation and execution -> the activity where test procedures or scripts are specified by comining the test cases in a particular order and including any other information needed for test execution, the environment is set up and tests are run Major tasks: -

4.Evaluating exit criteria and reporting -> the activity there test execution is assesed against the defined objectives (should be done for each test level) Major tasks: 5.Test closure activities -> collect data from completed test activities to consolidate experience, testware, facts and numbers (occur at milestones) Major tasks: 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 the corresponding development activity - testers should be involved in reviewing documents as soon as drafts are available in the development life cycle

Test levels:
1. Component(unit) testing -> searcges for defects in, and verifies the functioning 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 - functional 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 integration testing as well as functional testing.

3. System testing -> is concerned with the behavior of a whole system/product, the 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-developed software IV. Alpha ad beta (or field) testing - Alpha -> performed at the developing organization's site but not by the developing 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 functions and features and their interoperability with specific systems, and may be performed at all test level; considers the external behavior of the software (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 performed 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; if 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 discover 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, migration 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) Success factors for reviews During test design the test cases and test data are created and specified. A test case consistsof a set of input values, exacution preconditions, expected results and execution preconditions , defined to cover a certain test objective or test condition.

During test implementationthe test cases are developed, implemented, prioritized and organized in the test procedure specification.

Specification based or black-box techniques

1.Equivalence partitioning -> groups that are expected to exhibit same behavior; valid or invalid 2.Boundary Value Analysis -> the max and min values of a partition are its boundary values; valid or invalid 3.Decision table testing 4.State transition testing 5.Use case testing

Structure based or white-box Techiques

1.Statement testing and coverage (Number of executable statements covered by test cases) / (Number of all executable statements in the code under test) 2.Decision testing and coverage (Number of all decision outcomes covered by test cases) / (Number of all possible decision outcomes in the code under test) 3.Other structure-based techniques 4.Experience- based techniques - error guessing - exploratory testing