Sigma QTC i Maximoprojekt Maximo användarförening Malmö 2008-10-23 Kl 13.00 – 14.30 Erik Helsing Philip Nederfeldt erik.helsing@sigma.se philip.nederfeldt@sigma.se

Agenda Sigmas syn på test QTC-konceptet Kvalitetssäkring av en IT-leverans sker genom test. Det är ofta lättare sagt än gjort och i många projekt innebär en undermålig testhantering fördyringar som långt överskrider besparingarna i testaktiviteter. Fördyringarna yttrar sig i leveransförseningar, buggar, akuta leveranser driftstoppskostnader, funktionalitetsnedsättningar och missnöje hos användarna. Denna workshop syftar till att beskriva Sigmas syn på test, samt beskriva hur vi på ett metodiskt och enhetligt sätt etablerar och jobbar i ett testcenter. Sigmas syn på test QTC-konceptet Maximoprojekt där QTC kan användas

Affärsidé Sigma Quality & Test (QT) Vem är kunden? - Vi vänder oss till företag och organisationer med IT-intensiv verksamhet Vilket kundbehov fokuserar vi på? Våra kunder vill: Kvalitetssäkra sina IT-plattformar & verksamhetsprocesser - nå högre effektivitet & kostnadsreduktion genom ett medvetet kvalitets- och testarbete Vad erbjuder vi? Vi erbjuder: - Processförbättringar inom test – Sigma Testing Model (STM) - Expertkonsulting inom test - Etablering och drift av testcenter - Mentorskap och utbildning inom test Varför ska kunden välja oss? Våra kunder väljer oss tack vare vår: - Kompetens – vi är specialiserade! Erfarenhet – etablerar och driver testcenter Attityd – vi är lite bättre att ha att göra med

Sigmas position på Testkartan Testroller Test Manager & Testledare Testanalytiker & -designer Test Configuration Manager Testare Specialist-kompetens Teststrategi & -processer (TPI & TMM) Kravhantering Sourcing av test ERP-plattformar: Maximo/ Platina Testnivåer Enhetstest Systemtest Integrationstest Acceptanstest Specialtjänster Utbildning och Mentorskap Etablering och drift av TestCenter Sigma Testing Model Användbarhet

Sigma Testing Model Strukturkapital baserat på internationella standarder, kompletterat med uppdragserfarenheter och verksamhetskunskap Processbeskrivningar Metod Mallar Checklistor Best Practice

Processförbättring inom test Målgrupp Organisationer som behöver förändra och förbättra sina befintliga arbetssätt Organisationer som saknar definierade processer Definiera affärsnyttan – Hitta rätt kvalitetsnivå Tänkbart resultat En gemensam syn på test – testpolicy En gemensam syn på vad som är viktigt i din organisation avseende test – teststrategi En dokumenterad och driftsatt process Enkel och effektiv administration – mallar och verktyg Verktyg för att styra rätt när det uppstår problem – mätverktyg

TestCenter - Konsolidering för enkelhet och värde TestCenter bidrar till enkelhet och kostnadseffektivitet genom att ansvara och hantera uppdragsgivares behov av test. Uppdragsgivare får: Effektivitet, tex genom kortare ledtider En tydlighet i överenskommelse och förutsägbart resultat Enhetlig hantering av tester Metoder och processer som är anpassade till uppdragens förutsättningar Återanvändning av metod och resultat Fokus på förstklassig testning, ”expertstöd” och mjlighet till ”one-stop- shopping” för testbehov

Testcenter - Organisation Beställare Affärskontakt Leveransansvarig Testcenter ansvarig Testmiljö & testdata QM, TM Testresurser

Tänk rätt – Testa rätt – få rätt Kvalitet Höj kraven på output från test genom att ge rätt input Som vi frågar får vi svar – vilka förväntningar har vi? Hur kravställer vi test? Vad är kvalitet? Vilka beslutsunderlag kan vi få? Allt låter ju enkelt, men för att lyckas är det viktigt att vi tänker rätt från början.

