1 / 39

Chapter 1 : Introduction to Software Testing 322235 Software Testing

Chapter 1 : Introduction to Software Testing 322235 Software Testing. By Dr. Wararat Songpan ( Rungworawut ) Faculty of Computer Science, Department of Science, Khon Kaen University, Thailand. Software tester job??. Software tester job??. Software tester job??.

kato-colon
Download Presentation

Chapter 1 : Introduction to Software Testing 322235 Software Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 1: Introduction to Software Testing322235Software Testing By Dr. WararatSongpan (Rungworawut) Faculty of Computer Science, Department of Science, KhonKaen University, Thailand

  2. Software tester job??

  3. Software tester job??

  4. Software tester job??

  5. Where is software tester in software development team?

  6. Career path

  7. Why is Software testing important to a business? • Loss of money • Loss of time • Damage to business reputation • Injury or death

  8. Why is Software Testing Important to a business? Independent tester Developer 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”

  9. “Testing”

  10. Don’t care testing

  11. The cost of software development phases

  12. 7 Principles of testing 1) Testing shows presence of defects/Bugs 2) Exhaustive testing is impossible 3) Early testing 4) Defect clustering 5) Pesticide paradox 6) Testing is context depending 7) Absence – of – errors fallacy Source: http://istqbexamcertification.com/what-are-the-principles-of-testing/

  13. Principle 1: Testing shows presence of defects/Bugs • Testing can show the defects/Bugs are present, but cannot prove that there are no defects. • After testing the application or product thoroughly we cannot say that the product is 100% defect free. • Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.

  14. Principle 2: Exhaustive testing is impossible • Testing everything including all combinations of inputs and preconditions is not possible. • For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30  517  578  125  (515) tests. • This is very unlikely that the project timescales would allow for this number of tests.

  15. What is your test case?

  16. Principle 3: Early testing • In the software development life cycle (SDLC) testing activities should start as early as possible and should be focused on defined objectives.

  17. Principle 4: Accumulation of errors • There is no equal distribution of errors within one test object. The place where one error occurs, it’s likely to find some more. The testing process must be flexible and respond to this behavior.

  18. Principle 5: Fading effectiveness • The effectiveness of tests fades over time. If test-cases are only repeated, they do not expose new errors. Errors, remaining within untested functions may not be discovered. In order to prevent this effect, test-cases must be altered and reworked time by time.

  19. Principle 6: Testing is context depending • Testing is basically context dependent. Different kinds of sites are tested differently. For example, safety – critical software is tested differently from an e-commerce site.

  20. Principle 7: False conclusion: no errors equals usable system • Error detection and error fixing does not guarantee a usable system matching the users expectations. Early integration of users and rapid prototyping prevents unhappy clients and discussions.

  21. Software testing concepts • Software Testing is the process of evaluating a system or its component(s) with the intent to find that whether it satisfies the specified requirements or not. This activity results in the actual, expected and difference between their results. • Software Testing is executing a system in order to identify any gaps, errors or missing requirements in contrary to the actual desire or requirements.

  22. Keywords of testing • Error is an fault in the program. There are different types of error are • Syntax errors • Logical errors • Runtime errors • Etc.

  23. Keywords of testing • Fault is the result of an error that is representation of error such as narrative text, dataflow diagrams, hierarchy charts, source code. • Failure occurs when fault executes. • Incident – when a failure occurs, it may or may not be readily apparent to the user(cutormer/tester). An incident is the symptom associated with a failure that alerts the user to the occurrence of a failure.

  24. Keywords of testing • Bug is found in the development environment before the product is shipped to the respective customer. • Defect is found in the product itself after it is shipped to the respective customer. Bug(Programmer) = Defect(Tester)

  25. Keywords of testing • ** Test Case - test case has an identity and is associated with a program behavior. A test case also has a set of input and a list of expected outputs. Expected output System Input Actual output

  26. Keywords of testing • For example: A Test Case 5,000 Withdraw 5,000 Baht Expected output = Actual output 5,000

  27. Keywords of testing • Verification: Are we building the system right? The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. • Validation: Are we building the rightsystem? The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements from users.

  28. Structural and Functional View S - Specified Behaviors P - Programmed Behaviors P Fault of commission S P S S Fault of omission Specification (expected) Program (observed) P

  29. Structure and Functional View (Cont.) • 2,5 Spec. but do not be tested • 1,4 Spec. and Test • 3,7 Test does not meetSpec. • 2,6Program is not tested • 1,3 Program is undertest • 4,7Test case do not have program. Specification (expected) Program (observed) S P 2 6 5 1 4 3 7 8 T Test cases (verified)

  30. Software testing methods Black Box Testing (Functional Testing) • The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. • The tester is oblivious to the system architecture and does not have access to the source code. • Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.

  31. Comparing Functional Test Case Identification Methods S P S P Test cases (Method A) Test cases (Method B) Black box Black box

  32. Software testing methods White box testing (Structural Testing) • White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code. • The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately.

  33. Comparing Structural Test Case Identification Methods S P S P Test cases (Method A) Test cases (Method B) White box White box

  34. Level of Testing(Waterfall model) User Acceptance Testing Software Development Life Cycle Requirements & Specification Design test scripts/test cases System Testing Execute Preliminary Design Integration Testing Design Execute Design Detailed Coding Unit Testing Execute test scripts/test cases Coding

  35. Requirements Phase Testing Activities • A preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations. • Defines project goals into defined functions and operation of the intended application. • Analyzes end-user information needs. We can design overall System testing wait for actual system.

  36. Design Phase Testing Activities • Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo-code and other documentation. • Plan to test in Unit testing and Integration testing

  37. Coding Phase Testing Activities • The real code is written here then checks for error or bugs for each functions which are called Unit testing.

  38. Maintenance Phase Testing • The final stage of software development, where the software is put into production and runs actual business. • Brings all the pieces together into a actual environment and user, verify and validation for errors, bugs and interoperability. This testing phase is called UserAcceptance Testing (UAT).

  39. What the customer really needed: Must be tested 322 235 การทดสอบซอฟต์แวร์

More Related