Meny

Vad ska jag göra när det inte finns tillräckligt med tid att testa?

what do when there isn t enough time test

Prova Vårt Instrument För Att Eliminera Problem

Delvis genom testcykeln, inser du ofta att du inte har tillräckligt med tid att testa? Du hade allt under kontroll, till att börja med, men snart når du beredskapsplanens 'Vad ska man göra när det inte finns tillräckligt med tid att testa?' sektion.

Jag har också varit där och det är inte kul. :)

Jag tänkte på det här länge och hårt. Hur kan något som började så bra gå ner så illa, så snabbt. Och här är min analys.

=> Klicka här för en fullständig handledningsserie för testplan

Vad du kommer att lära dig:

Var gick min testtid?

Inte tillräckligt med tid att testa

vad är en swf-fil?

För det första, varför händer detta?Många skäl - varav några är:

# 1) Felaktig uppskattning :

Om du började med en felaktig förväntan kommer saker och ting att misslyckas. En bra testuppskattning måste ta hänsyn till följande:

  • Dags för förberedande uppgifter - Vi pratar om uppgifter som:
    • Identifiera och sätta ihop en regressionssvit
    • Skapa testdata
    • Dags att bestämma testberedskapen (t.ex. rök / sanitetstest) etc.
  • Testunderhållsunderhåll : Testfall är långsiktiga tillgångstillgångar. De kommer säkerligen att genomgå mindre uppdateringar under körningen. Det rekommenderas att upp till 30% av din testkörningstid tilldelas nya produkter för dessa mindre underhållsuppgifter. Alla team och projekt behöver kanske inte 30%, men avsätter lite tid och ansträngning för den här uppgiften.
  • Till detta / Exploratory testing - Antalet skripttest är en viktig nämnare för testuppskattningsnummer. Inget testteam i den här världen kommer dock att förneka att utforska din programvara även om modellen är dominerande manus.
  • Rapportering / kommunikation - Detta inkluderar triage / stand up-möten, uppdatering av arbetshanteringsverktyg etc.
  • Beredskapsfaktor: Standarder rekommenderar 25-30% buffert till dina ursprungliga uppskattningar. Men lag har sällan råd med det. Även då, lämna ett litet andningsrum, när det är möjligt.
  • Team och dess förmågor: Om du har ett nytt team eller om de använder ett verktyg för första gången kan du behöva avsätta lite tid för träning. Skräddarsy dina uppskattningar baserat på ditt team du arbetar med.

Rekommenderad läsning=> Kontrollera detta för mer information om testuppskattningens framgång och metoder

# 2) Instabila konstruktioner och andra tekniska problem:

  • Fel på rök / sanitet : När de grundläggande testerna på AUT misslyckas efter distribution i QA-miljö finns det nästan ingenting som QA-teamet kan göra mot testkörning. Det är sant att vi kan arbeta med andra uppgifter medan detta händer, men det kommer fortfarande inte att fylla testcykel tid. Så detta är en viktig bidragsgivare till slösad tid.
  • Testdata inte tillgänglig : Produktionsliknande data är ett måste för varje testprojekt. Att inte få detta in i QA-miljön i tid är också en annan blockerande faktor. Ibland kan testare kringgå detta genom skapa och hantera sina egna testdata , men det är tidskrävande och kanske inte alltid är på plats.
  • Miljöfrågor - Bygga misslyckade distributioner, servern fortsätter att få timeout, många fler sådana problem äter bort din testcykel. Detta beror förmodligen på det faktum att vissa företag (inte alla) undergräver vikten av en bra, levande miljö för effektiv QA. De försöker ofta ta bort servrar med låg kapacitet och make-do-inställningar. Det här är verkligen en kortvarig fix och gör ingen någon tjänst. I själva verket kan det kosta dem kvaliteten på testning och förlust av värdefull testtid.

# 3) Brist på överenskommelse mellan alla inblandade parter:

Detta kan vara ett sällsynt problem med lag som följer Agile eller Säker på grund av de nära kretsar de arbetar i, men många team lider fortfarande av oenighet eller felkommunikation när Dev, Ops och QA ska ta emot leveranser från varandra. Därför förseningar.

