Menu

Hvad skal jeg gøre, når der ikke er nok tid til at teste?

what do when there isn t enough time test

Prøv Vores Instrument Til At Fjerne Problemer

Delvis gennem din testcyklus, indser du ofte, at du ikke har tid nok til at teste? Du havde det hele under kontrol til at begynde med, men snart når du beredskabsplanens 'Hvad skal jeg gøre, når der ikke er tid nok til at teste?' afsnit.

Jeg har også været der, og det er ikke sjovt. :)

Jeg tænkte på det længe og hårdt. Hvordan kan noget, der startede så godt, gå så dårligt ned, så hurtigt. Og her er min analyse.

=> Klik her for en komplet testplan-tutorial-serie

Hvad du lærer:

Hvor gik min testtid hen?

Ikke nok tid til at teste

den bedste software til tekst til tale

For det første, hvorfor sker dette?Mange grunde - hvoraf nogle er:

# 1) Forkert estimering :

Hvis du startede med en unøjagtig forventning, vil tingene sandsynligvis mislykkes. Et godt testestimat skal tage følgende i betragtning:

  • Tid til forberedende opgaver - Vi taler om opgaver som:
    • Identificering og sammensætning af en regressionssuite
    • Oprettelse af testdata
    • Tid til at bestemme testberedskab (fx .: Røg / sundhedstest) osv.
  • Test sags vedligeholdelse : Testcases er langsigtede brugsaktiver. De er sikker på at gennemgå mindre opdateringer under udførelsen. Det anbefales, at der til nye produkter tildeles op til 30% af din testudførelsestid til disse mindre vedligeholdelsesopgaver. Alle teams og projekter har muligvis ikke brug for 30%, men afsætter lidt tid og kræfter til denne opgave.
  • Til dette / Sonderende test - Antallet af scriptede tests er en vigtig nævneren for testestimationsnumre. Imidlertid vil intet testteam i denne verden benægte at udforske din software, selvom modellen er dominerende scriptet.
  • Rapportering / kommunikation - Dette inkluderer triage / stand up-møder, opdatering af arbejdsstyringsværktøjer osv.
  • Beredskabsfaktor: Standarder anbefaler 25-30% buffer til dine oprindelige estimater. Men hold har sjældent råd til det. Selv da skal du forlade et lille åndedrætsrum, når det er muligt.
  • Team og dets evner: Hvis du har et nyt team, eller hvis de bruger et værktøj for første gang, skal du muligvis afsætte lidt tid til træning. Skræddersy dine skøn baseret på dit team, du arbejder med.

Anbefalet læsning=> Tjek dette for mere information om testestimerings succes og metoder

# 2) ustabile builds og andre tekniske problemer:

  • Fejl ved røg / sundhedstest : Når de grundlæggende tests på AUT mislykkes efter implementering i QA-miljø, er der stort set intet, som QA-teamet kan gøre mod testudførelse. Det er rigtigt, at vi kan arbejde på andre opgaver, mens dette sker, men det vil stadig ikke udfylde testcyklus tid. Så dette er en stor bidragyder til spildt tid.
  • Testdata utilgængelig : Produktionslignende data er et must for hvert testprojekt. Ikke at få dette ind i QA-miljøet til tiden er også en anden blokerende faktor. Nogle gange kan testere omgå dette ved oprette og administrere deres egne testdata , men det er tidskrævende og er måske ikke altid på stedet.
  • Miljøspørgsmål - Bygningen mislykkes implementeringer, serveren bliver ved med at blive timeout, mange flere sådanne problemer spiser din testcyklus. Dette stammer sandsynligvis fra det faktum, at nogle virksomheder (ikke alle) underminerer vigtigheden af ​​et godt, levende lignende miljø for effektiv kvalitetssikring. De prøver ofte at komme væk servere med lav kapacitet og make-do-opsætninger. Dette er virkelig en kortvarig løsning og gør ingen favoriserer. Faktisk kan det koste dem testkvaliteten og tab af værdifuld testtid.

# 3) Manglende aftale mellem alle involverede parter:

Dette kan være et sjældent problem med hold, der følger Agile eller Sikker på grund af de tætte kredse, de arbejder i, men mange hold lider stadig under uenighed eller fejlkommunikation om, hvornår Dev, Ops og QA formodes at modtage leverancer fra hinanden. Derfor forsinkelser.

