Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter2:Testing throughout the software life cycle - Coggle Diagram
Chapter2:Testing throughout the software life cycle
2.3-TEST TYPES: THE TARGETS OF TESTING
2.3.2 Testing of software product characteristics
(non-functional testing) includes, but is not limited to,
stress testing
Usability testing
load testing
maintainability testing
performance testing
reliability testing
portability testing
efficiency testing
2.3.1 Testing of function (functional testing): focusing on suitability, interoperability, security, accuracy and compliance
Requirements-based testing uses a specification of the functional requirements for the system as the basis for designing tests.
Business-process-based testing uses knowledge of the business processes.
Business processes describe the scenarios involved in the day-to-day business
use of the system.
2.3.4 Testing related to changes (confirmation and regression
testing)
Test fail->Determine the cause ->The bug is reported
->New version (fixed bug)->Re-testing
It is important to ensure that the test is
executed in exactly the same way as it was the first time,using the same inputs,
data and environment.
The difference is that for regression testing, the test cases may be true the last time they were executed.
2.3.3 Testing of software structure/architecture (structural
testing) referred to as “white boxes” or “glass boxes”.
It can happen at any level of testing, mainly in component testing, integration.
Structural testing is often used as a measure of testing.
2.1 SOFTWARE DEVELOPMENT MODELS
2.1.2 Iterative life cycles
Agile development
Extreme Programming (XP) 's characteristics
It promotes pair programming and shared code ownership amongst the
developers.
It states that component test scripts shall be written before the code is
written and that those tests should be automated.
It demands an on-site customer for continual feedback and to define and
carry out functional acceptance testing.
It states that integration and testing of the code shall happen several times
a day.
It promotes the generation of business stories to define the functionality
It states that we always implement the simplest solution to meet today's
problems.
Rapid Application Development (RAD)
Pros
Increase the reusability of finished products.
Quickly make assessments and comments for easy adjustment.
Reduced development time.
Clearly visible progression
Speed
Consistent feedback
Cons
Requires feedback
This model is a special model, so it is used only when there is a need to create systems that can be modularized in 2 or 3 months.
Large scale projects
Only used when the design problem for the model is available and besides, the budget must be large to be able to build many teams to develop in parallel
2.1.3 Testing within a life cycle model
Whichever life cycle model is being used, there are several characteristics 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
2.1.1 V-model
4 test levels
system testing
acceptance testing
integration testing
component testing
2.4 MAINTENANCE TESTING.
It can happen at any level of testing:
Component Test
Integration Test
System Test
Acceptance Test
Trigger
Modifications
Planned modifications
The following types of planned modification may be identified:
• perfective modifications (adapting software to the user's wishes, for instance
by supplying new functions or enhancing performance);
• adaptive modifications (adapting software to environmental changes such as
new hardware, new systems software or new legislation);
• corrective planned modifications (deferrable correction of defects).
-
Ad-hoc corrective modifications
Ad-hoc corrective modifications are concerned with defects requiring an immediate solution, e.g. a production run which dumps late at night...
Migration
Operational Testing of The
New Environment
Operational Testing of The
Changed Software
Retirement
The Testing of Data Migration
The Testing of Data Archiving
2.2 TEST LEVELS
Software testing can be performed at different levels of software development process
2.2.2 Integration testing
Integration testing is the testing of a group of related modules.
It aims at finding interfacing issues between the modules
This kind of testing is performed by testers
Integrating testing checks the data flow from one module to other modules
Tools/Technics:
Big Bang Approach :
Incremental Approach:
Bottom Up Approach
Top Down Approach
Sandwich Approach - Combination of Top Down and Bottom Up
2.2.3 System testing
Where the complete integrated application is tested as a whole
Determining if the application conforms to its business requirements
Involves the external workings of the software from the user's perspective
System test falls under the Black-box testing category of software testing
Testing each aspect of the application as seen from the outside without looking at the actual source code
Both the functional and non-functional requirements of the system are evaluated
It is carried out by the QA team
2.2.1 Component testing (Unit testing)
It checks that component are fulfilling functionalities or not
The Unit tests are always automated and more specifically use White-box testing technique as the knowledge of the piece of code and internal architecture is required to test the code
Usually performed by the developers
Tools: JUnit, TestNG, xUnit, NUnit...
A Unit is a smallest testable portion of system or application which can be compiled, liked, loaded, and executed
2.2.4 Acceptance Testing (UAT - User Acceptance Testing)
Where the system is tested for compliance to its business requirements
With the intent to see if the product is fit for delivery
is basically done by the user or customer and other stakeholders
UAT is required because
Developers have included features on their "own" understanding
Requirements changes "not communicated" effectively to the developers
Types of Acceptance Testing
Alpha Testing
Beta Testing