Ledarskap inom testning: Testplanering
Redaktörens kommentar: Välkommen till serien Ledarskap inom testning från mjukvarutestningsgurun och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i sina roller som testledare och chefer.
I den föregående artikeln gick vi igenom dokumentationens detaljer och några bästa metoder. Den här gången tillämpar vi mycket av kunskapen från tidigare artiklar och använder den för att planera ett testprojekt.
Anmäl dig till nyhetsbrevet The QA Lead för att få ett meddelande när nya delar av serien publiceras. De här inläggen är utdrag ur Pauls kursen Ledarskap inom testning, som vi varmt rekommenderar för en djupare genomgång av detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER och få 60 USD rabatt på ordinarie kurspris!
Vad är egentligen en plan?
En projektplan kombinerar projektuppgifter, uppskattade tidsåtgångar, beroenden och leveranser till en schemalagd modell av verkligheten.
Om du betraktar planen som en förutsägelse av framtiden skulle du vara mycket försiktig med att förlita dig på den, men det är vanligtvis precis vad vi gör.
Du kanske har stött på projektledare som behandlar sin plan som sin personliga verklighet – sin egen vanföreställda värld. Men vi bör inte vara så hårda mot projektledare – de är ofta motiverade att skapa en plan och leverera enligt den, oavsett vad som krävs.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Planen är inte verkligheten; den är en modell av verkligheten som kräver ständig förändring.
I den här artikeln går jag igenom varje steg i testplaneringen, inklusive:
- Leveranser
- Hur
- Resurser
- Ditt stödnätverk
- Uppskattningar
- Beroenden, risker och antaganden
- Kommunikation, åtaganden och rapportering av framsteg
Men först ska vi skapa oss en tydlig bild av hur användbar en plan är.
Varför planera?
Syftet med planering är vanligtvis att skapa ett överenskommet arbetssätt, en uppsättning åtaganden, beroenden, kostnader och en tidsplan för att leverera ett projekt. Planen är en överenskommelse mellan projektets intressenter, leverantörer och deltagare som vanligtvis beskriver följande:
- Vilka resurser som krävs och när
- När uppgifter behöver påbörjas och avslutas samt vem som ska utföra dem
- Vilka färdigheter som krävs för att slutföra uppgifterna
- Vilka verktyg och tekniker som stöder planen
- Vilka leveranser som ska tas fram och när de ska levereras
- Kostnaderna för den arbetsinsats och de resurser som krävs
- Processen för att föra projektet eller processen genom dess olika steg
- De risker som hotar leveransen.
Vissa av dessa aspekter kan vara specificerade i en strategi eller redan finnas på plats. Det kan till exempel vara känt vilka leverantörer som deltar och vad de ska göra för projektet. Verktygen och tekniken som ska användas kan redan vara kända och tillgängliga. Personerna, testmiljöerna och testdata kan vara klara. Det kan också finnas en strategi som definierar den process, det arbetssätt eller de tekniker som ska användas.
Medan strategin beskriver principerna eller teorin, beskriver planen däremot de praktiska detaljerna eller logistiken för hur projektet faktiskt ska levereras.
En strategi beskriver hur ett projekt i princip ska genomföras, medan planen definierar och bekräftar hur projektet ska genomföras i praktiken.
För många projektledare finns planen i programvara som Microsoft Project, men en genomförbar plan förutsätter att alla projektdeltagare vet vad de ska göra och hur det ska göras. För att uppnå detta måste planen och kunskapen om hur arbetet ska utföras kommuniceras till och förankras hos alla berörda.
Planering är en resa, inte en uppgift
För att citera USA:s tidigare president Dwight D. Eisenhower: ”planering är allt. Planen är ingenting.” Denna tanke är så viktig att den förtjänar att upprepas i nästan alla arbetssammanhang inom systemprojekt. Men vad innebär det att säga att planen är ingenting? Vad är poängen med att planera om resultatet är en värdelös plan?
Planen du till slut får är aldrig värdelös, men Eisenhowers tanke handlar om själva planeringsprocessen och dess värde jämfört med planen. Låt oss snabbt jämföra hur planering fungerar i längre strukturerade projekt respektive agila och kontinuerliga projekt.
Strukturerad kontra agil planering
I ett långsiktigt projekt behöver verksamheten, leverantörerna och den interna IT-personalen veta vilket åtagande som krävs av dem, så att de kan planera tillgängligheten för personal och fysiska resurser.
Det tar dyrbar tid att samla in den information som krävs för att skapa en plan. Med alla beroenden av resurser och människor, samt leverantörernas och den interna personalens åtaganden och prestationer, kan mycket gå fel. Vissa saker kommer att gå fel. Därför är planen, som en förutsägelse av framtiden, förenad med stora svårigheter.
Dagen efter att en plan har publicerats, och varje dag därefter, kommer ny information fram och vissa justeringar behövs. Krav tas bort; leverantörer levererar för sent; miljöer, testdata eller verktyg är inte klara i tid. Listan kan göras lång. Planering är aldrig en engångsuppgift, utan en kontinuerlig — nästan daglig — aktivitet.
Oplanerade händelser behandlas ofta som brus och får inte särskilt mycket uppmärksamhet. Men senare blir vissa av dessa mindre störningar stora problem. En av utmaningarna med vattenfallsprojekt är att denna kontinuerliga anpassning kan bli betungande, eftersom alla förändringar ses som onödigt petande. Projekt fortsätter ofta ändå, i hopp om att allt ska bli ”bra när det gäller”. Men så är det sällan, och det har sagts många gånger:
Hur blir ett projekt ett år försenat? En dag i taget.
Det agila arbetssättet är delvis en reaktion på frustrationen över fasta eller oflexibla planer. Agilitet är det beprövade alternativet till trögheten i omständliga, stegindelade arbetssätt. Men innebär det att agila projekt inte planerar? Nej.
Även i agila projekt krävs viss inledande planering för att strukturera arbetet, samla resurser och schemalägga — åtminstone på en övergripande nivå — lanseringsprocessen under de kommande månaderna. Men iteration för iteration, och ofta dag för dag, justeras den övergripande planen kontinuerligt för att ta hänsyn till händelser och ny information som kommer fram.
Planering är en kontinuerlig läranderesa, inte en uppgift med en leverans.
Testplanering
Hittills har vi tittat på projektplanering i stort och föreslagit att den i hög grad är en kontinuerlig aktivitet. Nu fokuserar vi specifikt på planering av tester i projekt.
Testplanering liknar projektplanering mycket – det är egentligen bara en plan i mindre skala. Testplanen måste naturligtvis också integreras med den större projektplanen, eftersom den är beroende av andra projektaktiviteter och leveranser (och andra uppgifter är beroende av testningen). Testplaner störs ofta eftersom dessa beroenden inte uppfylls.
Testplaner är relativt enkla på en övergripande nivå. Det kan finnas flera aktiviteter som är beroende av det överordnade projektet. Det är dessa som ofta visas som uppgifter i den större projektplanen. Men dessa aktiviteter fördelas inom ett team, som kanske har en stor mängd testobjekt att planera och genomföra tester för.
Denna detaljnivå är inte särskilt relevant för projektledarens tidsplan och definieras och hanteras vanligtvis lokalt inom testteamet.
Låt oss titta på några av kärnelementen i din testplan.
Leveranser
Vilka är testningens leveranser?
Vilken fråga! Det är väl testspecifikationerna, testerna, resultaten och rapporterna? Leveranserna finns i huvudsak i dokumentationen, så allt vi behöver bekymra oss om är att få ut dokumentationen och bocka av några rutor.
Men detta tillvägagångssätt, även om det är vanligt, bidrar delvis till att testning (och testare) har fått rykte om sig att vara dyra, trögrörliga byråkrater med litet värde. När allt kommer omkring, vem läser dessa omfattande dokument?
Anta att det inte finns någon avsikt att ta fram testdokumentation i ett agilt projekt. Det är mer än sannolikt, så vad levererar testningen egentligen i sådana situationer? Vilket värde har testning över huvud taget? Det är väl lite sent att ställa de här frågorna, eller hur?
När en komponent, ett delsystem eller hela systemet testas är resultatet bevis på hur systemet beter sig i en viss situation eller kontext. Bevis på systemets beteende samlas in och sammanställs för att presenteras för intressenter (utvecklare, användare, chefer osv.) så att de kan fatta ett beslut: åtgärda fel, integrera en komponent, acceptera eller avvisa funktionalitet, eller lansera eller driftsätta ett delsystem eller systemet som helhet.
Testningens leverans är bevis på systemets beteende som intressenter använder för att fatta ett beslut.
Nu är det i vissa projekt viktigt att tillhandahålla testdokumentation som dokumenterar hur ett test avgränsades, utformades, implementerades och genomfördes. Men det är bevisen på systemets beteende som är den slutliga värdefulla leveransen till intressenterna.
Värdet av testning är den grad av tillförsikt som intressenterna har när de fattar beslut baserat på testbevis.
Dessa bevis kan samlas in, tabelleras och analyseras systematiskt i avancerade testhanteringslösningar och presenteras för intressenterna i eleganta grafiska format. Eller så kan handskrivna anteckningar användas av en testare för att muntligen presentera testberättelsen för en produktägare vid ett ståuppmöte.
Oavsett hur bevisen samlas in och presenteras är testningens slutliga uppgift att överlämna bevisen.
Hur
Oavsett projektets omfattning eller metodik är testning beroende av en viss serie aktiviteter. Vi ska gå igenom en generell process ur testarens (eller teamets) perspektiv och därefter titta på några av de variationer som förekommer.
Det finns det som kan kallas ”testaktiviteter” och det finns ”teststödjande” eller ”logistiska” aktiviteter. För att vara säker på att alla aktiviteter finns med i planen kan du ha nytta av tabellerna nedan som checklistor.
En aktivitet i tabellen ovan som du kanske inte känner igen särskilt väl är återkopplingsaktiviteten. Du har säkert redan behövt arbeta med bristfälliga krav.
Återkopplings-, gransknings- och utmaningsaktiviteten är det tillfälle då testare, efter att ha tänkt igenom och modellerat ett krav, upptäcker problem och kan använda exempel för att visa var kraven saknas, är tvetydiga eller motsägelsefulla.
Om du bedömer att kraven är bristfälliga är det definitivt värt att avsätta utrymme för denna aktivitet.
Testlogistik
Testlogistiken stödjer testaktiviteterna ovan. Medan listan över testaktiviteter som jag har angett är relativt omfattande varierar testlogistiken mellan varje projekt och organisation. Listan nedan är därför inte fullständig. I ditt projekt bör du ta dig tid att tänka igenom varje aktivitet eller beroende som krävs för att leverera testning.
Resurser (mänskliga, fysiska)
Vi använder ofta ordet resurser för att hänvisa till personer i våra projekt, och för vissa känns det inte bekvämt. Människor är inte saker, utan självklart mänskliga varelser. I mindre projekt kan det vara möjligt att använda namn, men i större organisationer där projektteam ingår och kanske ännu inte är bemannade är ett antal resurser helt enkelt en förkortning för ett antal personer.
Ännu viktigare är att det inte nödvändigtvis är antalet personer som räknas – det är deras förmågor som verkligen spelar roll. Människor arbetar självklart på olika sätt och vanligtvis i olika hastigheter, så du behöver ta hänsyn till detta i din planering.
Utöver personer behöver du i olika skeden olika fysiska resurser för att testningen ska kunna fortsätta. Dessa sträcker sig från det vardagliga till det högst specifika, och avsaknaden av någon av dessa kan äventyra testuppdraget.
Du kanske redan har turen att ha tillgång till ett fullt utrustat, hanterat och dedikerat testlaboratorium. Om inte kan du behöva specificera allt – från fysisk lokal och möbler ner till självhäftande lappar och suddgummin – för att definiera din arbetsmiljö.
I tabellen nedan finns några typiska resurser som krävs. Din lista kommer utan tvekan att skilja sig avsevärt.
När du har identifierat alla resurser som krävs för att genomföra din plan bör du överväga om du behöver lägga till ytterligare aktiviteter i planen för att införskaffa dem.
Ditt stödnätverk
Om personerna och kompetenserna du behöver för att utföra testningen stod under din kontroll skulle projekten kunna vara mycket enklare! Men få team har alla de kompetenser de behöver eller behörighet till och åtkomst till de nödvändiga fysiska resurserna. Många projekt bemannas och drivs enligt en matrisorganisation. Viktiga teammedlemmar rapporterar faktiskt till chefer för andra specialistavdelningar, och du får bara ett begränsat åtagande från dem.
Du kan behöva ange ett visst antal timmar per dag eller schemalägga tider för att få tillgång till specialistkompetensen ovan. Ibland blir du ombedd att ange vilken servicenivå som är acceptabel, t.ex. att ”högprioriterade förfrågningar besvaras inom trettio minuter” och så vidare.
Uppskattningar
Att göra uppskattningar i programvaruprojekt är komplicerat. Mycket har skrivits om hur svårt eller till och med omöjligt det är att göra uppskattningar. Men uppskattningar krävs i alla projekt, och ju större projektet är, desto mer förlitar vi oss på dem.
Vi behöver uppskattningar för att skapa en tidsplan, men problemet är att uppskattningar inte ger någon exakthet. Det bästa vi någonsin kan göra är att beräkna en arbetsinsats eller förfluten tid med en viss grad av säkerhet eller sannolikhet.
Vissa betraktar uppskattning som en svartkonst, och det finns till och med en rörelse kallad #NoEstimates med många anhängare. Det råder stor oenighet om huruvida uppskattningar någonsin kan vara tillräckligt exakta eller om de ens är en god praxis i programvaruprojekt.
Uppskattning kommer aldrig att vara en exakt vetenskap. Men utifrån mina erfarenheter finns det några principer som jag känner mig bekväm med att dela:
- Kraven är bristfälliga och inexakta.
- Människor är mer eller mindre kompetenta, samvetsgranna och hårt arbetande.
- Ju mindre arbetsuppgiften är, desto enklare är den att uppskatta. Dela upp stora uppgifter i mindre enheter när det är möjligt och summera uppskattningarna till den större uppgiften.
- Uppskattning baseras på erfarenhet. Om du inte har någon, ta reda på var andras erfarenhet är relevant och kan anpassas.
- Din arbetsuppgift är unik, så leta efter arbetsmönster i andra kända situationer där du har erfarenhet.
- Be andra att göra uppskattningar och jämför dem. Diskussioner om avvikelser synliggör skillnader i förväntningar, säkerhet och noggrannhet.
- Uppskatta situationen i bästa fall och därefter situationen i värsta fall. En bra uppskattning ligger någonstans däremellan.
Gör en uppskattning idag och börja arbeta. I morgon och varje efterföljande dag kommer din uppskattning av tiden tills arbetet är klart att förbättras tack vare den kunskap du har fått.
Beroenden, risker och antaganden
I en tidigare artikel diskuterade vi risker och testningens roll i riskhanteringen. Produktrelaterade risker handlar om huruvida produkten uppfyller användarnas behov med avseende på funktionella eller tekniska krav. Här ligger fokus på riskerna för den faktiska leveransplanen.
Saker går fel i projekt. I planeringsarbetet behöver du tydliggöra vilka risker för misslyckanden du har övervägt och tagit höjd för. Det finns tre aspekter av detta: beroenden, risker och åtgärder.
Beroenden
Beroenden utgör en lista över de mänskliga och fysiska resurser samt föregående aktiviteter som måste vara slutförda för att dina planerade aktiviteter ska lyckas och leverera.
Det finns alltid beroenden för alla testaktiviteter, oavsett om det gäller ett storskaligt test på systemnivå eller en utforskande testsession av en funktion. Beroenden omfattar tre huvudområden.
Risker
Risken är sannolikheten för att din plan misslyckas under genomförandet. Risker kan handla om sådant som:
- Dina uppskattningar: vad skulle kunna göra dina uppskattningar felaktiga? Att systemet är mer komplext, behäftat med fel, ofullständigt eller ständigt förändras kan påverka dina uppskattningar.
- Att personer inte är tillgängliga, saknar erfarenhet eller kompetens eller inte är fullt engagerade i din fas av projektet. Det kan vara teammedlemmar eller personer i ditt stödnätverk.
- Att infrastruktur, såsom testmiljöer, verktyg (eller utbildning i hur verktygen används) eller kontorsutrymmen, inte är tillgängliga, är felaktigt förberedda eller defekta.
- Att föregående aktiviteter inte slutförs i tid (eller överges, levererar ofullständiga eller defekta produkter eller inte levererar alls).
Åtgärder
För var och en av dessa risker behöver du bedöma sannolikheten, konsekvensen och, när det är betydande, en lämplig åtgärd eller förväntad följd. Dessa åtgärder brukar ta en av följande former:
- Antagande: risken bedöms vara tillräckligt låg för att ignoreras eller betraktas som obetydlig. Men den finns på radarn och dokumenteras som ett antagande (om tillgänglighet, fullständighet osv.).
- Justering: risken är betydande, men det finns en åtgärd som kan minska dess påverkan på planen. Om systemet som ska testas exempelvis bara har levererats delvis och vissa funktioner saknas, kan planen justeras så att endast de tillgängliga funktionerna testas.
- Konsekvens: vissa risker kan inte hanteras inom planen. Om systemet levereras sent kan testningen inte börja förrän det har levererats.
Kommunikation, engagemang och rapportering av framsteg
Slutligen kommer vi till en avgörande men ofta förbisedd aspekt av planeringen. Du kan ta fram en projektplan som innehåller alla uppgifter, deltagare, resurser, ansvarsområden, beroenden, tidsramar, arbetsinsatser och kostnader. Eller så kan det handla om en muntlig överenskommelse mellan medlemmarna i ett agilt team.
Oavsett vilket behöver planen kommuniceras effektivt till alla, så att alla vet vad som krävs och när.
En överenskommen plan är ett avtal mellan deltagarna. Om en teamchef godkänner en plan innebär det implicit eller explicit ett åtagande att uppfylla teamets del av avtalet.
Planen är ett avtal mellan deltagarna.
I mindre formella projekt kanske det inte finns någon skriftlig plan eller några åtaganden alls. Under sådana omständigheter är planen en pågående dialog mellan teammedlemmarna. Teamet träffas dagligen och de aktiva uppgifterna i planen diskuteras i realtid. Vad arbetar deltagarna med? Går arbetet framåt enligt förväntningarna? Vilka problem upplever deltagarna? Vilka problem hindrar arbetet från att gå framåt?
I alla projekt är syftet med lägesrapporteringen tvåfaldigt. Det finns uppenbarligen ett behov av att kommunicera var alla befinner sig när det gäller deras aktuella projektaktiviteter. Men lägesrapporten är också en återkommande kontroll av att framstegen kan upprätthållas och ett sätt att verifiera att deltagarnas åtaganden går att lita på.
Tack för att du läste, följ med oss nästa gång för … du gissade rätt, genomförandet!
Anmäl dig till nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs i testledarskap, som vi varmt rekommenderar för en djupare genomgång av detta och andra ämnen. Om du gör det, använd vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på kursens fullständiga pris!
