Monday, December 15, 2008
Thursday, November 6, 2008
Tips för att lyckas bättre med acceptanstestning:
Vanligt är att skriva acceptanstester efter utvecklingsaktiveteten. Men att identifera vad som skall testas, vilka acceptanskriteria som skall vara uppfyllda efter utvecklingen redan har utförts ter sig rätt märkligt vid närmare analys. Då är ju produkten redan skapad.
Att istället identifera acceptanskriteria - vilka kriterier som skall vara uppfyllda för att en del av en produkt skall anses fungerande, och accepteras, av kund före en viss del av en produkt (t.ex en viss funktion i ett informationssystem) byggs ter sig aningen mer effektivt. Det blir färre överraskningar på slutet.
Detta är inga nyheter. Detta arbetssätt har länge använts inom produktutveckling inom industrin, som att bygga flygplan exempelvis. Identifiera först vilka test som skall passera - bygg sedan ett inkrement som gör att testet passerar.
Genom att synkronisera identifieringen av acceptanstest med kravutredning effektiviseras arbetet och onödiga fel undviks som beror på fördröjning mellan kravanalys och analys av testkriteria. Dokumentation blir mer korrekt och lättare att underhålla och överblicka.
Genom att kombinera kompetens hos traditionella kravutredare med kompetens hos traditionella QA-avdelningar kan en organisation få ett kraftfullt verktyg att uttrycka krav. Detta är också till stor hjälp för utvecklarna som när de utvecklar en viss funktion redan vet vad som kommer testas och alltså vet vad som förväntas av en särskild funktion som skall byggas.
Att därtill lägga iterativ (kontinuerlig) uppdatering av krav/test-specifikationer med hjälp av tidig feedback från utvecklingsteamet (genom kontinuerliga leveranser), tidig feedback från kund (genom att denne tidigt ser vad som utvecklats) och i en ideal situation, tidig feedback från användare, tas acceptanstestningen och värdet av produktutvecklingen ytterligare ett steg framåt.
Att istället identifera acceptanskriteria - vilka kriterier som skall vara uppfyllda för att en del av en produkt skall anses fungerande, och accepteras, av kund före en viss del av en produkt (t.ex en viss funktion i ett informationssystem) byggs ter sig aningen mer effektivt. Det blir färre överraskningar på slutet.
Detta är inga nyheter. Detta arbetssätt har länge använts inom produktutveckling inom industrin, som att bygga flygplan exempelvis. Identifiera först vilka test som skall passera - bygg sedan ett inkrement som gör att testet passerar.
Genom att synkronisera identifieringen av acceptanstest med kravutredning effektiviseras arbetet och onödiga fel undviks som beror på fördröjning mellan kravanalys och analys av testkriteria. Dokumentation blir mer korrekt och lättare att underhålla och överblicka.
Genom att kombinera kompetens hos traditionella kravutredare med kompetens hos traditionella QA-avdelningar kan en organisation få ett kraftfullt verktyg att uttrycka krav. Detta är också till stor hjälp för utvecklarna som när de utvecklar en viss funktion redan vet vad som kommer testas och alltså vet vad som förväntas av en särskild funktion som skall byggas.
Att därtill lägga iterativ (kontinuerlig) uppdatering av krav/test-specifikationer med hjälp av tidig feedback från utvecklingsteamet (genom kontinuerliga leveranser), tidig feedback från kund (genom att denne tidigt ser vad som utvecklats) och i en ideal situation, tidig feedback från användare, tas acceptanstestningen och värdet av produktutvecklingen ytterligare ett steg framåt.
Thursday, February 7, 2008
Kom-ihåg-lista för teknisk utveckling
Jag säger inte att jag lever så här fullt ut alltid hela tiden, men steg för steg kommer jag närmare
Sammanfattning: Minska den tekniska risken och skulden! Det låter tråkigt för kund i första läget, men oj vad det lönar sig när det finns på plats - och löpande förbättras, eller snarare - vad tydligt dyrt det blir när det inte görs.
Försök baka in tekniska förbättringar i funktionalitet som utvecklas för att också visa att "det händer något" för användaren.
- Ta itu med driftsättningsfrågor genast. Oavsett hur lite funktionalitet du har utvecklat. Se till att komma i land med en testmiljö som liknar den slutliga produktionsmiljön. Se sen till att snarast gå vidare till driftsmiljö, kanske utan att publicera någon officiell ingång till denna. Varför? Det inträffar alltid problem vid driftsättning av nya miljöer. Bättre ta itu med dessa genast innan verksamheten hamnar i "panikläge" för att komma i drift med redan utvecklad funktionalitet.
- Prioritera utbyte av gamla versioner av system, den tekniska skulden växer och blir alltför svår att underhålla med tiden.
- Prioritera gedigna testmiljöer. Det är jobbigt att återskapa produktionsmiljö i lokal testmiljö, men ta tjuren vid hornen, och buggar hittas och kan rättas innan det är dags för produktionsdrift. Ju tidigare det går att testa, desto bättre.
Sammanfattning: Minska den tekniska risken och skulden! Det låter tråkigt för kund i första läget, men oj vad det lönar sig när det finns på plats - och löpande förbättras, eller snarare - vad tydligt dyrt det blir när det inte görs.
Försök baka in tekniska förbättringar i funktionalitet som utvecklas för att också visa att "det händer något" för användaren.
Subscribe to:
Posts (Atom)
