Strategi dan Teknik Testing

1. Testing Implementasi Sistem Pertemuan 2 Strategi dan Teknik Testing Oleh :Rifiana Arief, SKom, MMSI

2. Outline 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? A=0 A=A + 0.1 A=2 ? Print A Print A T F

4. 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.”

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

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

7. Most Common Software problems • Incorrect calculation • Incorrect data edits & ineffective data edits • Incorrect matching and merging of data • Data searches that yields incorrect results • Incorrect processing of data relationship • Incorrect coding / implementation of business rules • Inadequate software performance

8. Confusing or misleading data • Software usability by end users & Obsolete Software • Inconsistent processing • Unreliable results or performance • Inadequate support of business needs • Incorrect or inadequate interfaces with other systems • Inadequate performance and security controls • Incorrect file handling

9. 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 to double check to ensure results match those previously validated and if not then re-validate them

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

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 core workflow involved in development organization.

12. 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. Verification & Validation a process that establish the existenceof defects in a system Debugging a process that locates and corrects these defects Verification & Validation versus Debugging

14. 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. Verification versusValidation

15. 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 VerificationversusValidation • Validation: • “Are we building the right system?” • The system should do what the users really requires

16. Sometimes one of these word is used to mean both verification and validation: Verification in the meaning: verification and validation, or Validation in the meaning: verification and validation Verification versusValidation

17. 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. The V & V Objectives

18. 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. The V & V Objectives

19. 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 The V & V Objectives

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

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

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

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

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

28. 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 Purpose and goal of testing are situation dependent

29. 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 Purpose and goal of testing are situation dependent

30. Unsuitable objectiveswith testing Show that a system does what it is supposed to do Showing that a system is without errors

31. Testing Levels • Unit testing • Integration testing • System testing • Acceptance testing

32. Unit testing • The most ‘micro’ scale of testing. • Tests done on particular functions or code modules. • Requires knowledge of the internal program design and code. • Done by Programmers (not by testers).

33. Unit testing Srihari Techsoft

34. Srihari Techsoft

35. Incremental integration testing • Continuous testing of an application as and when a new functionality is added. • Application’s functionality aspects are required to be independent enough to work separately before completion of development. • Done by programmers or testers.

36. Integration Testing • Testing of combined parts of an application to determine their functional correctness. • ‘Parts’ can be • code modules • individual applications • client/server applications on a network. Srihari Techsoft

37. Types of Integration Testing • Big Bang testing • Top Down Integration testing • Bottom Up Integration testing

38. Integration testing Srihari Techsoft

39. Srihari Techsoft

40. System Testing

42. Systems Integration Testing

44. Acceptance Testing

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

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

48. Black box Testing Technique • 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.

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

50. 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?