Utvecklingen av test hos Microcraft AB 1 Bakgrund Naturvetare och ekonom i botten. En sån där ekonom En besvärlig användare ;) Microcraftare i snart 10 år Från början: utbildare, utvecklat hjälpsystemet, organisationsfrågor, testning 2 1
Testaren Anki Lloyd Roden, ½-dags seminarium i Göteborg 2001 Började leta info på nätet, böcker, utbildningar osv Test flyttade från kundutveckling till produktutveckling Grundkurs i testning SAST Fördjupning i test-och kvalitetsarbete ISEB Foundation Certificate in Software Testing EuroSTAR 2005 Exploratory Testing 3 Garp Affärssystem innehållande allt från olf, mps, inköp, ekonomi, logistik, projekthantering, varianthantering, butiksdata, crm, e-handel mm Standardsystem som hängt med sen 1984 Öppet system flertal vägar för export/import (COM/ODBC, XML, Ascii, SIE, generatorer, script) Valfrihet avseende plattform för server och databas (Windows, Linux, Unix) ALLA kör standardsystemet. Kontinuerliga uppdateringar som inte påverkar ev kundunika anpassningar Små och medelstora företag inom tillverkning och handel. Företag som sysselsätter mellan 10 och 250 personer, vars årliga omsättning är mellan 10 och 500 milj SEK och som har 5 100 samtidiga användare 4 2
Garp Ganska komplext system att testa Förvaltningsfas men med ständig vidareutveckling. Ibland större, ibland mindre ändringar. En huvudversion/år Löpande SP, försöker en/månad Supporterar och underhåller varje version i två år Versionshanteringen: Gamla versionen: 3.15 sp Huvudversion: 3.16 (sp) Utvecklingsspåret: 3.16A 3.17ß 5 Microcraft AB 1979 (3) Tre ägare/anställda effektivisera tandläkarpraktikers adm mha microdatorer och egenutvecklad programvara Dennis. 1982 (3) Fingal hyresredovisning och fastighetsförvaltning. 1983 (5) Två nya delägare 1984 (5) Astor konfektionssystem lanseras. Garp 1 påbörjas. 1986 (7) En ny delägare. Nu fem stycken delägare. Samtliga aktiva inom företaget. 1992 (16) Beslut om Garp 2 ny databas 1994 (18) Garp 2 börjar levereras 6 3
Microcraft 1995 (20) Beslut om Garp 3 1997 (20) Garp 3 börjar levereras. Samma db, kan köras parallellt med Garp 2. 1998 (24) Astor införs i Garp 3 1999 (25) Renodlat GARP 2000 (29) Lönemodulen läggs ner. Samarbete med och kopplingar direkt till Kontek Lön. Engelsk version av Garp. 2001 (30) Första e-handelslösningen 2003 (35) Två anställda går in som delägare med 5 % var. 2005 (39) Ingår i Jeeves koncernen Idag (39) Behov av fler utvecklare. Garp lever vidare i befintlig form. Jeeves Inception, Garp i Jeeves värld 7 Startläget ur testsynvinkel Ostrukturerat, oorganiserat, ofokuserat Utvecklarna gamla i gården testat vartefter var och en utvecklat tidigare Många gamla lik i lasten Svårt att få förståelse internt Varför frysa koden innan release? Ett försök att få till testning två veckor innan release av version i april 2000 kaos. Alla skulle testa. Ingen tog ansvar för ATT det gjordes eller HUR det gjordes. Ändå ett första steg. Eget feedbackdatabas fel och önskemål om vartannat 8 4
Vår hantering av felrapporter tidigare 9 Går ej återskapa Åtgärdas ej Åtgärdas Åtgärdad Hur få testning att fungera? Hur kan man väcka intresse och skapa förståelse för vad testning är, varför man testar och hur man skall testa? Man blir inte profet i sitt eget land, men ge inte upp! Att införskaffa verktyg eller införa nån av alla metoder hjälper inte om du inte har organisationen med dig! Information och utbildning! Föreläsning för ALLA om vikten av test ½ dag testutbildning för samtliga testare 1 dag Grundutbildning för utvecklare VÄLDIGT POSITIV RESPONS. Underlättar för mig som testledare 10 5
Verktyg Egenutvecklad feedbackdatabas (Access) TestNet Egenutvecklad lösning i Jeeves Enterprise Felrapportering HelpDesk Utvecklingslogg Utvecklingsförslag 11 Vår hantering av felrapporter idag 1. Snabb koll 3. Godkänd av testare Återöppnad 4. Godkänd av testledare (avslutad eller avförd) Avvakta (vid release) 12 2. Noterad Utredning el felrättning Klar för omtest Åtgärdas ej 6
Struktur TestNet första egentliga planerade testperioden Nu: testning en naturlig del av utveckling och planering Ständig förbättring och ständigt lärande 13 Tidsplan 14 7
Mätetal Statistik är som en bikini. Den ser jäkligt intressant ut men döljer det intressantaste. Men för att få en vettig uppföljning samt utveckla metoder, processer och organisationen är den nödvändig Dessutom ger det mer pondus åt test i på ledningsnivå! 15 Mätetal före release Defect Found: totalt rapporterade efter frysning av koden avförda verkligt rättade öppna vid leverans fördelat/produktområde (ekonomi, fsg/crm/butik, inköp/lgr/logistik, produktion, plattform) fördelat på vad som avses (programfunktion, filimport/-export, dokumentation, rapporter, språk) fördelat/allvarlighetsgrad fördelat/prioritet 16 8
Mätetal före release Pre-Release Defect Detection Percentage (PRDDP) Fault Feedback Ratio (FFR) 17 Mätetal efter release Defect Detection Percentage (DDP) (3 & 6 mån efter) Defect Fixed Percentage (DFP) (3 & 6 mån efter) 18 9
Erfarenhetsåtervinning - senaste releasen Löpande testarbete Testarbetet behöver planeras mer. För att detta skall kunna göras måste information om VAD som skall utvecklas och NÄR i tiden utvecklingen är planerad. På så sätt går det att planera i tid för testning samt hur testningen skall göras. Det krävs också att det finns kravspecar att utgå från. Test, dvs granskning, av kravspecarna skall ske. Test under frysperioden Den här gången rapporterades drygt 30 % av alla fel under frysperioden. Det vore bra om vi kunde sprida ut testarbetet mer löpande under utvecklingsperioden. På så sätt blir det mer tid till regressionstestning efter frysning. Detta ger bättre kvalitet på releasen och en minskad arbetsbelastning på utvecklarna under frysperioden. Utveckling av testarbetet Behov av kompetensutveckling finns och är uttalat när det gäller olika testmetoder. Detta för att få en effektivare och bättre testning. Detta kommer att ske till hösten. 19 Nuläge Alla vet att testning är viktigt samt varför det är det Testar alla på rätt sätt? Kunskapsöverföring en fredagseftermiddag (1 tim) Förväntan: en lathund Syfte: Väcka tankeverksamheten 20 10
Varför testar vi? Skall allt testas? Hur skall vi veta vad som skall testas? Hur skall vi testa? Vad skall vi tänka på? 21 Varför testar vi? Inställning till testarbetet You should want the program to fail, you should expect it to fail, and you should concentrate on finding test cases that shows it failure A test that reveals a problem is a success. A test that did not reveal a problem was a waste of time 22 11
Framtiden en utmaning! Garp Jeeves Inception Garp i Jeeves värld Testorganisation inom koncernen Testmetodik val Fokus på test 23 Sammanfattning Börja i rätt ände Ge inte upp! Förändringar tar tid Ta inget för givet Informera Utbilda Delegera Våga Stick ut 24 12
?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?! Anki Eriksson, Microcraft AB i Borås anki.eriksson@microcraft.se 25 13