Problem och lösningar

2006-05-10 Artikelbanken Test Läst 9739 gånger

Det finns ett oändligt antal faktorer som kan göra att slutprodukten inte håller tillräckligt hög kvalitet. Listan tar upp några vanligt förekommande problem och förslag till lösningar.

Problem vid kravställning

Kraven är luddigt skrivna eller inte testbara

  • Utbilda kravställarna i kravhantering. De har troligen mycket goda verksamhetskunskaper men vet inte hur krav bör utformas. Resultatet blir att kraven inte går att testa och i bästa fall bollas de tillbaka till kravställaren. I sämsta fall sker utveckling och test och när det kommer tillbaka till kravställaren inser denne att behoven misstolkats.
  • Använd dokumentgranskning. Sätt en eller flera personer på att granska alla kravspecar/användningsfall. När man granskar får man in nya infallsvinklar och många av felen kan hittas på ett tidigt stadium. Att granska kraven är därför en väl värd investering eftersom felen är billigare att åtgärda ju tidigare man hittar dem. Bäst kvalitet får man om man granskar formellt med noggranna förberedelser, ett strukturerad genomförande, rätt valda deltagare med kompletterande kompetenser och skriver ett protokoll efteråt.
  • Använd mallar för att åstadkomma ett enhetligt utseende på kraven. Det bör även finnas bra exempeldokument som tydligt visar hur mallarna ska fyllas i. Detta gör det lättare att dokumentera kraven på rätt sätt.

Det finns ingen kravspecifikation

  • Först och främst måste frågan ”varför finns det ingen kravspec” besvaras. Avsaknad av kravspec är ett tydligt tecken på en organisation som är omogen i sin kravhanteringsprocess. Bra krav är grunden till en fortsatt lyckad utveckling och detta problem bör därför åtgärdas snarast.
  • Informera tydligt om konsekvenserna, helst skriftligen (t ex via mail) så att du inte får skulden längre fram. Situationen går dessvärre inte att göra så mycket åt på kort sikt, men på längre sikt måste man underlätta arbetet med mallar, exempel och en begriplig kravhanteringsprocess. Kravställarna måste inse att en dokumenterad kravspec är nödvändig.
  • Lyft frågan till ledningsnivån och övertyga genom att visa vilka negativa konsekvenser det får för företaget. Säg inte bara ”vi måste testa”, det är inget argument som biter. Kronor och ören är ett språk som alla förstår. Beräkna hur många timmar som läggs ned på åtgärda fel som uppkommit på grund av luddiga krav. Läs dokumentet om mätetal i Faktabanken (www.konsultbolag1.se) för att få ytterligare tips om användbara mätetal.
  • Arbeta proaktivt t ex genom att använda tekniker som workshops för att samla in kraven för framtida releaser. Intervjuer är en annan kraftfull teknik, det finns förslag på intervjufrågor i Faktabanken (dokumentet ”Lyckas med intervjuer i kravhanteringsarbetet”).

Det tillkommer nya krav hela tiden

  • Ibland räcker det faktiskt med ett enkelt ”nej”. Kravställarna ser inte alltid själva att de nya kraven kommer in sent i processen.
  • Om ett ”nej” inte räcker kan en kompromiss vara lösningen. Gör en lista över de t ex tio senast inkomna kraven och prioritera tillsammans med kravställaren vad som absolut måste åtgärdas.
  • I de fall du inte har någon möjlighet att påverka så måste du informera om konsekvenserna. Helst skriftligen så att du har det svart på vitt.
  • Håll ett gemensamt seminarium för beställare och leverantörer för att skapa samsyn och förståelse för vilka konsekvenserna kan bli.

Beställarna vet inte vad de egentligen vill ha

  • Be beställarna ifrågasätta sina egna krav. Detta är inte samma sak som att motivera dem.
  • Det sägs att det inte är förrän man ser systemet som man vet vad man vill ha, och då är det ofta något annat än det som levererades. Använd prototyper för att visualisera kraven, alla kan förstå prototyper, men alla kan inte förstå kravspecar.
  • De vanligaste kravinsamlingsteknikerna är workshops och intervjuer, men dessa tekniker är inte bra för att hitta så kallade förväntade krav, krav som måste läsas in mellan raderna. Ytterligare tekniker behövs, exempelvis observation där kravledaren studerar en användare som utför sina vanliga arbetsuppgifter i systemet.

Det finns inte tillräckligt med resurser för att skriva kraven

  • Ta hjälp av en konsult. En kravhanteringskonsult bör ha erfarenhet av ett antal kravinsamlingstekniker samt kännedom om den typ av system ni utvecklar.
  • Arrangera en eller flera korta workshops. På bara en timme kan man få fram väldigt många krav.
  • Arbeta mycket med korta iterationer och prototyper. Därmed kan du stämma av med beställaren/användarna kontinuerligt för att se att systemet är på väg åt rätt håll.

Problem vid utveckling

Utvecklarna misstolkar kraven och hittar på egna lösningar

  • Sträva efter en tät dialog med utvecklarna. Vår erfarenhet är att i de fall man kan prata direkt med utvecklarna minskar missförstånden. Vissa anser att detta inte är nödvändigt om man har bra krav, men även med bra krav anser jag att man ska ha en tät dialog. Många av de mest lyckade projekten är de där kravställare, utvecklare, testare och projektledare suttit i samma rum.
  • Ta med någon representant från utvecklingsgruppen redan när kraven samlas in, exempelvis på en workshop.

