Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 2: Testing throughout the life cycle - Coggle Diagram
Chapter 2: Testing throughout the life cycle
Test levels (Chapter 2.2)
2.2 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.
2.3 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.
2.1 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.
2.4 Acceptance testing
When the development organization has performed its system test and has cor-rected all or most defects, the system will be delivered to the user or customer for acceptance testing.
Software developments models (Chapter 2.1)
Manifesto for Agile Software Development
The 4 values of Agile
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Working software over comprehensive documentation.
Individuals and interactions over processes and tools.
The 12 principles of Agile
2.Breaking big work down into smaller tasks that can be completed quickly.
3.Recognizing that the best work emerges from self-organized teams.
1.Satisfying customers through early and continuous delivery of valuable work.
4.Providing motivated individuals with the environment and support they need and trusting them to get the job done.
5.Creating processes that promote sustainable efforts.
6.Maintaining a constant pace for completed work.
7.Welcoming changing requirements, even late in a project.
8.Assembling the project team and business owners on a daily basis throughout the project.
9.Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
10.Measuring progress by the amount of completed work.
11.Continually seeking excellence.
12.Harnessing change for a competitive advantage.
1.2 Testing within a life cycle model
In summary, whichever life cycle model is being used, there are several charac-teristics of good testing:
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.
For every development activity there is a corresponding testing activity.
Testers should be involved in reviewing documents as soon as drafts are avail able in the development cycle.
Test types: the targets of testing (Chapter 3.1)
3.4 Testing related to changes (confirmation and regression testing)
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.
The way to detect these 'unexpected side-effects' of fixes is to do regression testing.
The final target of testing is the testing of changes.
3.3 Testing of software structure/architecture (structural testing)
Coverage measurement tools assess the percentage of executable elements (e.g. statements or decision outcomes).
The techniques used for structural testing are structure-based techniques, also referred to as white-box techniques.
The third target of testing is the structure of the system or component.
Control flow models are often used to support structural testing.
3.2 Testing of software product characteristics (non-functional testing)
A second target for testing is the testing of the quality characteristics, or nonfunctional attributes of the system.
Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing.
3.1 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.
Function (or functionality) testing can be done focusing on suitability, interoperability, security, accuracy and compliance.
Maintenance testing
4.1. Impact analysis and regression testing
Usually maintenance testing will consist of two parts:
Testing the changes.
Regression tests to show that the rest of the system has not been affected by the maintenance work.
In addition to testing what has been changed, maintenance testing includes extensive .
4.2. Triggers for maintenance testing.
Ad-hoc corrective modifications.
Ad-hoc corrective modifications are concerned with defects requiring an immediate solution.
Since modifications are most often the main part of maintenance testing foi most organizations, this will be discussed in more detail.
A risk analysis of the operational systems should be performed.
As stated maintenance testing is done on an existing operational system.
Planned modifications: The following types of planned modification may be identified:
Adaptive modifications (adapting software to environmental changes).
Corrective planned modifications (deferrable correction of defects).
Perfective modifications (adapting software to the user's wishes).
The development and test process applicable to new developments does not change fundamentally for maintenance purposes.
Note that maintenance testing is different from maintainability testing, which defines how easy it is to maintain the system.
Testing that is executed during this life cycle phase is called 'maintenance testing.