3. Contain
CMM Standard
Different Types of Testing
1. Unit Testing
2. Integration Testing
3. Validation Testing
4. System Testing
5. Acceptance Testing
4. CMM Standard
CMM stands for Capability Maturity Model
To determine an organization’s current state of process
maturity, the SEI uses an assessment that results in a five
point grading scheme.
The grading scheme determines compliance with a
capability maturity model (CMM) that defines key
activities required at different levels of process maturity.
The SEI approach provides a measure of the global
effectiveness of a company's software engineering
practices and establishes five process maturity levels that
are defined in the following manner:
5. CMM Standard
Level 1: Initial
The software process is characterized as ad hoc and
occasionally
Few processes are defined, and success depends on
individual effort
Level 2: Repeatable
Basic project management processes are established to
track cost, schedule, and functionality.
The necessary process discipline is in place to repeat
earlier successes on Project
6. CMM Standard
Level 3: Defined
The software process for both management and engineering
activities is documented, standardized, and integrated
This level includes all characteristics defined for level 2
Level 4: Managed
Detailed measures of the software process and product quality
are collected
This level includes all characteristics defined for level 3
Level 5: Optimizing
Continuous process improvement is enabled by quantitative
feedback from the process and from testing innovative ideas
and technologies
This level includes all characteristics defined for level 4
7. Different Types of Testing
1. Unit Testing
2. Integration Testing
3. Validation Testing
4. System Testing
5. Acceptance Testing
8. Unit Testing
Unit is the smallest part of a software system which is testable
it may include code files, classes and methods which can be
tested individual for correctness.
Unit is a process of validating such small building block of a
complex system, much before testing an integrated large
module or the system as a whole.
Driver and/or stub software must be developed for each unit
test a driver is nothing more than a "main program" that
accepts test case data, passes such data to the component,
and prints relevant results.
Stubs serve to replace modules that are subordinate (called
by) the component to be tested.
A stub or "dummy subprogram" uses the subordinate
module's interface.
9. Integration Testing
Integration is defined as a set of integration among
component.
Testing the interactions between the module and interactions
with other system externally is called Integration Testing.
Testing of integrated modules to verify combined functionality
after integration.
Integration testing addresses the issues associated with the
dual problems of verification and program construction.
Modules are typically code modules, individual applications,
client and server applications on a network, etc. This type of
testing is especially relevant to client/server and distributed
systems.
11. Validation Testing
The process of evaluating software during the
development process or at the end of the development
process to determine whether it satisfies specified
business requirements.
Validation Testing ensures that the product actually meets
the client's needs. It can also be defined as to
demonstrate that the product fulfills its intended use
when deployed on appropriate environment.
Validation testing provides final assurance that software
meets all informational, functional, behavioral, and
performance requirements.
The alpha test is conducted at the developer’s site by a
representative group of end users.
12. Validation Testing
The software is used in a natural setting with the
developer “looking over the shoulder” of the users and
recording errors and usage problems.
Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more end-user sites.
Unlike alpha testing, the developer generally is not
present.
Therefore, the beta test is a “live” application of the
software in an environment that cannot be controlled by
the developer.
13. System Testing
In system testing the software and other system elements are
tested as a whole.
To test computer software, you spiral out in a clockwise
direction along streamlines that increase the scope of testing
with each turn.
System testing verifies that all elements mesh properly and
that overall system function/performance is achieved.
Types of System Testing:
1. Recovery Testing
2. Security Testing
3. Stress Testing
4. Performance Testing
5. Deployment Testing
14. Recovery Testing
Recovery testing is a system test that forces the software
to fail in a variety of ways and verifies that recovery is
properly performed.
If recovery is automatic (performed by the system itself),
re initialization, check pointing mechanisms, data
recovery, and restart are evaluated for correctness. If
recovery requires human intervention, the mean-time-to-
repair (MTTR) is evaluated to determine whether it is
within acceptable limits.
15. Security Testing
Security testing attempts to verify that protection
mechanisms built into a system will, in fact, protect it
from improper penetration.
During security testing, the tester plays the role(s) of the
individual who desires to penetrate the system.
16. Stress Testing
Stress testing executes a system in a manner that
demands resources in abnormal quantity, frequency, or
volume.
A variation of stress testing is a technique called
sensitivity testing.
17. Performance Testing
Performance testing is designed to test the run-time
performance of software within the context of an
integrated system.
Performance testing occurs throughout all steps in the
testing process.
Even at the unit level, the performance of an individual
module may be assessed as tests are conducted.
18. Deployment Testing
Deployment testing, sometimes called configuration
testing, exercises the software in each environment in
which it is to operate.
In addition, deployment testing examines all installation
procedures and specialized installation software that will
be used by customers, and all documentation that will be
used to introduce the software to end users.
19. Acceptance Testing
Acceptance Testing is a level of the software testing
where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s
compliance with the business requirements and assess
whether it is acceptable for delivery.
It is a formal testing with respect to user needs,
requirements, and business processes conducted to
determine whether or not a system satisfies the
acceptance criteria and to enable the user, customers or
other authorized entity to determine whether or not to
accept the system.
Acceptance Testing is performed after System Testing and
before making the system available for actual use.
20. References
Inspiration from Prof. Parul V Bakaraniya
Notes of SE
Textbook of SE
Images from Google Images
Some my own Knowledge