Integration and Software Testing Strategies

1. Integration and Software Testing Strategies Rifki Indra P

2. Integration Concept • Penyatuansatuataulebih module dalamsubsistemmejadisatukesatuan enterprise sistem yang mempunyaikemampuan reporting, answering, and decision making yang akurat, cepatdantepat. Software Testing

3. Why Integration? • Islands of information • Effectivitas • Effisien • Increasing of services • Won the competition Software Testing

4. Case study • Human resources • Payroll • Finance • Executive • Administration academic • Assets • Development and Research • Student info • etc Software Testing

5. Purpose Of Integration • Reduce Redundancy reporting data • Reduce cost of maintenance • Minimalize resources • Minimalize bad information Software Testing

6. Software Testing

7. Software Testing

8. Software Testing

9. Software Testing Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. Software Testing

10. What Testing Shows errors requirements conformance performance an indication of quality Software Testing

11. Who Tests the Software? developer independent tester VS Understands the system Must learn about the system, but, will test "gently" but, will attempt to break it and, is driven by quality and, is driven by "delivery" Software Testing

12. Testing Strategy unit test integration test system test validation test Software Testing

13. Testing Strategy • We begin by ‘testing-in-the-small’ and move toward ‘testing-in-the-large’ • For OO software • our focus when “testing in the small” changes from an individual module (the conventional view) to an OO class that encompasses attributes and operations and implies communication and collaboration Software Testing

14. Unit Testing module to be tested results software engineer test cases Software Testing

15. Unit Testing module to be tested interface local data structures boundary conditions independent paths error handling paths test cases Software Testing

16. Unit Test Environment driver interface local data structures boundary conditions Module independent paths error handling paths stub stub test cases RESULTS Software Testing

17. Top Down Integration A top module is tested with stubs B F G stubs are replaced one at a time, "depth first" C as new modules are integrated, some subset of tests is re-run D E Software Testing

18. Bottom-Up Integration A B F G drivers are replaced one at a time, "depth first" C worker modules are grouped into builds and integrated D E cluster Software Testing

19. High Order Testing • Validation testing • Focus is on software requirements • System testing • Focus is on system integration • Alpha/Beta testing • Focus is on customer usage • Recovery testing • forces the software to fail in a variety of ways and verifies that recovery is properly performed • Security testing • verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration • Performance Testing • test the run-time performance of software within the context of an integrated system Software Testing

20. Debugging: A Diagnostic Process Software Testing

21. Debugging • Debugging is a consequence of testing! • Why it is difficult? • Software part: lack of documentation, bad software architecture, … • Human part: intuitive activities, psychological burden, … • Methods • Brute force: memory dumps, run time traces, … • Backtracking: starts from the symptom location, trace back manually until the site of error is found • Cause elimination: develop a “cause hypothesis”, then prove/disprove the hypothesis using data related to error occurrences Software Testing

22. The Debugging Process test cases results new test cases regression tests suspected causes Debugging corrections identified causes Software Testing

23. What is a “Good” Test? • A good test has a high probability of finding an error • A good test is not redundant. • A good test should be “best of breed” • A good test should be neither too simple nor too complex Software Testing

24. Software Testing black-box methods white-box methods Methods Strategies Software Testing

25. White-Box Testing (structural testing/transparent/glass) ... our goal is to ensure that all statements and conditions have been executed at least once ... Software Testing

26. Why need to be tested? Probability, logic errors and incorrect assumptions are inversely proportional to a path's execution that a path is not we often believe likely to be executed; in fact, reality is often intuitive Software Testing

27. Contoh White Box · menjaminseluruh independent path di dalammodul yang dikerjakansekurang-kurangnyasekali· mengerjakanseluruhkeputusanlogikal· mengerjakanseluruh loop yang sesuaidenganbatasannya· mengerjakanseluruhstruktur data internal yang menjaminvaliditas Software Testing

28. Black-Box Testing requirements output input events Software Testing

29. Black-Box Testing • Focuses on functional requirements • Disregards control structures • Attention on information domain • Handles the following classes of errors • Incorrect or missing functions • Interface errors • External database access • Performance errors • Initialization and termination errors Software Testing

30. Contoh Black Box Software Testing