Software Engineering 2 Software Testing Claire Lohr pp 413DefinitionAttributesTypes of TestingEquivalence class partitioningSteps for ECPBoundary valueDecision tableExploratory testingOperational profileTesting LevelsTesting Levels (cont.)Testing strategiesTesting strategies (cont.)Testing strategies (cont.2)Test DesignTest Coverage of codeTom McCabe’s basis technique.Test ExecutionTesting documentationIEEE Testing documentationTest managementSlide 23Software Engineering 2Software TestingClaire Lohrpp 413Presented By:Feras BatarsehDefinitionIEEE 610.12An activity in which a system or componentunder specified conditions, the results areobserved or recorded, and an evaluation ismade of some aspect of the system orcomponent.AttributesSoftware engineer intuition and experience.Specification.Code.Dataflow.Fault.Usage.Nature of the application.Types of TestingEquivalence class partitioning.Boundary value.Decision table.Exploratory.Operational profile.Equivalence class partitioningAccording to two attributes:Valid.Invalid.Example: age 0-120 (valid) age <0 and >120 (Invalid)Steps for ECPDefine valid and invalid values.Test as many valid classes together.Do one test for each invalid class.Boundary valueMust test the following:Legally defined minimum.Legally defined maximum.The first possible value below the legally min.The first possible value above the legally max.Age ex: 0, 120, -1, 121Decision tableLists all conditions and all resultant outputs.Y :yesN: no1:yes and no.Exploratory testingEmphasizing planning the focus of the testingprocess.Doesn’t require pre-planning.When test begins, modifications are stillallowed.Test results modify the plan accordingly.Operational profileNumber of tests to be done follows the model ofhow much it is used during operation.Test more for features that are used more.Testing LevelsLevels vary from organization to organization,and from project to project.Some parameters:Size.Complexity.Safety criticality.Experience of staff.Desire for certification(ISO, CMMI)Testing Levels (cont.)Operational testing:Software units, DB, integrated components,requirements and integration.Maintenance process:modified and un-modified parts, migrationverification, parallel testing, all developmentlevels for improvements.Supporting process:Verification and validation.Testing strategiesTesting all combinations is impossible!Macro:Time to marketAmount of functionality to be deliveredQuality of productMicro:More automation to speed processBetter selection of test casesLess turnovers in testing staff.Testing strategies (cont.)For functionality changes:Tracing requirements to see cases affected bychanges.Modular testing.For quality of product:More variety in types.Better tools.Better unit test tools for developersTesting strategies (cont.2)To control test effort cost:PM tool for estimations.Add root cause analysis.Test DesignArt and science.Structured:Boundary value Decision tableEquivalence class partitioningUn structured:RandomAd hocExploratoryTest Coverage of codeImpossible to cover all the code.Depends on the definition of ”covering”!Does it mean executing, reading, testing?Use Tom McCabe’s basis technique.Tom McCabe’s basis technique.1-Draw a flow graph.(nodes and edges)2-Compute the metric cyclomatic complexity (nodes). No.edges-no.Nodes+2=cc3-Choose paths. (cover all nodes and edges)Test ExecutionDefined in a test plan (Pseudo code andflow graph)Cover all specifications is important.(categorizeaccording to testable or not)Define components: hardware, software,personnel, data, automated tools.Testing documentationMedia vary depending on level of detail:Word doc.Spread sheets.Databases.Within automated test tools.IEEE Testing documentationTest planTest designTest casesTest proceduresTest logosIncident reportsTest summary reportTest item transmittal reportTest managementEstimating schedules.Planning for staffing and training.Identifying and planning tasks.Monitoring the execution of the plans andre-planning based on results.Any questions?Thank You for your