Höj kraven på output från test Vad är dina förväntningar? Vilket svar får du på frågan: ”Hur går det?” Betänk statusrapporten nedan… Statusrapport – Program X, Version 0.45 55 testfall har körts 34 tester var OK 14 tester var inte OK 17 felrapporter skrevs vid denna testomgången 14 felrapporter rättade från förra testomgången Din utmaning som beställare av kvalitetssäkring är VETA vad du vill ha! Hur hantera begreppet kvalitet - Vanligt problem i samband med nytt IT-system eller förändringar som påverkar vår verksamhet. Vad ingår i begreppet och hur kan vi med hjälp av verktyget test mäta att förväntad kvalitet uppnås? För att kunna veta vad du vill ha och vad du får, måste du också veta HUR du ska fråga. Förväntningar på och förutsättningar för test går hand-i-hand. Exempel på statusrapport Mycket information – man har lyckats fylla en hel sida, men ändå är det väldigt många frågor som står obesvarade. Om 55 körts och 34=OK & 14=NOK, hur gick det med de återstående 7? (Vad hände med de återstående 7? – Otydliga krav?) Hur många testfall skulle ha körts vid det här tillfället? (TF enligt plan?) Hur många testfall har körts jämfört med hur många som ska köras i hela projektet? (TF jämfört med totalt?) Om det finns tester som inte kördes – hur viktiga eller oviktiga var dom? (Ej körda TF – Prioritet?) Hur många felrapporter finns det totalt som ej är lösta? (Hur många olösta felrapporter?) Hur många felrapporter har testats men visade sig ej vara lösta på ett tillfredsställande sätt? (Antal rättade felrapporter=Failed?) Hur många av de nya respektive lösta felrapporterna var allvarliga? (Allvarlighetsgrad för nya/rättade felrapporter?) Hur många var mindre allvarliga? Hur ser den förmodade trenden ut framåt i tiden? Jämförelse med ett traditionellt bolag Jämför med en VD som rapporterar till sin styrelse eller ägare. Hon/han har klara riktilinjer och mål att styra mot. Dom är (eller ska vara) klart kommunicerade, kvantifierade och mätbara. En VD vet mer eller mindre intuitivt vilka nyckeltal hon/han skall rapportera och det är enkelt för en styrelse eller ägare att få information om status och förväntad progress. Samma sak bör gälla testverksamhet! Dvs, en testorganisation bör ha klart för sig vad den mäts på.

Hur går det?... egentligen Testresultat – Metrics – är Business Intelligence! En testorganisation ska kunna ge: rätt INFORMATION till rätt PERSON vid rätt TIDPUNKT för att fatta rätt BESLUT. Det handlar om att ge uppdragsgivaren ett snabbt och korrekt besked om: Vilken kvalitet som testobjektet har i förhållande till acceptanskriterierna? Kan vi gå till nästa testnivå? Kan vi produktionssätta/lämna över till förvaltning? En beställare måste definera kvalitetsbegreppet ur ett målperspektiv där man kan följa upp mätbara resultat. Dessa mätbara mål och resultat ska vara applicerade utifrån ett kvalitetsperspektiv där man har definierat vilka nivåer, eller vilken grad av kvalitet man vill uppnå. Testresultat = BI Testresultat – eller Metrics som det kallas – är att jämföra med BI, Business Intelligence. Dom tjänar som en grund för att fatta kloka och välgrundade beslut ur ett kvalitetsperspektiv. Rätt information till rätt person vid rätt tidpunkt för att fatta rätt beslut - Sigmas (och säker fleras) definition på BI En beställare skall när-som-helst kunna få svar på en statusfråga avseende kvalitet.

Ge rätt förutsättningar - input Ställ rätt krav på kvalitets- och testprocesserna För att en testorganisation ska kunna ge ett tillfredsställande och användbart svar avseende status på test krävs: En definition av kvalitet – acceptanskriterier Viktning mellan: tid – kostnad – kvalitet(Q) . Detta ger testorganisationen förutsättningarna för att på ett bra sätt mäta, tolka och presentera progress, som svar på frågan: ”Hur går det?” Vilka förväntningar har du som beställare på det du beställer? Är det klart och tydligt formulerat från dig? Är det klart och tydligt kommunicerat från dig? Testorganisation En testorganisation måste få tydliga riktlinjer för ramarna för test. - Vad är den förväntade kvalitetsnivån? - Hur förhåller sig tid-kostnad-kvalitet? Svårt att sätta siffror på men ger ändå en tydlig indikation på vad som prioriteras. Verktyg för ledning och styrning av verksamheten Parametrarna satta för att mäta tolka och presentera testresultat

