1. Rekayasa Perangkat Lunak
Software Testing

2. Outline of this presentation
What Testing is
Testing In Development Process
Types Of Testing and Definitions
Verification & Validation
Purpose and Goal of Testing
Who Tests Software
Testing Technique
Testing Step
Testing Strategy

3. What’s Wrong? T F
A=2 ?
A=A + 0.1
A=0
Print A

4. What testing is

5. Mau Tau ya.... ?

6. Mau Tau aja atau mau tau banget ???

7. Testing is to execute a program with the purpose of finding defects
What testing is
1) Common definition
Testing is to execute a program with the purpose of finding defects
testing
2) Wider definition
”Testing is a technical investigation of a product, done to expose quality-related information.”

8. Testing in Development Process
Testing activities take place in all parts of software development
From requirement eliciting to final shipment
Testing is part of the development process
Testing is part of the company business process

9. Testing in Development Process
Testing During implementation: test to verify that software behaves as intended by the designer.
Testing After implementation: test for conformance with requirements and reliability, and other non functional requirement

10. Types of testing and definitions
Validation and Verification
Validate
correctness or suitability
vertical experts to confirm master results
Verification
confirm software operates as it is required
double check to ensure results match those previously validated and if not then re-validate them

11. Testing can take place as part of each phase of development .
Rational Unified
Process (RUP)
Transition
Construction
Inception
Elaboration
Core Workflow
Maintenance
Testing
Development
Design
Analysis
Requirements
Testing can take place as part
of each phase of development .

12. Phase
Rational Unified
Process (RUP)
Transition
Construction
Inception
Elaboration
Core Workflow
Maintenance
Testing
Development
Design
Analysis
Requirements
Testing can take place as part of each core workflow involved in development organization.

13. Verification & Validation
Software V & V defined as a systems engineering methodology to ensure that quality is built into the software during development.
Software V & V is complementary to and supportive of quality assurance, project management, systems engineering, and development.

14. Verification & Validation versus Debugging
a process that establish the existence of defects in a system
Debugging
a process that locates and corrects these defects

15. Verification versus Validation
Software Verification Process
is a process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities.
Software Validation Process
is a process for determining whether the requirements and the final, as-built system or software product fulfills its specific intended use.
Is a whole life-cycle process - V & V must be applied during each phase of the software development process.
Verification and validation should establish confidence that the software is fit for purpose
This does NOT mean completely free of defects
Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed

16. Verification versus Validation
“Are we building the system in the right way?”
The system should conform to the specification
It does what you specified it should do
Validation:
“Are we building the right system? ”
The system should do what the users really requires

17. The V & V Objectives There are two principal objectives:
To discover and rectify defects in a system
To assess whether or not the system is usable in an operational situation.
Is a whole life-cycle process - V & V must be applied during each phase of the software development process.
Verification and validation should establish confidence that the software is fit for purpose
This does NOT mean completely free of defects
Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed

18. The V & V Objectives
Software V & V determines that the software performs its intended functions correctly.
Ensure that the software performs no unintended functions
Measure and assess the quality and reliability of software.

19. The V & V Objectives
As a software engineering discipline, software V & V also assesses, analyzes, and tests the software on
how it interfaces with systems elements
Influences the performance, or reacts to stimuli from system elements

20. The V & V process V & V Is a whole life-cycle process
V & V should be applied at each stage in the software process.

21. Execution base testing
Static and Dynamic V&V
Are we building
the system
In the right way?
Check correspondence between a program and its specification
Static
Verification F or
mal
specifica
tion
High-le v el
design R
equir
ements
Detailed
Code/
Program Pr
ototype
Dynamic
Validation
Are we building
the right system?
Execution base testing

22. Static and Dynamic V&V Static Verification
Concerned with analysis of the static system representation to discover problems
Analysis of all documents produced that represent the system
Can be applied during all stages of the software process

23. (static verification) observing product behaviour
V & V
Inspect artifacts
Dynamic = “testing”
Execute systems
Static
Statisk kontra dynamisk testning Dynamisk test = mjukvara exekveras i syfte att hitta defekter
Statisk test = artefakter granskas i syfte att hitta defekter
Statisk och dynamisk testning är komplementära verifieringstekniker.
Den ena kan inte ersätta den andra, bägge bör användas för att verifiera överensstämmelse med krav.
to discover problems
(static verification)
observing product behaviour
(dynamic validation)

24. Complements each other
V & V
Inspect artifacts
Dynamic = “testing”
Execute systems
Static
Statisk kontra dynamisk testning Dynamisk test = mjukvara exekveras i syfte att hitta defekter
Statisk test = artefakter granskas i syfte att hitta defekter
Statisk och dynamisk testning är komplementära verifieringstekniker.
Den ena kan inte ersätta den andra, bägge bör användas för att verifiera överensstämmelse med krav.
Complements each other

25. V & V Static Dynamic = ”Testing” Review Inspection Walkthrough
Unit test
Integration test
Acceptance
test
System test

26. Purpose and goal of testing are situation dependent
Find defects
Maximize bug count
Block premature product releases
Help managers make ship/no-ship decisions
Assess quality
Minimize technical support costs
Utvärdering av kvaliteten på en produkt - Buggrapporten behöver ej vara lättförståelig, det är inte buggfixning vi är ute efter… [Kaner 2004]
Utvärdera att
Minimera teknisk supportkostnad – Det är viktigt att fånga de fel som skulle rendera i många supportsamtal oavsett hur allvarliga de är i övrigt [Kaner 2004]
Minimera risken för personskador – allt annat är ”out of scope” med denna målsättningen
Hitta scenarier som funkar (trots buggar) – typ: ”Vi ska dema systemet i morgon, vad kan vi göra”