Det som levereras från utvecklarna innehåller för mycket fel

  • Ofta beror felen på att utvecklarna har för dålig metodkunskap i hur de ska testa. De utför t ex sällan negativa tester, bara positiva. Utbilda därför utvecklarna i test med fokus på de utvecklarnära testerna. Syftet är att de ska få en förståelse för test och ökad kompetens kring hur det kan testa mer effektivt.
  • Använd korstester, det vill säga låt utvecklare testar varandras program i stället för att bara testa sina egna program. Detta leder till ett mått av oberoende testning och till att fler fel hittas tidigt.
  • Inför checklistor för komponenttest som utvecklarna kan följa. Checklistor kan tas fram av utvecklarna, av testarna eller i samarbete. Det finns exempel på checklistor för komponenttester i faktabanken.
  • Automatisera komponenttesterna med hjälp av testramverk. Detta fungerar utmärkt för de moderna programmeringsspråken som Java och C#.

Stor mängd följdfel vid rättningar

  • Inför som rutin att rättningar alltid ska granskas av en annan utvecklare innan rättningen införs. Kollegan kan granska koden för att leta efter följdfel och komma med förbättringsförslag.

Problem vid test

Kraven är inte testbara

  • Testare måste delta i dokumentgranskning eftersom de ställer sig frågan ”hur ska jag göra för att testa det här?”. Om något i kraven inte går att testa ska kravet formuleras om.

Det finns ingen spårbarhet mellan krav, testfall och felrapporter

  • Skaffa ett verktyg som visar denna koppling. Spårbarhet är viktigt av många anledningar:
    1. Det är viktigt att snabbt kunna bedöma vilka testfall som ska testas om efter en rättning.
    2. Du vill veta om det verkligen finns testfall till alla krav. Om det finns krav som inte har testfall, kommer de kraven med stor sannolikhet inte testas.
    3. På individuella krav eller testfall ska man kunna se vem som har gjort en förändring, vad som har ändrats och när det har gjorts.
    4. Genom att se vilka felrapporter som hör ihop med vilka testfall, kan man bedöma varför det har blivit så mycket fel.

Testarna hittar för få fel

  • Testarna kanske har för dålig metodkompetens dvs de använder sig av för få eller för enkla testdesigntekniker för att hitta fel. Utbilda dem i test.
  • Arbeta med mätetal för att få statisk över en period på hur mycket fel testerna hittar. Det finns många mätetal som visar olika delar, t ex S-kurva, procent hittade fel och fel-läckage.
  • Har testarna tillräckligt mycket tid avsatt? Ibland stjäl de ordinarie arbetsuppgifterna resurserna. Skriv ett resursavtal med testarens chef för att säkerställa tillräckliga resurser under testperioden.

Testarna hittar för många fel som borde ha hittats tidigare

  • Testplanen bör innehålla kriterier för att avbryta testerna om för mycket fel hittas. Ett sådant kriterium kan vara formulerat så att testerna avbryts om mer än fem fel av högsta allvarlighetsgrad hittas under en och samma dag. Det är viktigt att tydligt definiera vad som menas med ”högsta allvarlighetsgrad”.

Testgruppen är omotiverad eller svårstyrd

  • En motiverad testgrupp är en viktig framgångsfaktor. Testledaren behöver ha kompetens inom personalledning, konflikthantering, mål och motivation. Behöver jag nämna att vår kurs ”Bli en effektiv testledare” fokuserar på dessa mjuka faktorer?

Prestandaproblem

  • Prestandatester behöver göras tidigt om systemet kommer att ha många användare eller om systemet anropar andra system frekvent (gränssnitt mot andra system medför risk för prestandaproblem). God prestanda är mycket svårt att lägga till efteråt när problemen upptäcks. Prestandatesta därför arkitekturen tidigt och flera gånger under utvecklingstiden. Prestandatester bör, precis som alla andra tester, göras i en miljö som liknar produktionsmiljön så långt det är möjligt.

Testdata

Många organisationer har problem att söka ut eller skapa testdata. Det kan finnas för lite testdata, det kan vara för gammalt eller vara sönderhackat av testerna.

  • Utse en ansvarig för testdata. Det kan vara en databasadministratör som ansvarar för att söka ut eller skapa testdata för testerna.

Bidra gärna med fler problem och/eller lösningar. Maila mig på [email protected] så kompletterar jag dokumentet.

Tips för vidare läsning

  • Boken ”Test och kvalitetssäkring av IT-system” av Ulf Eriksson är en pedagogiskt skriven handbok i test. Den behandlar bland annat testledning, mätetal och testdesigntekniker.
  • Boken ”Kravhantering för IT-system” av Ulf Eriksson tar bland annat upp insamlingstekniker och dokumentgranskning.
  • I Faktabanken finns det många kostnadsfria dokument om test och krav. Det finns bland annat dokument om mätetal, exempel på intervjufrågor, samt exempel på olika testchecklistor.
  • Se även vårt kursutbud.

 

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln