Ledarskap inom testning: att genomföra ett testprojekt

Den klassiska åtstramningen av testningen

Alla som har testat system har upplevt att systemet som ska testas levereras sent. På nästan alla nivåer, från komponenter till hela system, stöter utvecklare på problem och leveransen blir antingen försenad eller ofullständig. I de flesta fall, när en tidsperiod har avsatts för att genomföra testningen, flyttas inte tidsfristen och testningen får mindre utrymme. Detta tvingar team att välja mellan kvalitet och snabbhet. För verktyg som erbjuder det bästa av två världar kan du ta en titt på vår lista över de främsta plattformarna för programvarutestning.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Partiell och stegvis leverans

Även om hela systemet inte kan levereras för testning kan viss funktionalitet – ett partiellt system – levereras med löftet att senare versioner kommer att innehålla den återstående funktionaliteten. När som helst kommer statusen för funktionerna i en version att vara:

• Slutförda enligt kraven: dessa funktioner kan testas – åtminstone isolerat.
• Ofullständiga: funktioner saknar funktionalitet och/eller är kända för att vara felaktiga.
• Saknas: uppskjutna för leverans i en senare version.

När det gäller de funktioner som är tillgängliga kan det vara möjligt att testa dem isolerat. De kan dock vara beroende av data som skapats av andra funktioner som ännu inte är tillgängliga, vilket kan göra dem svårare att testa.

Funktioner kan vara tillgängliga, men resultatet av dessa funktioner kan inte verifieras av andra funktioner som ännu inte är tillgängliga, så databasen måste undersökas före och efter testningen. Det är nästan säkert att dina tester från början till slut, som kräver testbara kedjor av funktioner, till största delen kommer att vara blockerade.

I nästan alla avseenden försvåras testning på systemnivå kraftigt när systemen är partiella.

Att försvara testningen

Ditt team måste göra framsteg, hur motigt det än är. Om systemet inte är tillgängligt, eller bara är delvis tillgängligt för teamet, måste du hantera förväntningarna och försvara din plan. 

Din testplan, oavsett om den är liten eller omfattande, är beroende av att systemet är tillgängligt – detta är ett antagande – så din plan måste ändras. Du kanske inte dokumenterar formella startkriterier, men budskapet är detsamma:

Inträdeskriterier är planeringsantaganden – om dessa kriterier inte uppfylls är dina planeringsantaganden fel och planen måste justeras.

Oavsett om du väntar på att systemet ska levereras eller har tillgång till ett delvis färdigt system kommer du ganska snabbt att få slut på meningsfulla saker att göra. Då måste du ha ett svårt samtal med din produktägare eller projektledare. Om tidsfristen för slutförandet inte flyttas kommer du att tvingas testa mindre. Vissa funktioner kanske testas mindre, eller helt tas bort från testomfattningen.

Chefen kanske tror att du kan ta igen tiden senare, men det är nästan aldrig möjligt i praktiken.

Förlorad testtid på grund av sena eller ofullständiga leveranser kan inte återvinnas genom att ’arbeta hårdare’.

Varför försenas testningen? Det finns många möjliga orsaker, men de brukar följa ett av dessa mönster:

• Miljöer kan inte konfigureras i tid. Personer började sent, var för upptagna eller saknade kvalifikationer för att skapa en meningsfull testmiljö. Det som finns tillgängligt är delvis, felkonfigurerat eller ofullständigt.
• Leveransen försenas eftersom arbetsomfattningen underskattades.
• Leveransen försenas eftersom programvaran innehåller fel och är svår att testa och korrigera.
• Leveransen försenas eftersom utvecklingsteamet saknar färdigheter, erfarenhet eller kompetens inom verksamhetsområdet eller den teknik de använder.
• Leveransen försenas eftersom utvecklingen började sent.
• Leveransen försenas eftersom kraven fortsätter att förändras.

Utanför listan ovan finns force majeure och andra externa faktorer som ligger utanför projektteamets kontroll. Om projektledaren insisterar på att tidsfristen för testningen inte ändras och testningens omfattning också är fastställd, har du en betydande utmaning. I vart och ett av fallen ovan talar orsakerna till den sena leveransen för att göra mer testning, inte mindre.

Om utvecklingsarbetet underskattas är testningen förmodligen också underskattad. Om programvaran innehåller fel kommer testningen att ta längre tid. Om utvecklarna saknar färdigheter kommer programvaran sannolikt att vara bristfällig och ta längre tid att testa. Om utvecklarna började sent (varför?) och omfattningen är oförändrad, varför skulle testningen minskas? Om kraven ändras är det sannolikt att dina planer ändå är fel – att arbeta efter en dålig plan gör oundvikligen livet svårare.

