Presentation on theme: "By Rick Clements email@example.com Software Testing 101 By Rick Clements firstname.lastname@example.org."— Presentation transcript:
1 By Rick Clements email@example.com Software Testing 101By Rick Clements
2 Overview Terminology Requirements Configuration control Test plan Test casesTest proceduresBug tracking & ship decisionAfter the testing
3 TerminologyQA vs. QCQuality assurance (QA) - The management of quality. The encouragement of best practices. QA is about preventing defects.Quality control (QC) - Validation and verification of the product. This includes reviews, inspections and testing.
4 TerminologyTest DocumentsTest plan (or validation plan) - The plan describing the general approach, the people required, equipment required and schedule for testing and other validation activitiesTest cases - Specific data used to test the product.Test procedures - The procedures to follow in testing the product. These may be manual or automated.
5 TerminologyTypes of TestsBlack box testing - Testing by looking at the requirements to develop test cases. System level testing is often black box testing.White box testing - Testing by looking at the structure of the program to develop test cases. White box testing often occurs in unit testing.
6 TerminologyLevels of TestingUnit testing - The process of running small parts of the software. The design teams often handle unit testing.Integration testing or Interface testing - The testing of pre-tested modules and hardware to determine that they work together.System testing - The testing of the entire product to see that it meets its requirements. This occurs after the product has been integrated.
7 Software Development Process Software Implementation & DebugSoftware DesignDefine RequirementsSoftware TestTest Implementation & DebugTest DesignSoftware Release
8 Requirements Why are they important? How are they documented? What’s important?What if you don’t have any requirements?
9 Why Are Requirements Important? How do the designers know what to build?How can you test that it was built correctly?When you disagree, who’s right?
10 Documenting Requirements Data sheetRequirements specificationFunctional specificationData baseTraceability matrix
11 What’s Important They exist They are unambiguous and testable RequirementsWhat’s ImportantThey existThey are unambiguous and testableCover all of the customers (not just final customer)They are under configuration control
12 No Documented Requirements Ask the project managerAsk the marketing representativeHas anything been sent to the customer?Ask a domain expertWhat are the designers building?Write them down
13 Configuration Control Why is it a testing issue?What to trackBuild & Version Number
14 Why Is It A Testing Issue? Configuration ControlWhy Is It A Testing Issue?Ship the version that was testedA single test system failingModules accidentally reverting to older versionRe-create software and tests
15 What To Track Requirements Software Hardware Tests Configuration ControlWhat To TrackRequirementsSoftwareHardwareTests
16 Version & Build Number Simple to generate Configuration ControlVersion & Build NumberSimple to generateUnique for each build or changeReadily visible and validated for correctness
17 Test Plan What will be tested and not tested? What approach will be taken?What resources are needed?Which people are needed?Schedule
18 Test Cases Test boundary conditions System interfaces Where have other errors been found?What will the users do most often?What is the most serious if it fails?UsabilityWhat is unique to your product's environment?
19 Boundary Conditions Values at and away from the boundaries Test CasesBoundary ConditionsValues at and away from the boundariesValid and invalid valuesBoth numeric values and stringsMinimum-1, minimum, maximum, maximum+1, a good middle value
20 Where Have Errors Been Found? Test CasesWhere Have Errors Been Found?Errors tend to clusterCan a common error be fixed?Would a code review be useful?
21 Usability Often over looked First to see software outside of design Test CasesUsabilityOften over lookedFirst to see software outside of designThe interface makes sense if you know the designNeed to know your users
22 Interfaces User interface Interfaces between software modules Test CasesInterfacesUser interfaceInterfaces between software modulesInterfaces to other programsHardware / software interfaces
23 What Will Users Do Most Often? Test CasesWhat Will Users Do Most Often?Frequently encountered errors impact the user moreTest heavily used areas more heavilyLess used areas can’t be ignored
24 What Failures Are Most Serious? Test CasesWhat Failures Are Most Serious?Areas data could be lostErrors with a large financial impactErrors that could injure someone
25 Unique to Web Applications Test CasesUnique to Web ApplicationsVersions of browsersDifferent operating systemsServer capacityMultiple servers - one fails?
26 Unique to GUI Based Application Test CasesUnique to GUI Based ApplicationSystem configuration changesSize of the screenNumber of colors availableDefault font type and size
27 Unique to Database Applications Test CasesUnique to Database ApplicationsCompatible with existing dataTesting on a copy of real dataServer capacity
28 Unique to Embedded Applications Test CasesUnique to Embedded ApplicationsCan multiple simultaneous stimulus be handled?Are hardware failures handled correctly?Running out of suppliesComponents breaking or degradingCommunications errors between componentsCan temperature changes cause the system to behave differently?
33 After the Testing Known problems and solutions Test report Defects not fixedShorten customer service leaning curveTest reportTuned to the audienceIntroduction & conclusionMajor defectsWhat was run on which versionsWhat tests couldn’t be run