SoftwareTestingLifecyclePractice

1、Software Testing Lifecycle PracticeYujuan dou（窦玉娟）MSN:douyujuahole Course Plan10 hours in total:3 classes, 2 LabsTest planning (2 hours, one time, class)Test Case Design(2 hours ,one time, class)Test Execution and Defect Tracking(4hours,2 times, in the lab)Test Reporting(2hours , one ti

2、me, Class)Home WorkDraft a test plan for testing the Work log System （Group List)Delivery the test cases for Work Log Summarize the test results and deliver a test reportHome work delivery: or xzhu The First Class PlanIntroduction of Whole Class PlanTest PlanningWork log System introductionBenefits

3、of Test PlanForms a contract between testers and project teamAvoids random testing and missed featuresOptimizes resourcesKey Points in Test PlanningTest objectiveTest ScopeTest StrategyEstablish a team and defining rolesEstimate a test timelineKey Points-con.Risk Analysis Assumptions & ConstraintsDe

4、veloping test plan detailTest cyclesTest scenariosTest CasesThe forenamed information should be covered in all test plans. If for any reason a heading is not applicable, it should still be included in the plan, with a notation that it is not applicable. Statement of Objective To describe why the tes

5、ting is being performed and what will be accomplished as a result by this testing effort. for example “to ensure that the application will be able to recognize all financial periods that will be produced by the new functionality, and that all other processing is unaffected”Tips and TechniquesItemize

6、 the objective Write the objectives in a measurable statementPrioritizeDefine the completion criteria for each objectiveTest ScopeWhat is to be included in the testing effort and what is to be excludedFeatures includedFeatures not includedSoftware DecompositionClient-Specific RequirementSoftware Dec

7、ompositionIdentify what will be covered in the test plan including:FunctionsTransactionsReportsInterfacesError handlingDownstream impactsFor exampleThe next transaction/process in sequence should be part of the scope of the test effort. For example: if changes are made to the buy transaction, the se

8、ttlement transaction and the buy cancel transaction should be tested, too. Documentation (on-line help)Test StrategyDocuments how the test will be executed.Include:Test ApproachTest Environment and Test RequirementsTest TechniquesTest TeamTeam Preparation: knowledge transfer/trainingSimulation of Mi

9、ssing UnitsTest Approachthe overall method to conducting the test. Includes：Types of TestingSpecify the types of testing: integration or system testing. and non-functional quality attributes such as performance, reliability, usability etc. Test Approach-con.Testing MethodsSpecify the various testing

10、 methods (black box testing, GUI testing, system flow, database etc,) and the strategy of testing. The method of analyzing the test results are also to be documented. Indicate the test coverage if any. Identify the tools for defect tracking.Automated and Manual TestsSpecify the tests which are autom

11、ated and the tests that will be carried out manually.Test Environment Where and under what conditions will testing take place. Is it in pilot of production, batch or on-line, mainframe or PC based, etc Establish a Team and Defining RolesSpecifies resources for each taskAssigns tasks based on unique

12、skill setCommunicates objectives of testing effortParticipantsProject ManagersSQA managersTeam LeadersSQA SpecialistsIT RepresentativesClientsVendorsUsersBusiness analystsEstimate a Test TimelineDevelopment effort (software size)Percentage of new designSoftware complexityTechnology platformDocumenta

13、tion qualityRequirements stabilityAvailable resourcesRisk AnalysisBusiness RiskExternal DependencyOrganizationalPlanningTechnologicalAssumptions & ConstraintsAssumptions are suppositions about things that may or may not happen in the future.Constraints are limitations that must be worked around to m

14、anage the test effortOrganizational resourcesBusiness/LegalCost ,technical, schedule/timing/dependencyDeveloping test plan detailTest cyclesTest scenariosTest CasesSample Test PlanA typical Test Plan may have the following sections:Test Plan identifier: A unique name or number, useful if you store a

15、ll documents in a database.Introduction: Include references to all relevant policy and standards documents, and high-level product plans.Test items: A test item is a software item (function, module, feature, etc) that is to be tested. List them all, or refer to a document that lists them all. Includ

16、e references to specifications (e.g. requirements and design) and manuals.Features to be tested: Cross-reference them to test design specifications.Features not to be tested: Which ones and why not.Sample Test Plan-con.Approach: Describe the overall approach to testing: who does it, main activities,

17、 techniques, and tools used for each major group of features. How will you decide that a group of features is adequately tested? Item pass/fail criteria: How does a tester decide whether the program passed or failed a given test?Suspension criteria and resumption criteria: List anything that would c

18、ause you to stop testing until its fixed. What would have to be done to get you to restart testing? What tests should be redone at this point?Sample Test Plan-con.Test deliverables: List of all the testing documents that will be written for this product.Testing tasks: List all tasks necessary to pre

19、pare for and do testing. Show dependencies between tasks, special skills (or people) needed to do them, who do each, how much effort is involved, and when each will be done.Environmental needs: Describe the necessary hardware, software, testing tools, lab facilities, etc.Responsibilities: Name the groups (or people) responsible for managing, designing, prepari