Software Testing- Principles of testing- Mazenet Solution

  • View
    118

  • Download
    0

Embed Size (px)

Text of Software Testing- Principles of testing- Mazenet Solution

  • Software Testing Presented by Baskaran E(Testing trainer)

  • Principles of Testing

    1 Principles2 Lifecycle4 Dynamic testtechniques3 Static testing 5 Management6 ToolsSoftware Testing Chapter 1

  • ContentsWhy testing is necessaryFundamental test processPsychology of testingRe-testing and regression testingExpected resultsPrioritisation of testsPrinciples123456

  • Testing terminologyNo generally accepted set of testing definitions used world wideNew standard BS 7925-1Glossary of testing terms (emphasis on component testing)most recentdeveloped by a working party of the BCS SIGISTadopted by the ISEB / ISTQB

  • What is a bug?Error: a human action that produces an incorrect result Fault: a manifestation of an error in softwarealso known as a defect or bug if executed, a fault may cause a failureFailure: deviation of the software from its expected delivery or service (found defect)

    Failure is an event; fault is a state ofthe software, caused by an error

  • Error - Fault - FailureA person makesan error ... that creates afault in thesoftware ... that can causea failurein operation

  • Reliability versus faultsReliability: the probability that software will not cause the failure of the system for a specified time under specified conditions

    Can a system be fault-free? (zero faults, right first time)

    Can a software system be reliable but still have faults?

    Is a fault-free software application always reliable?

  • Why do faults occur in software?software is written by human beingswho know something, but not everythingwho have skills, but arent perfectwho do make mistakes (errors)under increasing pressure to deliver to strict deadlinesno time to check but assumptions may be wrongsystems may be incompleteif you have ever written software ...

  • What do software faults cost?huge sumsAriane 5 ($7billion)Mariner space probe to Venus ($250m)American Airlines ($50m)very little or nothing at allminor inconvenienceno visible or physical detrimental impactsoftware is not linear: small input may have very large effect

  • Safety-critical systemssoftware faults can cause death or injuryradiation treatment kills patients (Therac-25)train driver killedaircraft crashes (Airbus & Korean Airlines)bank system overdraft letters cause suicide

  • So why is testing necessary?because software is likely to have faults

    to learn about the reliability of the software

    to fill the time between delivery of the software and the release date

    to prove that the software has no faultsbecause testing is included in the project plan

    because failures can be very expensiveto avoid being sued by customersto stay in business

  • Why not just "test everything"?Total for 'exhaustive' testing:20 x 4 x 3 x 10 x 2 x 100 = 480,000 testsIf 1 second per test, 8000 mins, 133 hrs, 17.7 days(not counting finger trouble, faults or retest)10 secs = 34 wks, 1 min = 4 yrs, 10 min = 40 yrs

  • Exhaustive testing?What is exhaustive testing?when all the testers are exhaustedwhen all the planned tests have been executedexercising all combinations of inputs and preconditions

    How much time will exhaustive testing take?infinite timenot much timeimpractical amount of time

  • How much testing is enough?its never enoughwhen you have done what you plannedwhen your customer/user is happywhen you have proved that the system works correctlywhen you are confident that the system works correctlyit depends on the risks for your system

  • How much testing?It depends on RISKrisk of missing important faultsrisk of incurring failure costsrisk of releasing untested or under-tested softwarerisk of losing credibility and market sharerisk of missing a market windowrisk of over-testing, ineffective testing

  • what not to test (this time)use RISK toallocate the time available for testing by prioritising testing ...

    So little time, so much to test ..test time will always be limiteduse RISK to determine:what to test firstwhat to test mosthow thoroughly to test each item

  • Most important principlePrioritise testsso that, whenever you stop testing,you have done the best testingin the time available.

  • Testing and qualitytesting measures software qualitytesting can find faults; when they are removed, software quality (and possibly reliability) is improvedwhat does testing test?system function, correctness of operationnon-functional qualities: reliability, usability, maintainability, reusability, testability, etc.

  • Other factors that influence testingcontractual requirementslegal requirementsindustry-specific requirementse.g. pharmaceutical industry (FDA), compiler standard tests, safety-critical or safety-related such as railroad switching, air traffic control

    It is difficult to determinehow much testing is enoughbut it is not impossible

  • ContentsWhy testing is necessaryFundamental test processPsychology of testingRe-testing and regression testingExpected resultsPrioritisation of testsPrinciples123456

  • Test Planning - different levels

  • The test processspecificationexecutionrecordingcheckcompletion

  • Test planninghow the test strategy and project test plan apply to the software under testdocument any exceptions to the test strategye.g. only one test case design technique needed for this functional area because it is less criticalother software needed for the tests, such as stubs and drivers, and environment detailsset test completion criteria

  • Test specificationspecificationexecutionrecordingcheckcompletionIdentify conditionsDesign test casesBuild tests

  • A good test caseeffective

    exemplary

    evolvable

    economic

    Finds faultsRepresents othersEasy to maintainCheap to use

  • Test specificationtest specification can be broken down into three distinct tasks:

    1. identify:determine what is to be tested (identifytest conditions) and prioritise2. design:determine how the what is to be tested(i.e. design test cases)3. build:implement the tests (data, scripts, etc.)

  • Task 1: identify conditionslist the conditions that we would like to test:use the test design techniques specified in the test planthere may be many conditions for each system function or attributee.g.life assurance for a winter sportsmannumber items ordered > 99date = 29-Feb-2004prioritise the test conditionsmust ensure most important conditions are covered

    (determine what is to be tested and prioritise)

  • Selecting test conditions

    48

  • Task 2: design test casesdesign test input and test dataeach test exercises one or more test conditionsdetermine expected resultspredict the outcome of each test case, what is output, what is changed and what is not changeddesign sets of testsdifferent test sets for different objectives such as regression, building confidence, and finding faults

    (determine how the what is to be tested)

  • Designing test cases

  • Task 3: build test casesprepare test scriptsless system knowledge tester has the more detailed the scripts will have to bescripts for tools have to specify every detailprepare test datadata that must exist in files and databases at the start of the testsprepare expected resultsshould be defined before the test is executed

    (implement the test cases)

  • Test execution

    specificationexecutionrecordingcheckcompletion

  • ExecutionExecute prescribed test casesmost important ones firstwould not execute all test cases iftesting only fault fixestoo many faults found by early test casestime pressure can be performed manually or automated

  • Test recording

    specificationexecutionrecordingcheckcompletion

  • Test recording 1The test record contains:identities and versions (unambiguously) ofsoftware under testtest specificationsFollow the planmark off progress on test scriptdocument actual outcomes from the testcapture any other ideas you have for new test casesnote that these records are used to establish that all test activities have been carried out as specified

  • Test recording 2Compare actual outcome with expected outcome. Log discrepancies accordingly:software faulttest fault (e.g. expected results wrong)environment or version faulttest run incorrectlyLog coverage levels achieved (for measures specified as test completion criteria)After the fault has been fixed, repeat the required test activities (execute, design, plan)

  • Check test completion

    specificationexecutionrecordingcheckcompletion

  • Check test completionTest completion criteria were specified in the test planIf not met, need to repeat test activities, e.g. test specification to design more tests

    specificationexecutionrecordingcheckcompletion

    Coverage too low

    CoverageOK

  • Test completion criteriaCompletion or exit criteria apply to all levels of testing - to determine when to stopcoverage, using a measurement technique, e.g.branch coverage for unit testinguser requirementsmost frequently used transactionsfaults found (e.g. versus expected)cost or time

  • Comparison of tasksone-offactivityactivityrepeatedmany timesGoverns thequality of testsGood toautomate

  • ContentsWhy testing is necessaryFundamental test processPsychology of testingRe-testing and regression testingExpected resultsPrioritisation of testsPrinciples123456

  • Why test?build confidenceprove that the software is correctdemonstrate conformance to requirementsfind faultsreduce costsshow system meets user needsassess the software quality

  • ConfidenceNo faults found = confidence?

  • Assessing soft