Hur många av de vanliga orsakerna till försenade leveranser tyder på att mindre testning krävs? Ingen av dem. Försvara din plan.

Rapportering av framgång och misslyckanden

De flesta testare vet att effektiv testning kräver nyfikenhet, uthållighet och näsa för problem. Den främsta drivkraften är att framkalla fel och skapa tillräckligt med bevis för att felen ska kunna spåras till defekter som sedan kan åtgärdas. 

Även om det är bra för produktens kvalitet att hitta (och åtgärda) defekter känns det ofta som att du ger någon dåliga nyheter när du kommunicerar defekter. Det kan vara en utvecklare som har gjort ett misstag någonstans och måste åtgärda det, eller så rapporterar du till intressenter att någon kritisk funktion inte fungerar korrekt och att systemet kommer att försenas.

Ingen tycker om att ge dåliga nyheter och det är naturligt att känna sig ovillig att göra andra upprörda, särskilt nära kollegor. Men känslan av att dina nyheter är bra eller dåliga är inget som budbäraren bör bekymra sig om. 

Defekter är alltid dåliga nyheter för någon, men testningens roll är inte att vara dömande på det sättet. I vissa avseenden är testaren som en journalist som söker sanningen. Kipling-dikten om Elefantens barn innehåller raderna:

Jag har sex ärliga tjänare:
    (De lärde mig allt jag visste)
Deras namn är Vad och Var och När
    Och Hur och Varför och Vem.

På samma sätt som en journalist berättar en nyhetshistoria berättar du historien om vad du upptäckte när du testade ett system.

Sanningen – nyheten – kan vara bra eller dålig, men ditt ansvar är helt enkelt att så gott du kan söka efter både problem och framgångar. Du försöker upptäcka vad ett system gör och hur det gör det. 

Precis i slutet av ett projekt är målet att leverera till produktion med så få kvarstående problem som möjligt. Du vill att alla dina tester ska godkännas, men vägen till framgång försvåras av testmisslyckanden som måste undersökas och lösas. Ditt taktiska mål är att hitta problem snabbt, men ditt slutliga mål är att inte ha några problem att rapportera. 

För att korrekt rapportera framgången eller misslyckandet i ditt testprojekt bör du överväga att integrera avancerade testhanteringsverktyg som erbjuder omfattande analys

Du behöver agera ungefär som en undersökande journalist – söka efter historien med ett kritiskt och självständigt sinne. Som Kipling skrev:

Om du kan möta Triumf och Katastrof och behandla dessa två bedragare precis likadant …

Då kan du behålla lugnet och göra ett bra jobb för ditt projekt och dina intressenter.

Erosion av testtäckningen

Oavsett vilka mål för testtäckningen som finns i början av testningen samverkar flera faktorer för att minska den täckning som faktiskt uppnås. Erosion är ett lämpligt begrepp eftersom det verkligen återspeglar den gradvisa minskningen av omfattningen av de planerade testerna och den oundvikliga insikten att alla planerade tester inte kan genomföras under den tillgängliga tiden.

Erosion av testtäckningen har flera orsaker innan testkörningen:

• För det första identifierar testplaner de risker som ska hanteras och den metod som ska användas för att hantera dem. Planer förutsätter vanligtvis en budget för testning – vilket alltid är en kompromiss.
• Bristfälliga, instabila eller ofärdiga systemkrav, konstruktioner och specifikationer gör det svårare att specificera tester. Systemtäckningen försämras av brist på detaljer i specifikationerna.
• Att testmiljöer blir tillgängliga sent eller är otillräckliga gör vissa planerade tester opraktiska eller meningslösa. Integrationstester i större skala kan vara omöjliga att genomföra enligt planen eftersom alla gränssnitt eller anslutna system inte kan göras tillgängliga.
• Prestandatestning kan försämras eftersom miljöerna saknar tillräcklig skala eller inte återspeglar produktionsmiljön.
• Sen leverans av programvaran som ska testas innebär att mängden testning inom omfattningen måste minska när tidsfristerna ligger fast.

Erosion av testtäckningen under testkörningen har också flera orsaker:

• Om kvaliteten på programvaran som ska testas är dålig när den går in i ett teststeg kan testkörningen vara särskilt frustrerande. De mest grundläggande testerna kan misslyckas, och de fel som upptäcks kan vara så fundamentala att utvecklarna behöver mer tid för att åtgärda dem än någon hade räknat med. Om testningen avbryts eftersom programvarans kvalitet är för dålig kommer ni att hamna efter i tidplanen. Om tidsfristen inte flyttas kommer vissa tester att tas bort från omfattningen.
• Om fler fel uppstår än väntat kommer själva cykeln med korrigering och omtestning att ta mer tid, och tiden kommer att ta slut innan alla tester har slutförts.
• När tiden tar slut och beslutet att lansera fattas kommer inte all testning att vara slutförd. Antingen nåddes vissa tester aldrig i planen, eller så finns det kvarvarande fel som hindrar att misslyckade tester slutförs. När driftsättningsdatumet inte flyttas uppstår den klassiska åtstramningen av testningen som nämndes ovan.

