Part 1: Unit Test
Part 2: Integration Test
Part 3: System Test
Part 4: User Acceptance Test
Levels of testing
Unit test (Component test)
Integration test (Combination test)
System test
User Acceptance test
Example
The order system include basic functions for:
Front end with login accounts:
- Customer
- Manager
Back end with functions:
Customer:
1. Create new order: create order buying goods.
2. Cancel order: cancel their own orders
3. Inquiry order: inquiry their own orders
Manager:
1. Inquiry order: inquiry all orders in system.
2. Update order: update status of order.
Part 1: Unit test – What?
Validate that individual UNITs of software program are working properly
A UNIT(component) is the smallest testable part of an application, it can be:
Program statements
Function, procedure
Module
Individual program
Unit test – why?
Ensure code follow detailed design
Ensure quality of software unit
Detect defects and issues early
Reduce the Quality Effort & Correction Cost
Unit Test – When ?
After Coding
Before Integration Test
Unit test – Techniques
Statement coverage: execute all statements at least once
Decision coverage: execute each decision direction at least once
Branch coverage: branch coverage measures the coverage of both conditional and unconditional
branches
Path coverage
Example
Statement Coverage
1 READ A
2 READ B
3 C = A + 2 * B
4 IF C> 50 THEN
5 PRINT large C
6 ENDIF
=> 100% statement coverage: A = 20, B = 25
1 READ A
2 READ B
3 C = A - 2 * B
4 IF C< 0 THEN
5 PRINT “C negative”
6 ENDIF
100% decision coverage:
Test 1: A = 20, B = 15
Test 2: A = 10, B = 2
Branch Coverage
1 READ A
2 READ B
3 C = A - 2 * B
4 IF C< 0 THEN
5 PRINT “C Negative”
6 ENDIF
100% branch coverage:
Test 1: A = 20, B = 15
Test 2: A = 10, B = 2
Exercise
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF
How many cases to coverage 100% branchs? 100%
statements?
Stubs and drivers
Stubs and drivers are usually used in UT to replace missing components, software
Stub: called by software component
Driver: call software component
Part 2: Integration Test
Test the interface between components.
Do not concentrate on functionalities of each function itself.
Bug of IT is the bug when 2 components communicate to each other incorrectly.
Ex:
After login to an order system, the homepage will be displayed but it directs to another page.
Integration Test –Why, When
Why:
Ensure integrate functions/modules follow HLD
Ensure communication between functions/modules work properly
When:
Should begin once unit testing for the components to be integrated is complete
Level of Integration
Components integration: integrate between components.
Ex: integrate create new, cancel and inquiry order.
System integration: integrate between systems.
Ex: integrate front end and back end system.
Big-bang integration: integrate all components, systems at one time.
Incremental integration: integrate one by one component
Big Bang Integration
Advantages:
Everything is finished before integration testing starts.
Disadvantages:
Time consuming
Difficult to trace cause of failure
Only effectively when the software expected to have no defect.
Incremental Integration
Advantages:
Defects are found early at the beginning of integrate so it’s easy to detect the cause
Disadvantages:
Time consuming to create stubs and drivers.
Type of incremental integration
Top-down: from menu to function (use stub)
Bottom-up: from detail function to menu (use
driver)
Functional incremental: each function is
integrated, tested one by one.
Trend & Good Practices
Integration sequence and the number of
integration steps required depend on the location
in the architecture of the high-risk interfaces
The best choice is to start integration with those
interfaces that are expected to cause most
problems
Ideally testers should understand the architecture
and influence integration planning. If integration
tests are planned before components or systems
are built, they can be developed in the order
required for most efficient testing
Part 3: System test
Is concerned with the behavior of the whole
system/product as defined by the scope of a development
project or product
Is most often the final test on behalf of development to
verify that the system to be delivered meets the
specification and its purpose may be to find as many
defects as possible
System test base on:
Risk
Requirement specification
Business process
Use cases
Interaction with OS or system resources
System Test –Why, When
Why:
Ensure business of system work correctly,
Ensure requirement specification exist in the system
When:
Should begin as soon as a minimal set of components
has been integrated and successfully completed
integration testing
System Test - Environment
System test includes:
Functional testing: using black box test technique
Non-functional testing: performance and reliability.
Environment for system test should be the most likely
to the production environment to minimize
environment-specific failure.
Part 4: User Acceptance Test
Do by customer.
AT environment, for most aspect should represent for
the production environment.
AT concentrates on validation types of testing to
determine whether the system is fit for use.
AT may occurs at many levels due to the scope of project
(after UT, IT, ST).
Time scale of AT may overlap on ST.
UAT –Why, When
Why
Accept product based on acceptance criteria
Ensure function needed and expected by customers is
present in a software product
When:
After software product is released and system tested
User Acceptance Test Types
2 main test types in AT
Operational AT may include testing of
Backup/ restore
Disaster recovery
Maintenance tasks
Security weakness
Compliance AT is performed against the contract’s
acceptance criteria, such as government regulations.
Eg: does the accounting report adhere to the law?
Mass market AT contains 2 phase of AT:
Alpha test: do by users in development org.
Beta test: do by users in real world.
