Please enable JavaScript.
Coggle requires JavaScript to display documents.
testing throughout the sw development lifecycle - Coggle Diagram
testing throughout the sw development lifecycle
sw development lifecycle model
b.reason why sw development lifecycle models must be adapted to context of prj & product characteristic
difference in product risk of system (complex or simple prj)
many business units can be part of a prj or program (combination of sequential & agile development)
short time to deliver product to market (merge test level and/or integration of test type in test level)
definition:
describe type of activity at each stage in sw development prj
describe how activity relate another one
2 types of sw development lifecycle models
sequential development model
any phase should begin when the previous phase is complete
iterative & incremental development model
size of feature increases
occur when groups of feature are specified, designed, built & tested together in a series of cycles of a fixed duration
characteristic
for every development activity -> a corresponding test activity
each test level has test objective
test analysis & design for a test level begin during the corresponding development activity
tester participate in discussion to define & refine requirement & design & involve in reviewing work product as soon as drafts are available
test levels
definition
each test level is an instance of test process
group of test activity organized & managed together
include
component testing
objective
reduce risk
verify whether functional & non-functional behavior of component are designed & specified
build confidence in component's testing
prevent defect from escaping to higher test level
find defect
test basis
detailed desgin
code
data model
component specification
test object
component, unit or module
code & data structure
classes
database modules
typical defect & failure
incorrect functionality (not described in design specification
data flow problems
incorrect code & logic
approach & responsibility
developer wrote code + test + finding & fix defect
integration testing
objective
focus on interaction btw component & system
the same to component testing but with interface not component
2 types
component integration testing
focus on interaction & interface btw integrated component
is performed after component testing & is generally automated
system integration testing
focus on interaction & interface btw system, package, microservices
is performed after system testing or in parallel with ongoing system test activity
test basis
sw & system design
sequence diagram
interface & communication protocol specification
use cases
architecture at component or system test
workflow
external interface definitions
test objects
subsystem
database
infrastructure
interfaces
API
microservice
defect & failure
incorrect/missing data or incorrect data encoding
incorrect sequencing or timing of interface call in component integration testing
interface mismatch
failure in communication btw component/system
Unhandled or improperly handled communication failures between components/systems
Incorrect assumptions about the meaning, units, or boundaries of the data being passed between component/system
Inconsistent message structures between systems on system integration testing
approach & responsibility
approach
only focus on communication btw systems/components not individual functionality of them
increase integration with small number of additional component or system at a time
responsibility
component integration testing: developer
system integration test: tester
understand system architecture & influenced integration planning
system testing
objective
focus on behavior & capability of whole system or product
consider end-to-end task system can perform
consider non-functional behavior exhibits when performing tasks
the same to component testing but with system not component
verify data quality
provide info to stakeholder -> make decision on release
satisfy legal/regulatory requirement/standard
test basis
system & sw requirement specification (functional & non-functional)
risk analysis report
use cases
epic & user story
models of system behavior
state diagram
system & user manual
test object
application
hardware/sw system
operating system
system under test
system configuration & configuration data
defect & failure
incorrect calculation
incorrect or unexpected system functional/non-functional behavior
incorrect control/data flow
failure to properly & completely carry out end-to-end functional task
failure of system to work properly in system environment
failure of system to work as described in system & user manual
approach & responsibility
tester
acceptance testing
objective
like system testing
establish confidence in system quality
validate system is complete and work as expected
verify functional &non-functional behavior of system are specified
produce info to assess system's readiness for deployment & use by customer
satisfy legal/regulatory requirement/standard
common forms
user acceptance testing
focus on validating the fitness for use of system in real/simulate operational environment
build confidence that user can use system to meet their need
fulfill requirement
perform business processes with minimum difficulty, cost & risk
operational acceptance testing
testing of backup & restore
install, uninstall & upgrade
disaster recovery
user management
maintenance task
data load & migration task
check security vulnerability
performance testing
build confidence that operator/system administrator can keep system working properly for users in operational environment even under exceptional/difficult condition
contractual & regulatory acceptance testing
contractual acceptance testing
is performed by user/independent tester
regulatory acceptance testing
is performed by user/independent tester but result is witnessed or audited by regulatory agency
main objective
is build the confidence that contractual/regulatory compliance has be achieved
alpha & beta testing
used by developer -> get feedback from user, customer, operator before product release
alpha testing is performed by developing organization's site (customer, operator, independent test team), not development team
beta testing is performed by customer, operator at their own location. is come after alpha testing or not
build confidence that customer, operator can use system under normal, every condition, operational environment to achieve objective within difficulty, cost & risk
detect defect related to condition & environment which system will be used
test basis
business processes
user or business requirement
regulation, legal contracts & standard
use case/user story
system requirement
system/user documentation
installation procedure
risk analysis report
backup & restore procedure
disaster recovery procedure
non-functional requirement
operation documentation
deployment & installation instruction
performance target
database package
security standard/regulation
test object
system under test
system configuration & configuration data
business process for a fully integrated system
recovery system and hot site
operational & maintenance process
form
report
existing & converted production data
defect & failure
system workflow do not meet business/user requirement
business rules are not implemented correctly
system does not satisfy contractual/regulatory requirement
non-functional failure: security vulnerability, inadequate performance efficiency under high loads or improper operation on a supported platform
approach & responsibility
customer, business users, product owner, operator of a system, other stakeholder
is characterized by attributes
specific objectives
test basis, referenced to derive test case
test object (what is being tested)
typical defect & failure
specific approach & responsibility
for each test level -> suitable test environment
test type
a. functional testing
evaluate functions that the system perform
functional requirement: describe in work product like business requirement specification, epics, user story, use cases, functional specification
are 'what' the system do
is performed all test level
consider the behavior of sw -> use black-box technique to derive test condition & test case for functionality of component/system
be measured by functional coverage: the extent to which some functionality has been exercised by test & is expressed as a percentage of the type of element being covered.
functional test design & execution involve special skill/knowledge
change-related testing
confirmation testing
to confirm the original defect has ben fixed succesfully
is performed at all test level
fix defect or new/changing functionality
regression testing
change is made on 1 part of part -> affect to other parts
involve running test to detect unintended side-effects
is performed at all test level
is run many times and evolve slowly -> strong candidate for automation -> start early in the project
white-box testing
derive test based on system's internal structure/implementation (code, architecture, work flows, data flow)
is measured by structure coverage
in component testing level: code coverage is based on the percentage of component code that has be tested
be measured about different aspects of code (coverage items) like percentage of executable statements/decision outcomes tested
in component integration testing level: based on the architecture of system like interface btw component
be measured in terms of the percentage of interface executed by test
white-box test design & execution involve skill/knowledge: the way the code is built, how data is stored, how to use coverage tool, interpret result correctly
definition:
group of test activity aimed at testing characteristic of sw system or part of system based on test objective
objective
evaluate functional quality characteristic: completeness, correctness, appropriateness
evaluate non-functional quality characteristic: reliability, performance efficiency, security, compatibility, usability
evaluate structure/architecture of system/component is correct, complete, specified or not
evaluate the effect of changes
non-functional testing
evaluate characteristic of system & sw: usability, performance efficiency, security
is the testing of 'how well' the system behaves
is performed at all level & done as early as possible
the late discovery of non-functional defect can be extremely dangerous to the success of a project
use black-box technique
be measured by non-functional coverage
non-functional test design & execution involve special skill/knowledge
maintenance testing
when
change on delivered sw/system
fix defect in operational use
add/remove/alter functionality
scope depend on
the degree of risk of change
the size of existing system
the size of change
purpose
preserve (bao quan) / improve non-functional quality characteristic of component/system/performance efficiency/compatibility, reliability, security, portability
evaluate the success which the change
check the side-effects in other parts without changes against the change on other one (regression test)
involve planned/unplanned releases (hot fix)
trigger for maintenance
2 types
modification
planned enhancement
planned corrective & emergency change
Planned changes of operational environment (operating system/database upgrade)
upgrade of COTS sw
patch for defect & vulnerability (va su de bi ton thuong)
migration (movement)
one platform to another
test of data conversion when data from another application will be migrated into the system being maintained (chuyen doi)
Impact analysis for maintenance
evaluate the change
identify the intended consequence as expected and side effects
identify area in system will be affected by change
help to identify the impact of a change on existing test
is done before the change is made to help decide of that change should be made
is difficult if
specification are out of date or missing
test case are not documented/out of date
bi-directional traceability btw test & test basis has not been maintained
tool support is weak or non-existent
people involved do not have domain/system knowledge
insufficient attention has been paid to sw's maintainability during development