Presentation (in Norwegian) held at Trondheim Test Conference 2016. Discussing the shortcomings of traditional test strategies and suggesting ways to improve. Also presenting the idea to make the test strategy the contract between the test manager and the project manager.
God morgen…
Om meg: 25 års erfaring i IT-bransjen, først som utvikler senere prosjektleder, testleder, rådgiver, linjeleder.
Nå leder jeg Qualify – 9 konsulenter innen TL og testrådgivning. Testledelse med et ledelsesperspektiv
Har holdt foredrag på Eurostar om teststrategi – se slideshare (link på siste slide)
Primært PL –> PLs syn på TL. Forhåpentligvis er det nyttig, siden PL er TLs nærmeste foresatte. Samarbeidet mellom PL og TL må være bra for å lykkes.
Ønsker interaktivitet en tidlig morgen etter en hyggelig kveld
Be om eksempler / utfyllende kommentarer.
Hvorfor skriver dere (ikke) teststrategi?
Hvorfor er det (ikke) god bruk av tid? Er det bare oppfyllelse av «company policy»?
Min egen tolkning!
Ad hoc på 80-90-tallet
Fikk struktur gjennom 829
Ingen teststrategi, men veldig detaljert hva testplan skal inneholde. Med planer på flere nivåer ble mye gjentatt. Hentet ut det som er felles og overordnet; kalte det Strategi
Motivert mer ut fra rasjonalisering i produksjon enn fra et ønske om et reelt strategidokument?
Har blir alt for mye detaljer (anti-patterns)
Mye har skjedd med systemutvikling, men strategien henger ikke med (smidig, TDD, bedre IDE og automatisert testing). Fare for å bli irrelevant for utviklerne – stort skille mellom utviklere og de som skal kontrollere kvaliteten (eksternisering).
29119-3 Basert på og etterfølger 829 (Strategi som en del av plandokumentet, ikke nødvendigvis eget dokument). Strategi og policy på selskapsnivå.
Hvilket inntrykk sitter man igjen med? Testledere som viser at de ikke forstår sin rolle
Teststrategisidebæringskilometer
Har et nytt eksempel nå. Må lete i 30+ sider etter reelt innhold
Forklar bruken av «veiviser» i hjørnet – pedagogisk!
Ofte skriver vi i teststrategien at den bør leses av alle i og rundt prosjektet. Og det er jo fint, men ikke veldig viktig. Og hvis vi skriver et dokument for «alle» blir det lite målrettet for de som er viktigst.
Kommer tilbake til det med kontrakt, men tanken er å bruke strategien som kontrakt for «arbeidspakken» testledelse. Avviksledelse (MbE): Innenfor styrer du, men hvis du kommer utenfor toleransegrensene så skal det varsles og behandles
Ikke skriv ned alt det som står andre steder eller det målgruppen ikke strengt tatt trenger å forholde seg til (flytt det til testplan eller helst Wiki)
Alt for mange testledere synes å skrive for «menigheten», dvs egen testorganisasjon og andre testledere. Vanlig feil: Viktigere å fremstå som faglig flink enn å være effektiv i rollen
Lederne har ofte for mye å gjøre til å lese lange og detaljerte dokumenter.
Hvis du blir mindre opptatt av et dokument og mer opptatt av forankret innhold, så er det lettere å jobbe inkrementelt
Får du oppmerksomhet nok til å realitetsbehandle 3-4 viktige ting, så er det bedre enn et langt dokument som ingen egentlig tar stilling til.
Vil du treffe ledere, så snakk om det de bryr seg om
Kort presentasjon er modigere (og vanskeligere) enn å skjule seg bak 50 sider basert på en gammeldags og lite treffsikker standard
Kan pakke mye inn i en figur – viser helhet
Kan anrikes med farger, kolonner / «svømmebaner» o.l. for å vise f.eks. ansvar eller testmiljø e.a.
Kan henges opp og stadig trekkes frem – det kan du ikke med 4 side tekst
Hvis du av formelle grunner trenger lange dokumenter: Det holder normalt at testplanene er på den formen. De er uansett manifestasjonen av strategien
Sprinttakt, testfaser, ansvar,
Ta med noe om strategi for automatisering
Delegering av autorisasjon – grunnlaget for avviksledelse, Jfr PRINCE2
Eksternt view og internt view
Teststrategien kan brukes som delegering av autoritet til deg som TL.
Forutsetter et visst handlingsrom til testleder:
Hvis null toleranse: PL må involveres i hvert minste avvik. Fratar TL ansvar og motivasjon (blir bare overvåker for PL uten å sette inn korrektive tiltak). PL gjør TLs jobb.
Hvis ingen grenser: TL gjør PLs jobb.
«Du» ikke bare i betydningen testleder, men også metodeansvarlig, bestiller / prosjekteier, prosjektleder – utfordre TL til å levere nytte