Strategisk testplanlegging

Transkript

1 Strategisk testplanlegging av Hans Schaefer Hvordan planlegge testingen for et helt prosjekt Mal for dokumentasjonen Sjekklister Hans Schaefer Slide no. 1

2 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 Hans Schaefer Slide no. 2

3 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 Hans Schaefer Slide no. 3

4 Mål med strategisk planlegging Identifisere hva som testes Planlegge prioriteter Ansvarsfordeling Grov tidsplan Ressursplan Beslutningskriterier Alt som senere krever beslutninger Hans Schaefer Slide no. 4

5 Hvor er vi? Hans Schaefer Slide no. 5

6 Hva må vi vite Rammebetingelser! Hvor kritisk er produktets kvalitet? Tidsbegrensninger Ressursbegrensninger Nytt produkt eller vedlikehold Prosjektmodell Hans Schaefer Slide no. 6

7 Hva skal vi gjøre? Hans Schaefer Slide no. 7

8 Mal for dokumentasjonen IEEE Standard for testdokumentasjon: Testplan Egentlig en testplan for ett testnivå, men her bruker vi den som overordnet plan for all testing. Alternativ IEEE 1012, IEEE Hans Schaefer Slide no. 8

9 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 Kommandojobber etc Datagrunnlag, parametere 3.4. Brukernes prosedyrer, Driftsprosedyrer, Dokumentasjon, Hans Schaefer Slide no. 9

10 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 Hans Schaefer Slide no. 10

11 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) Hans Schaefer Slide no. 11

12 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 Hans Schaefer Slide no. 12

13 Grafisk fremstilling av risiko Sett et kryss for hver funksjon og hvert egenskap! Test det som er i første kvadrant! Hans Schaefer Slide no. 13

14 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! Hans Schaefer Slide no. 14

15 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! Hans Schaefer Slide no. 15

16 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 Hans Schaefer Slide no. 16

17 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 Hans Schaefer Slide no. 17

18 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 Hans Schaefer Slide no. 18

19 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! Hans Schaefer Slide no. 19

20 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! Hans Schaefer Slide no. 20

21 10. Arbeidsoppgaver for testen Følg den vanlige testprosessen ISTQB-modell IEEE 1008 ISO / IEC , -4, -5 ISO British Standard Sett sammen med resten av prosjektet. V-modell Hans Schaefer Slide no. 21

22 11. Krav til testomgivelser Hardware Software Databaser Nettverk Sikkerhet Verktøy Publikasjoner, Literatur, bakgrunnsmateriale Prosedyrer for oppsett, initialisering, postprosessering, backup, bruk, forvaltning Hans Schaefer Slide no. 22

23 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 Hans Schaefer Slide no. 23

24 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 Hans Schaefer Slide no. 24

25 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 Hans Schaefer Slide no. 25

26 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 Hans Schaefer Slide no. 26

27 Testpersoner De viktigste tre: Hans Schaefer Slide no. 27

28 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 Hans Schaefer Slide no. 28

29 Krav til soft skills Soft Skills that Make a Tester By Anuj Magazine Discipline and Perseverance Reading Skills Negative Thinking Communication and Interpersonal Skills Time Management and Effort Prioritization Attitude Hans Schaefer Slide no. 29

30 12. Uavhengig forberedelse er viktigst! Hans Schaefer Slide no. 30

31 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 Hans Schaefer Slide no. 31

32 Typisk ansvarsfordeling (2) Modultest: Programmerer utfører. En arbeidskollega eller programmerer selv forbereder testdata eller ser gjennom konseptet. Kvalitetssikring sjekker testdekning Hans Schaefer Slide no. 32

33 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 Hans Schaefer Slide no. 33

34 13. Personer og opplæring Personer. Testleder Testutvikler / test designer Testautomatiserings-utvikler Testomgivelses-tilrettelegger / forvalter Testoperator Testverktøyansvarlig Testkoordinator ( application integrator (for inngangskontroll og utføring) Utviklere, Brukere etc Hans Schaefer Slide no. 34

35 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 Hans Schaefer Slide no. 35

36 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! Hans Schaefer Slide no. 36

37 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 Hans Schaefer Slide no. 37

38 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 Hans Schaefer Slide no. 38

39 Cost and benefit curves Hans Schaefer Slide no. 39

40 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: Better Software Magazine, Sept Referanse: Software Estimation: Demystifying the Black Art by Steve McConnell, Microsoft Press, 2006, ISBN , 308 pp., US$ Hans Schaefer Slide no. 40

41 14. Estimering av testomfang Basert på analogi Basert på tommelfingerregler Basert på kodelinjer Basert på funksjonspunkter Hans Schaefer Slide no. 41

42 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 Hans Schaefer Slide no. 42

43 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 Design Coding Integration & Later Test Overall Maintenance (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 Hans Schaefer Slide no. 43

44 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 Prototyping x x Architecture x x Formal Project Plans x x Initial analysis and design x x x Detailed design x x x Formal design reviews x x Coding x x x Acquiring reusable code x x Acquire purchased code x x Formal code inspection x x IV&V x Formal conf. management x Formal integration x x User documentation x x x Unit testing x x x Function testing x x x Integration testing x x System testing x x x Field testing x x Acceptance testing x x Independent testing x Formal quality assurance x x Installation and training x x x Project management x x x Som utgangspunkt må en vite antall funksjonspunkter for prosjektet. Resultatet blir korrigert med faktorer bl.a. for kritikalitet, verktøybruk, systematisk arbeidsmåte etc Hans Schaefer Slide no. 44

45 Tidsplan, hovedprinsipp Testforberedelse gjøres parallelt med utviklingsarbeidet. Spesielt testspesifikasjon, testomgivelse Hans Schaefer Slide no. 45

46 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!!! Hans Schaefer Slide no. 46

47 Sjekk prosjektplanen med jevne mellomrom Fornuftig? Aktuell? Dårlige trender? Hans Schaefer Slide no. 47

48 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 Hans Schaefer Slide no. 48

49 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 Hans Schaefer Slide no. 49

50 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! Hans Schaefer Slide no. 50

51 Referanser IEEE Standard : Standard for Software Verification and Validation Plans. IEEE Standard : Standard for Software Test Documentation IEEE Standard : Standard for Software and System Test Documentation Bill Hetzel, The Complete Guide to Software Testing, QED Information Sciences, Wellesley, Ma., Poul Staal Vinje, Test af Software, teknisk forlag, København, 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, Cem Kaner, Bad Software: What to Do When Software Fails, John Wiley, 1998 James Bach, "Risk Based Testing", STQE Magazine, 6/1999, Rex Black, Critical Testing Processes, Addison-Wesley, Hans Schaefer Slide no. 51