Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

Transkript

1 Teststrategi Projekt CiviCRM Version 0.9 Sida 1(7)

2 Innehållsförteckning Referenser...2 Revisioner Inledning Uppgift Bakgrund Organisation Granskning och godkännande Kvalitetsegenskaper för test Tid Testgenomförande Testmetoder Specifikations-baserad testning Enhetstest Integrationstest Riskbaserad testning Funktionstest Användartester Utforskande testning Acceptanstest Testmiljö Testutförare Avvikelsehantering Felklassificering Dokumentation och rapportering Dokumentation Rapportering...8 Referenser Dokumentnamn / Hemsida CiviCRM hemsida Sökväg Revisioner Version Datum Revision Av Initial, ej godkänd version Terese B Sida 2(7)

3 1. Inledning Detta dokument beskriver vad som gäller specifikt för projekt civicrm. 1.1 Uppgift Testobjekt: CiviCRM ( Ta fram en mångfacetterad teststrategi. Använd lärdomar från veckans SFDIPOT-övning. Skriv den som om den vore en del av en testplan. Antaganden: Det är release om två månader Kvalitet har mycket hög prioritet All kod har skrivits om (och det finns inte så mycket enhetstester) Test-teamet består av två testare från en yrkeshögskoleutbildning 1.2 Bakgrund Från Civicrm.org: CRM är ett kraftfullt, webbaserat CRM-system (Customer Relationship Management). Det hjälper organisationer att hantera information om de olika människor och organisationer som de interagerar med. CiviCRM är mer än bara en adressbok och den information som samlas lagras på ett ställe, men du kan komma åt den från nästan var som helst. 1.3 Organisation Följande roller kommer huvudsakligen vara involverade: 2 st testare Utvecklare Uppdragsgivare 1.4 Granskning och godkännande Denna teststrategi ska granskas och godkännas av Uppdragsgivaren och Utvecklingschefen. Det är viktigt att den godkänns och förankras i projektet från fler håll än enbart testare för ett så lyckat resultat som möjligt. 1.5 Kvalitetsegenskaper för test Fokus på produktens kvalité är efterfrågat och kommer vara ledord genom hela projektet. Sida 3(7)

4 1.6 Tid Release av produkten planeras om två månader. 2. Testgenomförande Inför releasen behöver test genomföras för att säkerställa produktens kvalitet. All kod har skrivits om sedan förra release. För att i releasen ha en högkvalitativ produkt krävs att alla projektdeltagare har ögon och öron öppna för produktens svagheter och rapporterar in dessa till Testare1. Tänket att alla deltagare i projektet är testare behöver implementeras. Huvudfokus ligger på kvalitet och särskilt i de områden med hög användning. Målet med testgenomförandet är att säkerställa kvalitén på produkten. Detta genom att: Hitta fel och brister så tidigt som möjligt. Säkerställa att krav i specifikationer följs. Att noggrant dokumentera testprocessen och kontinuerligt rapportera fel och defekter. Illustration 1: civicrm Produktelement enligt Bach SFDIPOT Sida 4(7)

5 2.1 Testmetoder Specifikations-baserad testning Specifikations-baserad testning handlar om att testa utifrån specifikationer som beskriver produkten och dess detaljer. Utifrån krav, övriga specifikationer eller annan dokumentation skrivs testfall. Kraven som finns i specifikationerna är grunden till testfallen och ett testfall bör skrivas per krav Enhetstest Ett enhetstest validerar att en enskild enhet av koden fungerar och beter sig förväntat utifrån dess specifikation. Det är ett effektivt sätt att tidigt upptäcka fel i koden samt att säkerställa att inga oönskade förändringar införts. Enhetstester baseras på kännedom om kodens struktur, s.k. White Box Testing och görs därför av utvecklare. Denna typ av test är i detta projekt extra viktigt då ny kod implementerats Integrationstest Integrationstest innebär att man testar en del av systemet integrerat i produktionslik miljö. Testningen utförs av utvecklare och till viss del testare Riskbaserad testning Riskbaserad testning är ett sätt att prioritera testaktiviteterna baserat på riskområden. Riskfaktorn räknas fram genom en tabell gällande sannolikhet och konsekvens. De risker med hög sannolikhet/konsekvens kan prioriteras framför de med låg sannolikhet/konsekvens om tidsbrist infinner sig. Konsekvens Sannolikhet Hög Mellan Låg Hög Mellan Låg Funktionstest Funktiontstest testar att alla funktioner gör det de ska och inte gör det de inte ska. Funktiontstestningen kan, för att tjäna tid, ta stöd från den riskbaserade testningen och börja med de risker med hög riskfaktor. Sida 5(7)

6 2.1.6 Användartester Vi kommer ge tillgång till produkten åt en utvald användargrupp. Efter en genomgång kommer användargruppen få använda den för att testa. Deras återkoppling gällande buggar, fel, brister och allmänt intryck kommer vara till stor fördel för projektet Utforskande testning Genom hela projektet kommer testare (med hjälp av samtliga projektdeltagare) att kontinuerligt använda sig av utforskande testning. Med utforskande testning menas testning utan att testningen styrs av till exempel scenarion eller testfall. Testningen baseras på testarens kompetens och erfarenhet om produkt, system, risker och felbenägenhet. Som en del av den utforskande testningen kan nya testfall skrivas Acceptanstest Att levererad produkt möter de krav som beställts av beställaren. Villkor för godkännande av acceptanstest är : Inga fel klassade som Akuta eller Allvarliga kvarstår 2.2 Testmiljö Följande demomiljö används, Testutförare Två stycken testare från en Yrkeshögskola i Solna. Sida 6(7)

7 3. Avvikelsehantering Felrapportering sker i excel på Google Drive och klassificeras enligt nedan. 3.1 Felklassificering Prio Felklass Förklaring 1. Akut fel Stoppande fel där testen ej kan fortsätta utan måste avbrytas och rättning genomföras omedelbart. 2. Allvarligt fel En aktivitet går inte att utföra och felet kan inte kringgås. 3. Fel Det går att utföra en aktivitet, men inte på tänkt sätt. 4. Mindre fel Fel som ej påverkar funktionaliteten, t.ex. felstavningar och andra skönhetsfel. 5. Önskemål Ej fel enligt kravdokumentation, men funktionalitet som skulle förbättra systemet. Dessa prioriteras ej vid rättning utan ger upphov till en ändringsbegäran. 4. Dokumentation och rapportering Samtlig dokumentation finns tillgängligt på Google Drive. 4.1 Dokumentation Testplan för projekt civicrm. Produktriskanalys Testfall Testrapport med analys för projekt civicrm 4.2 Rapportering Löpande rapportering ska finnas tillgängligt för samtliga projektdeltagare på Google Drive. Veckorapporter skickas per e-post från testare till testledare för vidare distribution om så krävs. Sida 7(7)