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 2

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

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

5. Mau Tau ya.... 5

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

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

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 8

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 9

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 10

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

12. 12 Maintenance Testing Development Design Analysis Requirements TransitionConstructionInceptionElaboration Core Workflow Phase Rational Unified Process (RUP) 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. 13

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

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

16. Verification versus Validation 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 16  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. 17

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. 18

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 19

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. 20

21. 21 Formal specification High-level design Requirements specification Detailed design Code/ Program Prototype Static and Dynamic V&V Check correspondence between a program and its specification Are we building the system In the right way? Are we building the right system? Static Verification Dynamic Validation Execution base testing

22. 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 22 Static and Dynamic V&V

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

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

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

26. Purpose and goal of testing are situation dependent 1.Find defects 2.Maximize bug count 3.Block premature product releases 4.Help managers make ship/no-ship decisions 5.Assess quality 6.Minimize technical support costs 26

27. Purpose and goal of testing are situation dependent 7.Conform to regulations 8.Minimize safety-related lawsuit risk 9.Assess conformance to specification 10.Find safe scenarios for use of the product (find ways to get it to work, in spite of the bugs) 11.Verify correctness of the product 12.Assure quality 27

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

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

30. 30 Who Tests Software? user independent tester developer

31. 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. 32 Who Tests Software? User – Test while using it It’s not in purpose to do so – Indirect test

33. 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. 34 Testing Technique Two views on Software testing: White Box Testing Black box Black Box Testing

35. 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. 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. 37 White-box testing  Also known as:  Structure based (Structural) testing  Code based testing  Glass box testing  Clear box testing  Logic driven testing

38. 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. 39... our goal is to ensure that all Statements, decisions, conditions, and paths have been executed at least once... White-box testing

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

43. 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. 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. 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. 46 Testing Steps Unit test Unit test Unit test Integration test Function test Performance test Acceptance test Installation test Unit code...... Integrated modules Functioning system Verified, validated software Accepted system SYSTEM IN USE! Design specifications System functional requirements Other software requirements Customer requirements specification User environment

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

48. 48  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 software customer site customer tests Testing Steps Acceptance Test

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

50. 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. Semoga Sukses di UAS