Sigma QTC i Maximoprojekt

2. Sigma QTC i Maximoprojekt Maximo anv�ndarf�rening Malm� 2008-10-23 Kl 13.00 � 14.30

3. Agenda Sigmas syn p� test QTC-konceptet Maximoprojekt d�r QTC kan anv�ndas

4. 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

5. Sigmas position p� Testkartan

6. Sigma Testing Model

7. 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

8. TestCenter - Konsolidering f�r enkelhet och v�rde

9. Testcenter - Organisation

10. 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. Allt l�ter ju enkelt, men f�r att lyckas �r det viktigt att vi t�nker r�tt fr�n b�rjan.

11. Vad �r dina f�rv�ntningar?Vilket svar f�r du p� fr�gan: �Hur g�r det?� Bet�nk statusrapporten nedan� 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�.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�.

12. 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.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.

13. 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?� Ge r�tt f�ruts�ttningar - input 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 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

14. 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.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.

15. Beslutsunderlag Rapportera Relevanta Resultat Kvantifiera, Kvalificera och Kommunicera 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? 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?

16. 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�.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�.

17. 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 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

18. 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 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

19. 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 N�r du identifierat vad som �r viktigt

20. 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�. 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�.

21. QTC

22. Maximo-projekt Implementeringsprojekt Uppgraderingsprojekt Patcher Add-Ons F�rvaltningsprojekt Olika typer av projekt/Aktiviteter g�llande systemutveckling i MaximoOlika typer av projekt/Aktiviteter g�llande systemutveckling i Maximo

23. Delar i en Maximo-leverans Processst�d, i form av systemanpassningar och konfigurationer Rapport- och analysverktyg, Anv�ndargr�nssnitt (Sk�rmbilder) Integrationer Teknik Migrering av data

24. QTC-komponenter i Maximoprojekt 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.Genom att vara en integrerad del av projektet kan QTC s�kerst�lla flera omr�den.

25. 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

26. Diskussion och fr�gor