27. Purpose and goal of testing are situation dependent
Conform to regulations
Minimize safety-related lawsuit risk
Assess conformance to specification
Find safe scenarios for use of the product (find ways to get it to work, in spite of the bugs)
Verify correctness of the product
Assure quality
Utvärdering av kvaliteten på en produkt - Buggrapporten behöver ej vara lättförståelig, det är inte buggfixning vi är ute efter… [Kaner 2004]
Utvärdera att
Minimera teknisk supportkostnad – Det är viktigt att fånga de fel som skulle rendera i många supportsamtal oavsett hur allvarliga de är i övrigt [Kaner 2004]
Minimera risken för personskador – allt annat är ”out of scope” med denna målsättningen
Hitta scenarier som funkar (trots buggar) – typ: ”Vi ska dema systemet i morgon, vad kan vi göra”

28. Purpose and goal of testing are situation dependent
Testing cannot show the absence of errors, only their presence
We test a program to find the existence of an error
If we find no errors then we have been unsuccessful
If an error is found debugging should occur

29. Unsuitable objectives with testing
Show that a system does what it is supposed to do
Showing that a system is without errors

30. Who Tests Software?
independent tester
developer
user

31. Who Tests Software? Software Developer Independent Tester
Understand system
Test gently
Driven by delivery
Independent Tester
Doesn’t understand system
Will try to break it
Quality driven

32. Who Tests Software? User Test while using it Indirect test
It’s not in purpose to do so
Indirect test

33. Static verification Review (desk checking)
Code reading done by a single person,
informal.
Uneffective compared to walkthrough or inspection
Walkthrough
The programmer(s) ”walks through”/”executes” his code while invited participants ask questions and makes comments.
Relatively informal
Inspection
Usually a checklist of common errors is used to compare the code against.

34. Testing Technique Two views on Software testing: White Box Testing
Black box
Black Box Testing

35. Testing Technique White box testing - tests what the program does.
Test sets are developed by using knowledge of the algorithms, data structures, and control statements.

36. Testing Technique
Black box
Black box testing - tests what the program is supposed to do.
Test sets are developed and evaluated solely on the specification. There is no knowledge of the algorithms, data structures, or control statements.

37. White-box testing Also known as: Structure based (Structural) testing
Code based testing
Glass box testing
Clear box testing
Logic driven testing

38. White-box testing White-box (or Structural) testing:
Use knowledge of the program to derive test cases to provide more complete coverage
Problem: What criteria to use?
Two basic strategies for figuring out a test plan: black-box or white-box. (There are also points inbetween.) One is not better than the other. Black-box testing uses boundary analysis, input equivalence partitioning, etc.
We’ll be focusing on white-box. We’ll go through a quick example on the board about the differences.

39. White-box testing ... our goal is to ensure that all
Statements, decisions, conditions, and paths have
been executed at least once ...

40. White-box testing The system is looked upon as an open box.
The test cases is based on the internal structure of the system (code)
Theoretically desirable but impossible and insufficient goal: all paths of the code exercise

41. Black-box testing Also known as: Functional Testing Behavioral Testing
because it test all the functions
Behavioral Testing
because the program is tested against the expected behavior (described by requirements and/or design)

42. Black-box testing
requirements
input
events
output
The software is viewed as a black box which transforms input to output based on the specifications of what the software is supposed to do.

43. Black-box testing
Check The Conformity of the tested S/W against established behaviour, and
Detect errors generated by fault
Software fault is a software part which is not according to its definition provided in the development document

44. Black-box testing
Functional tests examine the observable behavior of software as evidenced by its outputs without reference to internal functions.
If the program consistently provides the desired features with acceptable performance, then specific source code features are irrelevant.

45. Black-box testing Should consider only from the standpoint of its:
Input data
Output data
Knowledge of its internal structured should not be
It is very often impossible to test all the input data
It is hence necessary to select a subset of possible input

46. Testing Steps Unit Unit code test . SYSTEM IN USE! Integration
Function
Performance
Acceptance
Installation
Unit code .
Integrated
modules
Functioning
system
Verified,
validated
software
Accepted
SYSTEM
IN USE!
Design
specifications
System
functional
requirements
Other
Customer
specification
User
environment

47. Testing Steps Acceptance Test
software
tests
customer
developer site
type of acceptance testing performed by customer at the developer’s site is usually called alpha testing

48. Testing Steps Acceptance Test
software
customer site
customer
tests
beta testing is a type of acceptance testing involving a software product to be marketed for use by many users
selected users receive the system first and report problems back to the developer
users enjoy it - usually receive large discounts and feel important
developers like it - exposes their product to real use and often reveals unanticipated errors

49. Testing Strategy Big Bang! Top-down Sandwich Bottom-up incremental
non-incremental
incremental
Sandwich
Compromise

50. Testing Strategy Big bang integration (all components together)
Bottom up integration
(from lower levels No test stubs necessary)
Top down integration
(from higher levels  no test drivers are needed)
Sandwich testing
(combination of bottom-up and top-down  no
test stubs and drivers needed)

51. Kesawah Naik Bis....

52. Wahhhh ... materi kuliahnya sudah habis....

54. Terimakasih….. Untuk mahasiswa/i yang tidak ngantuk dan tetap konsentrasi Mengikuti Perkuliahan.