Strategisk testplanlegging av Hans Schaefer hans.schaefer@ieee.org Hvordan planlegge testingen for et helt prosjekt Mal for dokumentasjonen Sjekklister 2000-2011 Hans Schaefer Slide no. 1
Hva skal vi lære Hvordan lage en overordnet plan for å bekjempe feil i et softwareprosjekt Risikobasert test Estimering av test Generell planlegging Referanser til detaljer Mal for dokumentasjon 2000-2011 Hans Schaefer Slide no. 2
Mål med testingen Med de resurser og den tiden vi får, skal vi ved ethvert punkt ha gjort den best mulige testen. Dvs: Funnet flest mulig alvorligst mulige feil Målt kvaliteten så nøyaktig som nødvendig 2000-2011 Hans Schaefer Slide no. 3
Mål med strategisk planlegging Identifisere hva som testes Planlegge prioriteter Ansvarsfordeling Grov tidsplan Ressursplan Beslutningskriterier Alt som senere krever beslutninger 2000-2011 Hans Schaefer Slide no. 4
Hvor er vi? 2000-2011 Hans Schaefer Slide no. 5
Hva må vi vite Rammebetingelser! Hvor kritisk er produktets kvalitet? Tidsbegrensninger Ressursbegrensninger Nytt produkt eller vedlikehold Prosjektmodell 2000-2011 Hans Schaefer Slide no. 6
Hva skal vi gjøre? 2000-2011 Hans Schaefer Slide no. 7
Mal for dokumentasjonen IEEE Standard 829-1998 for testdokumentasjon: Testplan Egentlig en testplan for ett testnivå, men her bruker vi den som overordnet plan for all testing. Alternativ IEEE 1012, IEEE 829-2008. 2000-2011 Hans Schaefer Slide no. 8
1. - 3. Innledende kapitler 1. Identifikasjon Hva heter testplanen? Dato og versjon, 2. Introduksjon 2.1. Mål 2.2. Bakgrunn 2.3. Omfang 2.4. Referanser 3. Produkter som skal testes (overblikk, konfigurasjon) 3.1. Programmoduler, subsystemer, system, flere systemer... 3.2. Kommandojobber etc. 3.3. Datagrunnlag, parametere 3.4. Brukernes prosedyrer, Driftsprosedyrer, Dokumentasjon, 2000-2011 Hans Schaefer Slide no. 9
4 og 5. Hva skal testes og hva ikke List alle dokumenter som skal utvikles. De finnes i prosjektplanen. Inkluder prosjektplan og kontrakt, evtl. også standarder og retningslinjer. Planlegg granskning og granskningsmetode for alle. Planlegg automatisk analyse v.hj.a. verktøy Planlegg testnivåene (vanligvis tre). Lag en liste over produktets funksjoner og viktige egenskaper Planlegg for hver av dem hvor og hvor nøye de skal sjekkes eller testes. Viktig er også en vektlegging hvor mye en skal bruke for å sjekke og teste funksjonene versus egenskapene og egenskapene imellom. Hvis spesifikasjonen er dårlig, kan listen over funksjoner og egenskaper som skal testes være levende og øke etter hvert som testeren lærer produktet. 2000-2011 Hans Schaefer Slide no. 10
Hvor mye skal vi gjøre Avhenger av risiko og feilkostnad (se også under estimering) Sortering etter risiko (Risk based testing) Risiko = Kostnad ved feil * Sannsynlighet for feil Analyse: Først utenfra (black box), senere oppdatering også ut ifra produktkunnskap (glass box). 2000-2011 Hans Schaefer Slide no. 11
Generell risiko Konsekvenser av feil Størrelse og kompleksitet Brukerne (offerne for problemer) og deres omgivelse Brukshistorie Trusler (situasjoner som kan føre til problemer) Dårlige produktområder: Modenhet av utviklingsmetoder, verktøy og modeller Spesielle krav fra standarder for safety critical software 2000-2011 Hans Schaefer Slide no. 12
Grafisk fremstilling av risiko Sett et kryss for hver funksjon og hvert egenskap! Test det som er i første kvadrant! 2000-2011 Hans Schaefer Slide no. 13
Kostnad og sannsynlighet faktorer Kostnad Sannsynlighet Bruksfrekvens Kompleksitet, tidligere feil, endringer Ustabile krav (funksjoner, grensesnitt, datadefinisjoner) Flere kokker Strid blant oppdragsgiverne Mulighet for workaround Tidligere feil Følger i praksis Mindre kvalifiserte personer Utskifting av personale Lokale faktorer Gi hver faktor en vekt, finn for hver testkandidat og hver faktor et nivå (lav, middels,høy), regn ut et vektet produkt! 2000-2011 Hans Schaefer Slide no. 14
5. Hva skal ikke testes Alt som utelukkes skal ha en begrunnelse! Oppfør her også hva som utsettes! Du kan slå sammen punktene 4 og 5 i testplanen. Kan hende må dette punktet oppdateres flere ganger! 2000-2011 Hans Schaefer Slide no. 15
6. Hvordan testen skal designes og utføres Avtal programfasiliteter som skal lette testingen. Inngangsporter i programmene som gir testerne adgang til interne datastrukturer o.l. Bruk av standarder på de eksterne grensesnitt som gjør bruk av automatiske testverktøy lettere. Tidlig implementering av funksjonalitet som er viktig for testerne. Lag regler og standarder for test og granskingsarbeide. Velg testmetoder. Velg graden av automatisering. Velg om ekstern hjelp, standardtestsuiter etc. skal brukes. 2000-2011 Hans Schaefer Slide no. 16
Måledata en trenger underveis Framdrift (se også Kap 12): Prosent testeksempler planlagt - forberedt - prøvd utført, utført med suksess Testtid: Prosent brukt Testbudsjett: prosent brukt Hva slags testaktiviteter er tiden brukt til? Hvor mange feil oppdages pr. tidsenhet? Testdekning: Prosent kodelinjer / forgreninger etc. utført Prosent funksjoner / skjermbilder etc. utført Feil: Hvor mange funnet Hvor mange rettet Type feil (Kode, design, spes.) Hvor alvorlig er feilene Følgefeil eller ny feil Kostnader med feilretting Analyse: årsaker, dårlige systemdeler, mulig forebygging eller bedre review og test. 2000-2011 Hans Schaefer Slide no. 17
7. Start- og sluttkriterier Hva skal til for å starte testarbeidet? Godkjenning eller ikke? Nødutganger Lag akseptansekriterier (for hver granskning, analyse og test). Testkvalitet OG programvarekvalitet må være under kontroll 2000-2011 Hans Schaefer Slide no. 18
8. Kriterier for avbrudd og gjenopptakelse Avbrudd av test i håpløse situasjoner testmiljøproblemer alvorlige blokkerende feil ressursmangel Gjenopptakelse etter at vesentlige hindringer er rettet regresjonstestkrav m.m. Testmiljøproblemer er en vesentlig faktor! 2000-2011 Hans Schaefer Slide no. 19
9. Testprodukter og dokumentasjon Krav til eksistens, omfang og format av Testplaner Testspesifikasjoner Testdesign Spesifikasjon av testomgivelser Testdata og resultatdata Testlogger Avviks- og feilrapporter Test- sluttrapporter Testprogrammer, scripts, instruksjoner og prosedyrer Alt annet som skal arkiveres og vises utenfor testingen Beskriv testarkitekturen! 2000-2011 Hans Schaefer Slide no. 20
10. Arbeidsoppgaver for testen Følg den vanlige testprosessen ISTQB-modell IEEE 1008 ISO / IEC 14598-3, -4, -5 ISO 12207 British Standard 7925-2 Sett sammen med resten av prosjektet. V-modell. 2000-2011 Hans Schaefer Slide no. 21
11. Krav til testomgivelser 11.1. Hardware 11.2. Software 11.3. Databaser 11.4. Nettverk 11.5. Sikkerhet 11.6. Verktøy 11.7. Publikasjoner, Literatur, bakgrunnsmateriale 11.8. Prosedyrer for oppsett, initialisering, postprosessering, backup, bruk, forvaltning 2000-2011 Hans Schaefer Slide no. 22
Testomgivelse for ulike tester Laboratory environment for Unit and Integration test Typically development environment Standards for file names Standards for configuration and change management High level integration and System test environment Controllable environment Tests of subsystems isolated from each other and with each other Change control Reset facilities Tools Acceptance test environment As much as possible simulation of production Controlled environment 2000-2011 Hans Schaefer Slide no. 23
11. Oppsett av testdatabaser Use of regular system functions Problem: Maybe problems because these functions don t work reliably Advantage: Implicit test of data entry functions Use of separate load software Problem: All kinds of impossible situations may become possible. Technical support needed during set-up. Loader must be available. Advantage: Quick set-up. Converting production data Problem: Large amount of data. Data cover same system area, Unknown coverage. Security and privacy restrictions. Advantage: Quick to prepare and set up. 2000-2011 Hans Schaefer Slide no. 24
11. Bruk av testdatabaser Accumulative development Databases grow with the test. Advantage: Flexibility Problem: Change control, space requirements growing, pollution. Periodic reset of data All tests based on fixed data content. Reset daily or weekly. Changed data a personal responsibility of the testers. Advantage: No pollution of database Problems: Dependence on moment of reset. Extra work to enter needed extra data. Parallel use of several isolated data areas Each tester has his own data area or database. Advantage: Parallel tests possible. Problem: Integration between functions not well tested. 2000-2011 Hans Schaefer Slide no. 25
12. Ansvar og myndighet For alle vesentlige oppgaver beskriv ansvar og myndighet. Testplan for hvert testnivå Test spesifikasjon Test design og implementering Testutførelse og logging Verifikasjon (av testdokumenter og testresultater) Godkjenning Test og godkjenning av oppdateringer / rettede feil Vedlikehold av Regressionstest Testomgivelse 2000-2011 Hans Schaefer Slide no. 26
Testpersoner De viktigste tre: 2000-2011 Hans Schaefer Slide no. 27
12. Ansvar og uavhengighet Testing krever et uavhengig synspunkt Nivåer av uavhengighet: Tre dimensjoner: Teknisk (fresh view) Management Finansiell Utvikler selv Kollega av utvikler (buddy system) Tester(s) i utviklingsteam Dedikerte tester(e) (ikke utviklere) Interne testkonsulenter (råd, support, review) Organisasjon utenfor leverandør (Tredjeparts test service) It is very difficult to get people to understand facts, if their salary is dependent on their misunderstanding the facts. Al Gore i filmen, En ubehagelig sannhet 2000-2011 Hans Schaefer Slide no. 28
Krav til soft skills Soft Skills that Make a Tester By Anuj Magazine http://www.stickyminds.com/r.asp?f=dart_6752 Discipline and Perseverance Reading Skills Negative Thinking Communication and Interpersonal Skills Time Management and Effort Prioritization Attitude 2000-2011 Hans Schaefer Slide no. 29
12. Uavhengig forberedelse er viktigst! 2000-2011 Hans Schaefer Slide no. 30
Typisk ansvarsfordeling (1) Reviews / Granskinger: Noen trente review-ledere forvalter sjekklister og leder reviews. Lavnivå reviews holdes av forfatter Høyere nivå reviews holdes av trente review-ledere Kvalitetssikring sjekker at reviews finner sted 2000-2011 Hans Schaefer Slide no. 31
Typisk ansvarsfordeling (2) Modultest: Programmerer utfører. En arbeidskollega eller programmerer selv forbereder testdata eller ser gjennom konseptet. Kvalitetssikring sjekker testdekning. 2000-2011 Hans Schaefer Slide no. 32
Typisk ansvarsfordeling (3) Integrasjonstest, systemtest: Egen testgruppe Eventuelt bruker / kunde med Formell gjennomgang av testkonsepter Kvalitetssikring sjekker testlogg og review Feilretting: Utviklernes ansvar Omkjøring av modultest utviklernes ansvar Høyere nivå test og godkjenning ved testgruppe 2000-2011 Hans Schaefer Slide no. 33
13. Personer og opplæring 13.1. Personer. Testleder Testutvikler / test designer Testautomatiserings-utvikler Testomgivelses-tilrettelegger / forvalter Testoperator Testverktøyansvarlig Testkoordinator ( application integrator (for inngangskontroll og utføring) Utviklere, Brukere etc. 2000-2011 Hans Schaefer Slide no. 34
13.2. Kvalifikasjoner som behøves Test design teknikker Test automatisering Database Design / utvikling / programmering Business / applikasjonsområde Test omgivelse Test ledelse Test eksekvering (manuell) Configuration management Software metrikker og statistikk Mellommenneskelig kommunikasjon Diplomatiske ferdigheter Møteledelse Prosjektledelse 2000-2011 Hans Schaefer Slide no. 35
14. Tidsplan og budsjettering Testingens omfang er avhengig av konsekvensene av driftsfeil og forventet antall feil. (Risikobasert testing) Optimale testbudsjetter finnes ikke. Erfaringstall er viktige! Testutførelsens kostnader er avhengige av programvarekvaliteten. Testutførelse blir alltid forsinket og gjerne avbrutt for tidlig. Sørg for at testen, når den stoppes, har funnet flest mulig og tyngst mulige feil! Viktigste tester først! 2000-2011 Hans Schaefer Slide no. 36
Observasjoner mht. kostnader Skal du finne mer enn 80% av feilene, blir en test eller granskning ekstremt dyr. Test og granskinger finner forskjellige typer feil. Hvert testnivå finner forskjellige feil. De siste testnivåene finner også følgefeil av feilrettingen. Uten granskinger koster testfasen 50% av et prosjekt. 2000-2011 Hans Schaefer Slide no. 37
Optimal estimering Økonomi mht feil: Minimer følgende likning Kostnad = Testkostnad pr. dag * testdager + Rettekostnad pr. feil * feil funnet i test + Rettekostnad i drift pr. feil * antall feil funnet i drift + Trøbbel -kostnad pr. driftsfeil * antall feil funnet i drift + kostnad for senere levering - gevinst for tidligere levering. Problem: Vi har ikke data 2000-2011 Hans Schaefer Slide no. 38
Cost and benefit curves 2000-2011 Hans Schaefer Slide no. 39
Data vi bør samle under prosjektet, for å hjelpe estimering neste gang Gjennomgangs kostnader Test kostnader Rette kostnader Trøbbel kostnader Typiske feiltall og feiltyper Feilfinningskurver / trender Feilfinningsgrad Arbeidskostnader mht. test og feil Se et annet kapittel Freeware Tool: www.testimation.com, Better Software Magazine, Sept. 2006 Referanse: Software Estimation: Demystifying the Black Art by Steve McConnell, Microsoft Press, 2006, ISBN 0-7356-0535-1, 308 pp., US$39.99. 2000-2011 Hans Schaefer Slide no. 40
14. Estimering av testomfang Basert på analogi Basert på tommelfingerregler Basert på kodelinjer Basert på funksjonspunkter 2000-2011 Hans Schaefer Slide no. 41
14. Estimering fra tommelfinger regler Test og gjennomganger = 30% (Microsoft >50%) Gjennomganger = 10-20% ekstra i tillegg til utarbeidelse av et dokument Test = 5 dager per transaksjon Eller 5% av budsjett for modultest 5 % for integrasjon 10% for systemtest 2000-2011 Hans Schaefer Slide no. 42
14. Estimering fra kodelinjer COCOMO model, based on estimate of delivered code lines and several quality, project and personnel factors. Cost per phase (in %), dependent on project size and reliability requirements Phase Test Planning Defect removal Plans & requirements 2-6 6-10 Design 4-8 6-10 Coding 4-8 6-12 Integration & Later Test 2-5 34-20 Overall 4-7 10-14 Maintenance 3-6 10-14 (Left number of two = small and "easy" projects, right number = large projects) (Test planning means analysis of phase products and preparation of tests against these phase products. Defect removal means reviews and inspections, and test execution. Debugging and defect repair is an additional cost not covered here). Barry Boehm, Software Cost Estimation with COCOMO II, Prentice Hall 2000 2000-2011 Hans Schaefer Slide no. 43
14. Funksjonspunktmetode, tall Antall funksjonspunkter som kan løses pr. månedsverk. Activity Information systems Productivity ranges System software Minimum Median Maximum Critical projects 1. Requirements x x x 50 175 350 2. Prototyping x x 75 200 500 3. Architecture x x 50 150 300 4. Formal Project Plans x x 200 500 1200 5. Initial analysis and design x x x 50 175 400 6. Detailed design x x x 25 150 300 7. Formal design reviews x x 75 225 400 8. Coding x x x 3 15 50 9. Acquiring reusable code x x 300 400 600 10. Acquire purchased code x x 350 750 1500 11. Formal code inspection x x 75 100 200 12. IV&V x 75 100 200 13. Formal conf. management x 1000 2000 3000 14. Formal integration x x 100 250 500 15. User documentation x x x 15 30 50 16. Unit testing x x x 100 200 400 17. Function testing x x x 25 150 300 18. Integration testing x x 75 175 400 19. System testing x x x 100 175 400 20. Field testing x x 75 225 500 21. Acceptance testing x x 100 350 600 22. Independent testing x 100 200 300 23. Formal quality assurance x x 30 125 300 24. Installation and training x x x 150 250 400 25. Project management x x x 20 75 150 Som utgangspunkt må en vite antall funksjonspunkter for prosjektet. Resultatet blir korrigert med faktorer bl.a. for kritikalitet, verktøybruk, systematisk arbeidsmåte etc. 2000-2011 Hans Schaefer Slide no. 44
Tidsplan, hovedprinsipp Testforberedelse gjøres parallelt med utviklingsarbeidet. Spesielt testspesifikasjon, testomgivelse 2000-2011 Hans Schaefer Slide no. 45
15. Risikohåndtering Definer mulige prosjekt-risikofaktorer og hva du vil gjøre mot de Tekniske, prosjektmessige, politiske, organisatoriske Oppfølging (Hvor ofte?) Mulige reaksjoner Ignorering Ansvar!!! 2000-2011 Hans Schaefer Slide no. 46
Sjekk prosjektplanen med jevne mellomrom Fornuftig? Aktuell? Dårlige trender? 2000-2011 Hans Schaefer Slide no. 47
Feilbekjempelse i små prosjekter Små prosjekt: < 5 mennesker, < 6 måneder. Hvert dokument: I hvert fall en annen person bør sjekke dem. Testeksempler for system- og akseptansetest: Forbered dem før koden blir skrevet. Prosjektplan: Sjekk og oppdater ofte. Feildata: Finn alarmerende trender. 2000-2011 Hans Schaefer Slide no. 48
Hva må vi ellers gjøre, utenom planen? Få konsensus om feilbekjempelsen i prosjektet. Sjekke ambisjonsnivå. Få aksept i ledelsen. Organiser rapportering og behandling av feil. 2000-2011 Hans Schaefer Slide no. 49
Kontrakter og testing Require from subcontractors what your customer requires from you! Require what you require internally! Static analysis of code Review reports Test coverage measurement (at least 100% statement coverage in unit test) Defect logs Access to test data, tools and test programs Updating of test material with the software (configuration management) Delivery of all this to you You may also require a certain mean time between failures (MTBF) at entry to your acceptance test! 2000-2011 Hans Schaefer Slide no. 50
Referanser IEEE Standard 1012-1997: Standard for Software Verification and Validation Plans. IEEE Standard 829-1998: Standard for Software Test Documentation IEEE Standard 829-2008: Standard for Software and System Test Documentation Bill Hetzel, The Complete Guide to Software Testing, QED Information Sciences, Wellesley, Ma., 1988. Poul Staal Vinje, Test af Software, teknisk forlag, København, 1993. Barry W. Boehm, Software Risk Management, IEEE Computer Society Press, 1990 Ståle Amland, "Risk Based Testing of a Large Financial Application" Stale Amland, Proceedings of the 14th International Conference and Exposition on TESTING Computer Software, June 16-19, 1997, Washington, D.C., USA. James Bach, «A framework for good enough testing», IEEE Computer Magazine, October 1998 Hans Schaefer: Strategies for prioritizing test, STAR West 98 conference proceedings, San Diego, 1998. www.sqe.com Cem Kaner, Bad Software: What to Do When Software Fails, John Wiley, 1998 James Bach, "Risk Based Testing", STQE Magazine, 6/1999, www.stqemagazine.com Rex Black, Critical Testing Processes, Addison-Wesley, 2003 2000-2011 Hans Schaefer Slide no. 51