7 Why is Software testing important to a business? Loss of moneyLoss of timeDamage to business reputationInjury or death
8 Why is Software Testing Important to a business? DeveloperIndependent testerUnderstands the systembut, will test "gently"and, is driven by “delivery”Must learn about the system,but, will attempt to break itand, is driven by “quality”
11 The cost of software development phases Cost SpentRequirements Analysis3%SpecificationDesign5%Coding7%Testing15% (should be > 50%)Operational and Maintenance67%**
12 7 Principles of testing 1) Testing shows presence of defects/Bugs 2) Exhaustive testing is impossible3) Early testing4) Defect clustering5) Pesticide paradox6) Testing is context depending7) Absence – of – errors fallacySource:
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.
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 testingError is an fault in the program. There are different types of error areSyntax errorsLogical errorsRuntime errorsEtc.
23 Keywords of testingFault 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 Bug(Programmer) = Defect(Tester) Keywords of testingBug 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 outputSystemInputActual output
26 Expected output = Actual output Keywords of testingFor example: A Test Case5,000Withdraw 5,000 BahtExpected output = Actual output5,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 right system?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 BehaviorsP - Programmed BehaviorsPFault of commissionSPSSFault of omissionSpecification(expected)Program(observed)P
29 Structure and Functional View (Cont.) 2,5 Spec. but do not be tested1,4 Spec. and Test3,7 Test does not meet Spec.2,6 Program is not tested1,3 Program is under test4,7 Test case do not have program.Specification(expected)Program(observed)SP26514378TTest 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 Test cases(Method A)Test cases(Method B)Black boxBlack 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 Test cases(Method A)Test cases(Method B)White boxWhite box
34 Level of Testing (Waterfall model) User Acceptance TestingSoftware Development Life CycleRequirements & SpecificationDesign test scripts/test casesSystemTestingExecutePreliminaryDesignDesignIntegrationTestingExecuteDetailedCodingDesignUnit TestingExecute test scripts/test casesCoding
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 User Acceptance Testing (UAT).
39 What the customer really needed: Must be tested การทดสอบซอฟต์แวร์