Input – definiera kvalitet Definitionen av kvalitet är avgörande för varje projekt och ska finnas med från början som underlag för validering och verifiering av egenskaperna. Exempelvis: Att samtliga krav realiseras (alla ilities) Att systemet är stabilt, driftsäkert (Stability, Reliability) Funktionella krav (Functionality) Användbarhet (Understandability, Operatibilty, Usability) … De parametrar som definieras för kvalitet skall vara mätbara och sättas i förhållande till vilken risk det innebär om de inte uppfylls. Exempel: Stabilitet är viktigt. KRAVSTÄLL Jämför instruktioner från TOTEM…. Svensk standard, SS 02 01 04, definierar kvalitet som: Alla sammantagna egenskaper hos en produkt som ger dess förmåga att tillfredsställa uttalade eller underförstådda behov. Det är svårt för att inte säga vad som är KVALITET. Men om vi åtminstone har ett par punkter som vi använder som utgångspunkt får vi en enklare situation när vi letar efter vad som är kvalitet i aktuellt projekt: Verifiering (bygger vi systemet rätt) vs Validering (bygger vi rätt system?). FRÅGA ÅHÖRARE om förslag på parametrar som kan fungera som variabler på kvalitet: Pålitlighet/driftsäkerhet. Prestanda. Säkerhet. Lämplighet för användningsområdet. Servicevänlighet/underhållsbehov. Uppfyllelse av avtal (Leverans i tid, snabb reparation etc). Miljöpåverkan. Skillnader (för och nackdelar) gentemot konkurrerande produkter. Kostnad (både inköp, drift och avveckling). Utseende. External Quality Attributes Availability: The percentage of "up-time" during which the system is fully operational. Performance: The system's ability to meet latency, throughput and resource utilization requirements. Reliability: The extent to which the system will execute without failure for a specific period of time. Scalability: The system's ability to handle a large amount of data. Security: The system's ability to prevent and/or forbid restricted actions. Usability: The end user's ability to learn the system and complete tasks. Internal Quality Attributes Integrability: The ability to make the separately developed components of the system work correctly together. Maintainability: The system's ability to evolve and meet changing requirements. Modifiability: The ease with which a software system can accommodate to changes. Portability: The ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. Reusability: The degree to which existing applications can be reused in new applications. Testability: The ease with which software can be made to demonstrate its faults. Kvalitet: många av de aktiviteter som vi sysselsätter oss med under systemutvecklingsprojektet syftar till att upprätthålla kodkvaliteten; vi skriver enhetstester, skriver kodkommentarer, låter våra kollegor granska den kod vi skrivit, använder refactoring för att arbeta om kod som inte fyller de krav på kvalitet som vi har och så vidare. Så någon form av gemensam uppfattning om vad som är bra kodkvalitet finns uppenbarligen.

Beslutsunderlag 0 :- 100 :- Kostnad 0 h 100 h Tid Kvalitet Rapportera Relevanta Resultat Kvantifiera, Kvalificera och Kommunicera 0 :- 100 :- 36 :- Kostnad 0 h 100 h 74h Tid Kvalitet Rapportera Relevanta Resultat Kvantifiera, Kvalificera och Kommunicera Tid kan lätt mätas, ex. Vi har förbrukat 74% av våra man-timmar Kostnaden kan lätt beräknas, ex. Vi har förbrukat 36% av budgeterade kronor vid halva tiden… Kvalitet? Hur kan vi mäta den? 15

Hur kan vi mäta kvalitet? Per kravområde: definiera testfall, som baserade på ställda krav mäter. Ex: Stabilitet Hur uppträder systemet under givna förutsättningar över tid? Antal metoder/klass (antal kodrader). Buggar per rader källkod Funktion Uppfyllnad av funktionella krav Negativa tester Testresultat: Antal utvecklade och körda testfall kontra prioriterade krav Exempel på Stabilitet Hur uppträder systemet under givna (kravställda) förutsättningar över tid? Hur uppträder systemet om vi går över riktvärden? Hur uppträder systemet vid operationer som ligger utanför normal användning? Exempel på användbarhet Performance data (Objektiv data, vad hände i verkligheten) Preference data (Subjektiv data, vad tyckte användaren) Ändamålsenlighet och Effektivitet Kan användarna hitta information och klara av en uppgift? Kan användarna klara av en uppgift snabbt? Hur snabbt? Hur många sidor behöver användaren titta på innan h*n hittar rätt information? Hur står sig förhållandet mellan antalet sedda sidor (pages viewed) och hur många sidor som egentligen behövdes för att hitta all begärd information? Klarar användaran av att hitta rätt väg till informationen? Tappar användarna bort sig I site/produktnavigationen? Hur ofta? Hur många gånger används backknappen eller motsvarande? Reliability - No f defects identified in multiple rounds of testing or stress testing or burn in test and observe the stability. Code coverage -- % of code covered using tools such as VIsual pure coverage etc., 3) Design and code traceability -- % of conformance to design. No of design units covered to total design units 4) No of unit test cases per feature or method or class. Minimum 4 test cases per feature ( +ve, -ve and stress, system interaction) 5) % Conformance to standards -- use of fx cop or jtest and codify the rules 6) Number of methods/class, (6 avg), no of lines / method < 60). Same can be described for procedures, functions etc., 7) % of code documentation. No of lines of documentation/code base( atleast 15% in documentation). Javadoc has more details 8) Exception handling --- Clean exits for application and system exception with proper throw 9) DFT -- Design and code for testability -- Need to provide necessary trace to pinpoint errors. This will be a clear metric for MTTR ( mean time to repair) 10) elements such as scalability, performance would have been covered as part of the design and ideally should not be covered in code metric. 11) no of issues ( bugs and peer reviews)/ kloc at unit level 12) defect leakage % . Number of defects identified from system testing/ total no of errors. This will be a key metric För vem kan vi presentera? - Samma data, ger underlag för olika presentationer anpassade för målgruppen. (Beställare, projektledare, projektmedlemmar, styrgrupp, m fl.) Se instruktioner från TOTEM…. 16

