Presentation on theme: "By Rick Clements email@example.com Software Testing 101 By Rick Clements firstname.lastname@example.org."— Presentation transcript:
1By Rick Clements email@example.com Software Testing 101By Rick Clements
2Overview Terminology Requirements Configuration control Test plan Test casesTest proceduresBug tracking & ship decisionAfter the testing
3TerminologyQA 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.
4TerminologyTest 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.
5TerminologyTypes 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.
6TerminologyLevels 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.
7Software Development Process Software Implementation & DebugSoftware DesignDefine RequirementsSoftware TestTest Implementation & DebugTest DesignSoftware Release
8Requirements Why are they important? How are they documented? What’s important?What if you don’t have any requirements?
9Why 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?
10Documenting Requirements Data sheetRequirements specificationFunctional specificationData baseTraceability matrix
11What’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
12No 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
13Configuration Control Why is it a testing issue?What to trackBuild & Version Number
14Why 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
15What To Track Requirements Software Hardware Tests Configuration ControlWhat To TrackRequirementsSoftwareHardwareTests
16Version & Build Number Simple to generate Configuration ControlVersion & Build NumberSimple to generateUnique for each build or changeReadily visible and validated for correctness
17Test Plan What will be tested and not tested? What approach will be taken?What resources are needed?Which people are needed?Schedule
18Test 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?
19Boundary 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
20Where 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?
21Usability 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
22Interfaces User interface Interfaces between software modules Test CasesInterfacesUser interfaceInterfaces between software modulesInterfaces to other programsHardware / software interfaces
23What 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
24What Failures Are Most Serious? Test CasesWhat Failures Are Most Serious?Areas data could be lostErrors with a large financial impactErrors that could injure someone
25Unique to Web Applications Test CasesUnique to Web ApplicationsVersions of browsersDifferent operating systemsServer capacityMultiple servers - one fails?
26Unique to GUI Based Application Test CasesUnique to GUI Based ApplicationSystem configuration changesSize of the screenNumber of colors availableDefault font type and size
27Unique to Database Applications Test CasesUnique to Database ApplicationsCompatible with existing dataTesting on a copy of real dataServer capacity
28Unique 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?
33After 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