For at forstå kommunikationsfinesser skal du kontrollere dette => Hvordan forretning, udvikling og kvalitetssikring kan arbejde sammen for at få projektet gennemført

Nu hvor vi kender problemerne, er der nogle måder at løse det på.

Hvordan kan testere få tid nok til at teste?

# 1) Anslå nøjagtigt. Hvis du er i tvivl, overvurderes det med en rimelig margin, men ikke undervurderes. Glem ikke at foretage skønjusteringer baseret på dit team, værktøjer og processer. Når du er færdig, skal du søge officiel afmelding, så alle er opmærksomme og holdes i løkken.

#to) Tag historiske data i betragtning - Test Management-værktøjet er din bedste ven .

  • Hvor lang tid tog de tidligere frigivelsestestcyklusser?
  • Hvilke slags problemer forårsagede afbrydelser i den forrige testcyklus?
  • Hvor mange kørsler tog de fleste testsager inden de bestod?
  • Hvilke mangler blev rapporteret?
  • Hvilke mangler fik testet til at blive afbrudt?

# 3) Stil disse spørgsmål og planlæg derefter i crunch-tid:

  • Find ud af Vigtig funktionalitet er dit projekt?
  • Find ud af højrisikomodul af projektet?
  • Hvilken funktionalitet er mest synlig for brugeren?
  • Hvilken funktionalitet har den største sikkerhedspåvirkning?
  • Hvilken funktionalitet har den største økonomiske indvirkning på brugerne?
  • Hvilke aspekter af applikationen er vigtigst for kunden?
  • Hvilke dele af koden er mest komplekse og dermed mest udsat for fejl?
  • Hvilke dele af applikationen blev udviklet i rush- eller paniktilstand?
  • Hvad synes udviklerne er de mest risikofyldte aspekter af applikationen?
  • Hvilke slags problemer ville forårsage den værste omtale?
  • Hvilke slags problemer ville forårsage de fleste kundeserviceklager?
  • Hvilke slags tests kan let dække flere funktioner?

I betragtning af disse punkter kan du i høj grad reducere risikoen for frigivelse af projekt under mindre tidsbegrænsning.

# 4) Brug et teststyringsværktøj. Dette reducerer tid og kræfter betydeligt forberedelse, rapportering og vedligeholdelse.

=> For listen over de mest populære valg af teststyringsværktøjer , tjek her :

# 5) Der er ikke meget, vi kan gøre ved forkerte builds / tekniske problemer, men den ene ting, der kan hjælpe, er at se på enhedens testresultater. Dette vil give os en idé om, hvorvidt bygningen var en succes eller ej, og hvilken type test der mislykkedes - så vi genopfinder ikke hjulet.

gratis tidssoftware til små virksomheder

Hvis din Test Management Tool understøtter CI-integration , har du disse oplysninger tilgængelige uden besvær, så du forstår applikationens stabilitet bedre.

# 6) Mål din produktivitet og fremskridt ofte . Lad ikke statusrapporter leveres kun til fordel for de eksterne teams. Sørg for, at du nøje overvåger dine daglige mål og din evne til at nå dem.

Sørg også for ikke at komme ind i den klassiske gåde 'Velocity vs. Quality'. Fordi når du rapporterer, siger 50 fejl om dagen, kan det se ud som om du er superproduktiv. Men hvis de fleste af dem kommer tilbage som ugyldige, har du fået dig selv et problem.

Så overvåg, overvåg og overvåg lidt mere :)

Konklusion:

Endelig, på trods af alle forholdsregler og foranstaltninger, hvis du stadig finder dig selv knust i tiden, spørg hjælp .

De fleste hold er villige til at deltage i en krigsrumssession for at få tingene tilbage på sporet.

Om forfatteren: Disse nyttige testtip leveres af STH-teammedlem Swati S.

Hvad er dine tricks nu for at holde dig til tiden og levere en kvalitetstjeneste? Hvilke punkter i ovenstående artikel genlyder også dig?

Vi sætter pris på din feedback og værner om din læserskare. Tak fordi du læste!

=> Besøg her for en komplet testplan-tutorial-serie

Anbefalet læsning

^