Att hantera erosion av testtäckningen är en av de utmaningar som testare möter i alla projekt. Saker går sällan smidigt, och att minska tiden för testning (och täckning) är vanligtvis det enda alternativet för att hålla projektet på rätt spår.

Det är inte fel att minska mängden testning; det enda som är fel är att minska testningen godtyckligt. När ni därför fattar beslut om vilka tester som ska tas bort måste inverkan på testmålen och de risker som ska hanteras ses över. Ni kan behöva ta er igenom några besvärliga samtal med intressenter.

När inverkan är betydande kan ni behöva leda ett möte med dem som ber om nedskärningarna (vanligtvis projektledningen) och dem vars intressen kan påverkas av nedskärningarna (intressenterna). Er roll är att redogöra för situationen när det gäller slutförda tester, det aktuella kända tillståndet hos det testade systemet, de tester som misslyckas och/eller blockerar framsteg samt mängden testning som återstår.

Era planer och modeller beskriver testningens ursprungliga omfattning och är avgörande för att hjälpa intressenter och ledning att förstå luckorna och de återstående riskerna samt fatta beslut om att fortsätta testa eller avsluta testningen.

Incidenthantering

När projektet går in i stegen systemtestning och acceptanstestning drivs det i stor utsträckning av de incidenter som uppstår under testkörningen. Incidenter utlöser aktiviteter under återstoden av projektet, och incidentstatistik kan ibland ge god insikt i projektets status. När vi kategoriserar incidenter måste vi tänka framåt på hur informationen senare kommer att användas.

En incident är en oplanerad händelse som inträffar under testning och som kan påverka ett framgångsrikt slutförande av testningen, beslutet om godkännande eller behovet av att vidta någon annan åtgärd.

Vi använder ett neutralt begrepp för dessa oplanerade händelser – incident. Dessa händelser benämns dock ofta med andra termer; vissa är mer neutrala än andra. 

Tester som misslyckas kan benämnas observationer, avvikelser eller problem – neutrala termer som inte förutsätter någon orsak. Men ibland används problem, buggar, defekter eller fel – vilket förutsätter att systemet är felaktigt. Detta kan dock vara en förhastad slutsats, och dessa benämningar kan vara missvisande.

Vi föreslår att ni reserverar termerna bugg, defekt eller fel för resultaten av diagnosen av fel i konstruktionen av systemet som testas, vilka vanligtvis leder till omarbete för utvecklingsteamet.

Incidenter visar sig på två sätt:

1. Systemfel: systemet beter sig inte som förväntat i ett test, det vill säga att det fallerar på något sätt eller verkar inte uppfylla något krav.
2. Avbrott i eller undergrävande av testning eller tester: någon händelse som påverkar testarnas möjlighet att slutföra sina uppgifter, till exempel förlust av eller fel i testmiljön, data, gränssnitt, stödjande och integrerade system eller tjänster, eller någon annan extern påverkan.

Systemfel

Dessa incidenter är ofta av det mest direkta intresset eftersom de undergräver förtroendet för systemets kvalitet. 

Avbrott och undergrävda tester

Vissa organisationer betraktar inte dessa händelser som incidenter över huvud taget – avbrott är en del av den turbulens som präglar projekt när de närmar sig sitt slut. Undergrävda tester, där miljön eller testuppsättningen är felaktig, kan skyllas på testteamet (för uppsättningen eller åtminstone för att inte ha kontrollerat den före testningen).

I båda fallen påverkas framstegen i testningen och, om du leder processen, är du ansvarig för att förklara förseningar. Därför bör du antingen registrera dessa händelser som incidenter eller be teamet föra en testlogg och dokumentera avbrott i miljön, konfigurationsproblem eller avsaknad av lämpliga programvaruversioner att testa. Om du inte gör det får du svårt att motivera förseningar i framstegen, och det kan påverka bilden av dig och teamet negativt.

Ska incidenter registreras eller inte?

I och med införandet av agila arbetssätt och metoder för kontinuerlig leverans har den traditionella synen på incidenthantering ifrågasatts. I projekt med etappindelning behandlas incidenter som möjliga arbetspaket för utvecklare, vilka godkänns utifrån allvarlighetsgrad och/eller brådskandegrad. 