Output – presentation av resultatet 1(2) Vi har som input fått att stabilitet är viktigt, att det skall mätas (och vad som skall mätas), nu visas testresultat över testfall på stabilitet. Kommentar: Vilka frågor föder denna grafen? Vad innebär t.ex. diffen mellan implemented och Run? Genom att lägga till planen för när funktionsleveranser ska komma till testavdelningen samt när de faktiskt gör det så har man adderat en hel del information till sin rapportering som gör en räcka med frågor onödiga att ställa. Här kan vi exempelvis se att gapet mellan antalet körda testfall och den levererade funktionaliteten sällan är särskilt stort. Hur många testfall skulle ha körts vid det här tillfället? - Besvarad Hur många testfall har körts jämfört med hur många som ska köras i hela projektet? - Besvarad Om det finns tester som inte kördes – hur viktiga eller oviktiga var dom? – Ej besvarad

Output - presentation av resultatet 2(2) Och lägg som sagt gärna in den förväntade trendutvecklingen för att ha ett hum om var man kommer att hamna i slutändan. Den här förväntade trenden kan även fungera som en målbild och man kan naturligtvis skruva lite för att uppnå ett visst mål. Har vi fått svar på våra frågor? Hur många felrapporter finns det totalt som ej är lösta? – Besvarad Hur många felrapporter har testats men visade sig ej vara lösta på ett tillfredsställande sätt? – Ej besvarad Hur många av de nya respektive lösta felrapporterna var allvarliga? - Besvarad Hur många var mindre allvarliga? – Delvis besvarad

Mätning av kvalitet – återanvänd! Identifiera de mätvärden som passar testorganisationen, testobjektet och verksamheten bäst. Håll ned antalet parametrar som mäts. Återanvänd parametrarna i kommande projekt för att bli bättre på att analysera resultat snabbare och med större träffsäkerhet. Tänk kvalitet och test TIDIGT! När du identifierat vad som är viktigt 19

Positiva effekter av tidig kvalitetskontroll Vi har möjlighet att tidigt få en korrekt uppfattning om kvalitetsnivån under pågående utveckling. Vi kan jämföra testresultat mellan utvecklings- och testavdelningarna och där igenom få en samlad och mer rättvisande bild av projektets progress -> korrigeringar i tid Tydligt beslutsunderlag för när vi kan lyfta oss till kommande testnivåer. En tidig indikation på projektets progress och vi kan tidigt mota Olle i grind. Vi får signaler om vad som behövs korrigeras förhoppningsvis innan det är ”för sent”. Vi som mottagare kan vara med och styra när vi är klara för nästa testnivå.

Kvalitetssäkring och Test (QTC) Analys Design Utveckling Imple-mentation Acceptans CR CR CR CR CR Kravhantering Verksamhetskrav

Maximo-projekt Många olika typer av projekt och systemutvecklingsaktiviter kan uppstå kring Maximo Implementeringsprojekt Uppgraderingsprojekt Patcher Add-Ons Förvaltningsprojekt Olika typer av projekt/Aktiviteter gällande systemutveckling i Maximo

Delar i en Maximo-leverans Hanteras och kvalitetssäkras i en gemensam leverans. Komplexitet som kräver samordning Processstöd, i form av systemanpassningar och konfigurationer Rapport- och analysverktyg, Användargränssnitt (Skärmbilder) Integrationer Teknik Migrering av data

QTC-komponenter i Maximoprojekt - För att säkerställa att: Acceptanskriterierna är verifierbara Testfall finns och kan användas för att verifiera leveransen Det finns kravspecifikationer som svarar mot testfallen Det finns testrutiner och testplaner framtagna Det finns en ändringshanteringsrutin framtagen och som efterföljs Säkerställa och leda tester på systemnivå Att följa upp och utvärdera att förväntad leverans har uppnåtts, avseende levererad kvalitet och enlighet med verksamheten i övrigt (Utility and Warranty) Leveransen är i linje med gällande strategi och affärsprocesser Genom att vara en integrerad del av projektet kan QTC säkerställa flera områden.

Slutord Kvaliteten på ett system mäts genom test Tester syftar till att hitta fel och skapa tilltro till systemet Byggs systemet rätt? Byggs rätt system? Alternativkostnaden för att testa är kostnaden för att inte testa Felrapportering, helpdesk, omtestning information, badwill mm

Diskussion och frågor