Modul 3 Flashcards
(18 cards)
Kallelse till granskningsmöte:
Du kallas härmed till granskningsmöte för dokumentet “Kravspec … version X”
Plats:
Tid: datum och klocka.
Under mötet kommer vi gå igenom dokumentet i syfte att hitta fel och förbättringar av dokumentets kvalitet. Du behöver läsa dokumentet före och anteckna oklarheter. Du bör lägga ner ca 20min/sida före mötet åt granskning av dokumentet.
Bifogar aktuell version av dokumentet.
Förvaltning av krav med iterativa metoder
Blandad prioritering på krav inför varje iteration. Om ett nytt viktigt krav tillkommer behöver vi plocka bort ett mindre viktigt krav som tar ungefär samma tid att ta fram som det nya.
Steg 3 i granskningsprocessen:
Individuella förberedelser:
Granskarna förbereder sig individuellt inför mötet genom att läsa/granska och anteckna kommentarer om dokumentet.
Kan med fördel göras med trafikljusmetoden.
Små fel som stavfel bör mejlas till författaren innan mötet för att inte lägga tid på det under mötet.
Framgångsfaktorer för lyckad granskning:
- Författaren har gjort grundläggande kontroller av dokumentet, stavfel, slarv osv.
- Granskarna har fått tillräcklig med tid för att läsa dokumentet.
- Tillräcklig information till mötesdeltagarna. Hur ska mötet gå till? Vad ska vem granska?
- Rätt granskare valda, olika roller på granskarna.
- Långa diskussioner undviks. Hur något specifikt ska designas tex.
- Håll star- och sluttider. Rent hyfft.
2 problem som kan lösas med spårbarhetsmatris:
- Att bedöma konsekvenserna av förändring av ett krav.
- Att veta om det finns testfall till samtliga krav.
Spårbarhetsmatrisen visar kopplingen mellan krav och testfall.
Formella roller på granskningsmötet:
Författare
Presentatör
Granskningsledare/mötesledare
Granskare
Sekreterare
Konfigurationsansvarig
Samma person kan ha flera roller
Steg 1 i granskningsprocessen:
Planering:
Ofta är det författaren som initierar granskning av ett dokument. Arbetet inleds med att utse de personer som ska granska dokumentet och tilldela dem roller. Om dokumentet är långt är det vanligt att dela upp dokumentet i mindre delar och låta en eller några få granskare granska var sitt kapitel.
Testfall: Blackbox och whitebox
Testfall: dynamiska och statiska tester
Dynamiska: Testfall som kräver att systemet körs. Hit hör de flesta testfall.
Statiska: Testfall som utförs utan att systemet körs. Ex. granskning av kravspec eller kod.
Testtekniker:
- Testfall med olika vyer.
- Adhoc test: Klickar sig runt utan strategi och skriver felrapport om det behövs.
- Utforskandetestning: samma som Adhoc med med strategi. Skriver testfall medans man testar.
Testfall: positiva och negativa
Positivatester: testar att systemet fungerar som det ska när man inte pressar systemet till dess gränser. Visar att normal funktionalitet fungerar som den ska.
Negativatester: Testar systemets beteende utanför den normala användningen och pressar då systemet till dess gränser.
Steg 2 i granskningsprocessen:
Start/skicka ut dokumen och instruktioner.
- Skickar ut kallelse till mötet i god tid så att granskarna har bra tid till dokumentet.
- Informera granskarna om vad som ska hända före, under och efter mötet.
- Bifoga dokumenten som ska granskas.
Kan även vara instruktioner om hur mkt tid granskarna förväntas lägga eller/och hur dem ska skriva sin kommentarer.
4 utfall av ett granskningsmöte:
- Dokumentet godkänns om det inte längre innehåller nåra fel.
- Dokumentet godkänns med kompletteringar, om dokumentet innehåller ett fåtal mindre fel.
- Dokumentet måste granskas igen om dokumentet ännu inte har tillräckligt hög kvalitet.
- Mötet skjuts upp om viktiga personer inte är närvarande eller om för få av granskarna har förberett sig noga.
Steg 4 i granskningsprocessen:
Granskningsmöte:
Går igenom och diskuterar dokumentet stycke för stycke baserat på granskarnas kommentarer/synpunkter. Försöker undvika långa diskussioner. Syftet med mötet är inte att lösa problem utan bara att hitta problemen och fatta beslut om åtgärd.
Komponenttest:
Kallas också modultest. Testar koden ofta med teststubbar (automatiska testprogram). Funktionella tester på lågnivå.
Integrationstest:
Testar att de olika komponenterna funkar ihop.
Systemtest:
Testar hela systemet i en provdriftsmiljö. Både funktionella tester på högnivå och ickefunktionella tester i form av:
- prestandatest
- användbarhetstest
- stresstest
- säkerhetstest
- systemintegrationstest
Acceptanstest:
Testar att systemet uppfyller de överenskomna kraven och kan accepteras av beställaren. Utförs av beställaren under ledning av acceptanstestledare ibland tillsammans med leverantör.