För att förstå kommunikationsfinesser, kontrollera detta => Hur Business, Development och QA kan arbeta tillsammans för att projektet ska slutföras

Nu när vi känner till problemen, här är några sätt att åtgärda det.

Hur kan testare få tillräckligt med tid för testning?

# 1) Uppskatta exakt. I tvivel överskattas med rimlig marginal, men underskattar inte. Glöm inte att göra justeringar baserat på ditt team, verktyg och processer. När du är klar, sök officiell avloggning så att alla är medvetna och hålls i slingan.

#två) Ta hänsyn till historiska data - Testhanteringsverktyget är din bästa vän .

  • Hur lång tid tog de tidigare släpptestcyklerna?
  • Vilken typ av problem orsakade avbrott i föregående testcykel?
  • Hur många körningar tog de flesta testfall innan de klarat?
  • Vilka brister rapporterades?
  • Vilka brister orsakade att testet avbröts?

# 3) Ställ dessa frågor och planera därefter i knäcktid:

  • Ta reda på Viktig funktionalitet är ditt projekt?
  • Ta reda på högriskmodulen för projektet?
  • Vilken funktionalitet är mest synlig för användaren?
  • Vilken funktionalitet har störst säkerhetspåverkan?
  • Vilken funktionalitet har störst ekonomisk påverkan på användarna?
  • Vilka aspekter av applikationen är viktigast för kunden?
  • Vilka delar av koden är mest komplexa och därmed mest felaktiga?
  • Vilka delar av applikationen utvecklades i rus- eller panikläge?
  • Vad tycker utvecklarna är de mest riskfyllda aspekterna av applikationen?
  • Vilka typer av problem skulle orsaka den värsta publiciteten?
  • Vilka typer av problem skulle orsaka de flesta kundserviceklagomålen?
  • Vilka typer av tester kan lätt täcka flera funktioner?

Med tanke på dessa punkter kan du kraftigt minska risken för att projekt släpps under mindre tidsbegränsning.

# 4) Använd ett testhanteringsverktyg. Detta minskar tid och ansträngning förberedelser, rapportering och underhåll avsevärt.

=> För en lista över det mest populära valet för testhanteringsverktyg , kolla in här :

stack datastrukturen c ++

# 5) Det finns inte mycket vi kan göra för felaktiga konstruktioner / tekniska problem, men det enda som kan hjälpa är att titta på enhetens testresultat. Detta ger oss en uppfattning om huruvida konstruktionen var en framgång eller inte och vilken typ av tester som misslyckades - så att vi inte uppfinner hjulet på nytt.

Om din Test Management Tool stöder CI-integration , har du den informationen tillgänglig utan krångel så att du förstår applikationens stabilitet bättre.

# 6) Mät din produktivitet och framsteg ofta . Låt inte statusrapporter levereras bara till förmån för externa team. Se till att du noga övervakar dina dagliga mål och din förmåga att uppnå dem.

Var också noga med att inte komma in i det klassiska språket 'Velocity vs. Quality'. Eftersom när du rapporterar, säg 50 fel per dag, kan det verka som om du är superproduktiv. Men om de flesta av dem kommer tillbaka som ogiltiga, har du fått dig själv ett problem.

Så övervaka, övervaka och övervaka lite mer :)

Slutsats:

Slutligen, trots alla försiktighetsåtgärder och åtgärder om du fortfarande befinner dig knäckt i tiden, fråga hjälp .

De flesta lag är villiga att delta i en krigsrumssession för att få saker tillbaka på rätt spår.

Om författaren: Dessa användbara testtips tillhandahålls av STH-teammedlem Swati S.

Vilka är dina knep för att hålla dig i tid och leverera en kvalitetstjänst? Vilka punkter i ovanstående artikel kommer också ihop med dig?

Vi uppskattar din feedback och värnar om din läsarkrets. Tack för att du läste!

=> Besök här för en komplett testplan-handledningsserie

Rekommenderad läsning

^