När jag började med test under andra halvan av 90-talet så var V-modellen den första bilden av test som jag kom i kontakt med och det blev kärlek vid första ögonkastet. Den var ju begriplig!
Tyvärr blandar många ihop V-modellen med Vattenfallsmetoden vilket för mig är två helt skilda saker. Vattenfallsmetoden är ett sätt att driva ett projekt. V-modellen däremot visar i sitt enklaste utförande vad som testas på ena sidan och vem som gör testerna på andra sidan. Jag tycker V-modellen fortfarande är fantastisk för att påvisa att det görs olika typer av tester och att det behövs olika kompetenser för att genomföra dessa.
De senaste åren har jag emellertid gjort en liten justering av modellen. Acceptanstest heter ju traditionellt översta steget på V-modellens högra sida. Men när man arbetar iterativt i allmänhet, och agilt i synnerhet, så tycker jag Användartest är ett bättre namn. Acceptanstest låter så definitivt, som att man därefter inte behöver testa den funktionen mer. Jag tycker till exempel att det är omöjligt att acceptanstesta något inom en sprint. Acceptanstest görs ju på helheten, tillsammans med övriga funktioner. Däremot vill man gärna ha med sig användarna (verksamhetsexperter på uppdrag av beställaren) under hela resan och löpande få deras bedömningar.
Och det är nog just där som jag har mest användning av V-modellen idag. Att förklara skillnaden mellan systemtest (“Är systemet rätt gjort?”) och användartest (“Är det rätt system?”). Min ambition är att funktionerna ska vara avlusade och väl fungerande när de lämnas över från systemtest till användartest så att användarna kan koncentrera sig på att mäta systemets effekt och nytta. Ibland behöver jag också påminna användarna om att de inte ska leta efter funktionsfel utan ska koncentrera sig på att verifiera att systemet går att använda till det som det är till för.
Som född i början av 70-talet så tillhör jag en generation som inte har kroppen fylld av tribaler, asiatiska tecken eller namnen på mina barn. Från och till har jag likväl varit sugen på en tatuering men har inte kommit till skott eftersom jag inte vetat vad jag ska ha för motiv. Men nu vet jag. Blir det en tatuering så blir det definitivt en V-modell!
Härligt med kärlek!
Den gör att du nog har stor nytta av V-modellen.
Själv har jag lite svårt för den, dels för att den brukar ha tidspilar, och därmed höra ihop med den sämre delen av vattenfallsmodellen.
Dels för att kategoriseringen inte passar den miljö jag befinner mig i, där det finns ett fungerande system hela tiden, vilket innebär att funktionstest och integrationstest hellre görs tillsammans med systemtestning, för att därigenom få gratistestning av allehanda slag.
För att påvisa att det görs olika typer av tester använde jag länge verifiering vs. validering, men har nu insett att det tolkas väldigt olika.
Bäst (för mig) just nu är Michael Boltons Testing vs- Checking – http://www.developsense.com/blog/2009/08/testing-vs-checking/ – som ofta får poletter att trilla ner.
Sen ska man komma ihåg att alla klassificeringar är lite farliga, det är mycket som riskerar att ramla mellan stolarna när man specificerar vad olika delar ska täcka.
Snarare tror jag man ska använda kategoriseringar i utbildningssyfte, och när man lärt sig, så är det bara att slänga definitionerna och angripa problemen med fräscha, nyfikna tankar.
För hård kritik av V-modellen från Joakim Holm, se http://jockeholm.wordpress.com/2011/04/04/dissecting-the-v-model/
Bra och intressanta synpunkter Rikard!
Efter att nu ha snabbläst Boltons Checking (making sure that the program doesn’t fail) vs Testing (finding new information, learning how the program works) så tycker jag han har rätt men att han missar dimensionen med validering, dvs tester som kan avgöra om systemet löser uppgiften.
För mig är just det en väldigt avgörande detalj. Genom att kunna lyfta fram skillnaden mellan det en professionell systemtestare gör och det en verksamhetskunnig person kan bidra med så blir det t ex lättare att motivera vilka sorts testare som behövs.
Många kritiserar V-modellen och med de agila vindar som blåser just nu så är de allra flesta livrädda för att erkänna att det finns en tidslinje i testarbetet. Men självklart finns det fortfarande en tidslinje även om det idag inte går nio månader mellan komponenttest och användartest utan kanske dagar eller timmar eller minuter.
Som du Rikard är inne på så är alla projekt olika men även om du i din situation gör funktionstest och integrationstest tillsammans med systemtest så vill väl du ha dessa hyggligt genomförda innan någon slutligen accepterar systemet innan driftsättning?! Och förmodligen har utvecklarna testat sin egen kod innan du får ett nytt bygge, eller hur?!
Trender kommer och går och många blir besatta av det senaste och tror att det är den slutliga sanningen. Andra förpackar om gamla sanningar för att sedan sälja det som något nytt. Självklart går utvecklingen framåt (t ex agilt istället för vattenfall) men inte sällan så stämmer fortfarande de gamla sanningarna, bara man ser på dem med nya ögon.
Det viktigaste först: Jag tror inte att en testare kan göra ett tillräckligt bra jobb om man inte har verksamhetskunskap. Kan den inte skaffas, så får man samarbeta med någon som har den.
Det är intressant när man får reda på lite mer, och kan förstå vart olika åsikter kommer ifrån.
Jag är med och gör programvara som säljs off-the-shelf; vi har alltså ingen specifik kund som säger bu eller bä, produktens förtjänster visar sig först långt senare.
Men jag tror att även om det fanns en kund med acceptansrätt, så skulle jag vilja att testarna tittade på både verifiering och validering samtidigt. Jag tror Bolton tycker detsamma; validering ingår i både checking och testing.
Det finns en kraftfull dynamik i att tänka på både och; helheten utgörs av detaljerna, detaljernas för- och nackdelar bestäms av helheten.
Och ja, utvecklarna testar sin egen kod, men jag dubbelkollar ofta; och jag tycker det är bra om de även testar på systemnivå, både manuellt och automatiskt. Utan alltför tydliga ramar, så kan man få väldigt fruktbara överlapp (ingen testning är komplett.)
Men jag är helt med dig på Agile/vattenfall-trenderna; bra kod är fortfarande bättre än sämre kod.
Nästan alla projekt är en mix, och jag har upplevt mer lättrörlig utveckling i vattenfallsprojekt än i Agile-projekt.
Mycket intressant diskussion.
Skulle nog inte välja någon modell/metodik som tatuering då jag tycker dessa sällan hanterar sammanspecifika komplexa it-händelser effektivt över tiden. De som tatuerade in RUP för 5-10 år sen går nog med heltäckande kläder nu för tiden 🙂
Det viktigaste först: Jag tror inte att en testare kan göra ett tillräckligt bra jobb om man inte har verksamhetskunskap. Kan den inte skaffas, så får man samarbeta med någon som har den.
Håller helt med om detta och kanske går även ett steg längre då jag anser att även utvecklarna bör ha bra verksamhetskunskap för att designa/bygga “rätt system” från början.
Alla är nog överens om att jobbet blir bäst gjort om alla är experter på allt. 🙂 Men nu glider vi från ämnet i artikeln.
Jag hävdar fortfarande att V-modellen tydliggör att det behövs tester med olika syften och att detta kräver olika kompetenser. Om dessa kompetenser ryms i samma person så är det kanon.