Rekayasa Perangkat Lunak

1. Rekayasa Perangkat Lunak Sesi 14 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. A=0 A=A + 0.1 A=2 ? Print A Print A T F What’s Wrong?

4. What testing is..................

5. Mau Tau ya....

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

7. 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. Phase Inception Elaboration Construction Transition Requirements Analysis Design Development Testing Maintenance Rational Unified Process (RUP) Core Workflow Testing can take place as part of each phase of development .

12. Phase Inception Elaboration Construction Transition Requirements Analysis Design Development Testing Maintenance Rational Unified Process (RUP) Core Workflow 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 • Verification & Validation • a process that establish the existenceof defects in a system • Debugging • a process that locates and corrects these defects

15. VerificationversusValidation • 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.

16. Verification versusValidation • Verification: • “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.

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. Static and Dynamic V&V Are we building the system In the right way? Check correspondence between a program and its specification Static Verification R equir ements High-le v el F or mal Detailed Code/ Program specifica tion design specifica tion design Dynamic Pr ototype 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 documentsproduced that represent the system • Can be applied during all stages of the software process

23. Dynamic = “testing” Inspect artifacts Execute systems V & V Static observing product behaviour (dynamic validation) to discover problems (static verification)

24. Dynamic = “testing” Inspect artifacts Execute systems Complements each other V & V Static

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

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

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

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. Show that a system does what it is supposed to do Showing that a system is without errors Unsuitable objectives with testing

30. Who Tests Software? user developer independent tester

31. Who Tests Software? Software Developer 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 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 (or Structural) testing: Use knowledge of the program to derive test cases to provide more complete coverage Problem: What criteria to use? White-box testing

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

42. 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. Black-box testing requirements output input events

43. 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 Black-box testing

44. 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. Black-box testing

45. 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 Black-box testing

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

47. Testing StepsAcceptance 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 StepsAcceptance Test software tests customer customer site • 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 Compromise Bottom-up incremental non-incremental

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)