Det finns en formell, ofta byråkratisk process att följa, där incidenter granskas, prioriteras och åtgärdas av utvecklingsteamet (eller något annat team). Avancerade verktyg för incidenthantering kan ingå.

I mindre, agila team är relationen mellan testare och utvecklare nära. Hela teamet kan träffas dagligen för att diskutera större incidenter, men oftare än inte upptäcks, diagnostiseras, åtgärdas och testas buggar informellt utan att någon incident behöver registreras eller att andra i teamet eller externa personer från verksamheten eller IT behöver involveras. Allvarligare buggar kan diskuteras och införlivas i arbetet med en användarberättelse eller samlas i särskilda iterationer eller sprintar för buggfixar.

Vi diskuterade syftet med och behovet av dokumentation i en tidigare artikel. Det resonemanget är relevant även för incidenter. Teamet behöver överväga om ett incidentverktyg och en incidentprocess behövs och om de är till hjälp för teamet och/eller krävs av personer utanför teamet.

Större team tenderar att förlita sig på processer och verktyg för att hantera incidenter av tre skäl: 

1. För att säkerställa att incidenter inte glöms bort
2. För att säkerställa att allvarliga problem granskas av intressenter och projektledningen 
3. För att samla in mätvärden som kan vara värdefulla under och efter projektet.

More Articles

• Så integrerar du DevOps-verktyg för AWS
• 9 bästa konferenserna om digital transformation att delta i 2026–2027
• Så använder du DevOps-mätvärden för att skala upp ditt företag

Att skilja brådskandegrad från allvarlighetsgrad

Oavsett vilken incidenthanteringsprocess du väljer rekommenderar vi att du tilldelar både en prioritets- och en allvarlighetskod till alla dina incidenter.

• Prioritet tilldelas ur ett testperspektiv och påverkar när en incident kommer att lösas. Testaren bör avgöra om en incident har hög eller låg prioritet (eller någon av de mellanliggande nivåer som kan vara tillåtna). Prioriteten anger hur brådskande felet är för testarna själva och baseras på den påverkan testfelet har på den fortsatta testningen.
• Allvarlighetsgrad tilldelas ur användarens perspektiv och anger om (vanligtvis) ett fel är acceptabelt eller inte. Slutanvändarna eller deras ledning bör fastställa allvarlighetsgraden eller, mer effektivt, vid behov ändra testarnas ursprungliga bedömning. Allvarlighetsgraden återspeglar påverkan som felet skulle ha på verksamheten om det inte åtgärdades före leveransen. Ett allvarligt fel gör vanligtvis systemet oacceptabelt. Om ett fel har låg allvarlighetsgrad kan det bedömas som för obetydligt för att behöva åtgärdas före produktionssättningen, men det kan åtgärdas i en senare version.

Om en incident stoppar testningen och testningen ligger på den kritiska linjen, stannar hela projektet.

En incident med hög prioritet stoppar all testning och vanligtvis även projektet.

Det viktiga att komma ihåg med klassificeringsscheman för incidenter är att inte varje brådskande incident är allvarlig och att inte varje allvarlig incident är brådskande.

Att hantera slutskedet

Vi kallar de sista stegen i vår testprocess för ”slutskedet”, eftersom hanteringen av testaktiviteterna under dessa sista, kanske hektiska och stressiga dagar kräver en annan disciplin än den tidigare, till synes betydligt mer avslappnade perioden för testplanering.

Kom ihåg att syftet med testning är att leverera information till intressenter så att de kan fatta ett beslut – att godkänna, åtgärda, avvisa, förlänga projektet eller helt överge det. 

Om ni har en gemensam förståelse för de modeller som ska användas vid testningen blir det mycket enklare att förklara vad som ”fungerar” (i förhållande till modellen), samt var saker inte fungerar och vilka risker dessa misslyckanden medför. Det är intressenterna som ska använda denna information för att fatta sina beslut – med vägledning från dig.

Ett av värdena med att använda en riskbaserad testmetod är att vi, när testningen begränsas sent i ett projekt, använder den kvarvarande risken som argument för att fortsätta testa eller till och med lägga till mer testning. 

När ledningen insisterar på att begränsa testningen bör testarna helt enkelt presentera de risker som ”byts bort”. Detta är mycket enklare när en tidig riskbedömning har genomförts, använts för att styra testaktiviteterna och följts upp under hela projektet. När ledningen kontinuerligt är medveten om de kvarvarande riskerna är det mindre sannolikt att de begränsar testningen från första början.

Och det var allt, lycka till med testningen!

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 ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på ordinarie kurspris!