Meny

Hva skal jeg gjøre når det ikke er nok tid til å teste?

what do when there isn t enough time test

Prøv Instrumentet Vårt For Å Eliminere Problemer

Delvis gjennom testsyklusen din, innser du ofte at du ikke har nok tid til å teste? Du hadde alt under kontroll, til å begynne med, men snart når du beredskapsplanens 'Hva skal jeg gjøre når det ikke er nok tid til å teste?' seksjon.

Jeg har vært der også, og det er ikke gøy. :)

Jeg tenkte lenge på dette. Hvordan kan noe som startet så bra, gå så dårlig, så raskt. Og her er analysen min.

=> Klikk her for fullstendig testplanopplæringsserie

Hva du vil lære:

Hvor gikk testtiden min?

Ikke nok tid til å teste

hva er en swf-fil?

For det første, hvorfor skjer dette?Mange grunner - hvorav noen er:

# 1) Feil estimering :

Hvis du startet med en unøyaktig forventning, vil ting sikkert mislykkes. Et godt testestimat må ta følgende i betraktning:

  • Tid for forberedende oppgaver - Vi snakker om oppgaver som:
    • Identifisere og sette sammen en regresjonspakke
    • Opprette testdata
    • Tid til å bestemme testberedskapen (for eksempel: røyk / sunnhetstest) osv.
  • Test saksvedlikehold : Testtilfeller er langsiktige bruksmidler. De vil helt sikkert gjennomgå mindre oppdateringer under utførelsen. Det anbefales at det tildeles opptil 30% av testutførelsestiden for disse nye produktene til disse mindre vedlikeholdsoppgavene. Alle lag og prosjekter trenger kanskje ikke 30%, men bruker litt tid og krefter på denne oppgaven.
  • Til dette / Utforskende testing - Antallet skriptede tester er en viktig nevner for tallene for estimering av test. Imidlertid vil ingen testteam i denne verden nekte å utforske programvaren din, selv om modellen er dominerende skriptet.
  • Rapportering / kommunikasjon - Dette inkluderer triage / stand up-møter, oppdatering av arbeidsstyringsverktøy etc.
  • Beredskapsfaktor: Standarder anbefaler 25-30% buffer til de opprinnelige estimatene. Men lag har sjelden råd til det. Selv da, la det være litt pusterom når det er mulig.
  • Team og dets evner: Hvis du har et nytt team eller hvis de bruker et verktøy for første gang, må du kanskje sette av litt tid til trening. Skreddersy estimatene dine basert på teamet du jobber med.

Anbefalt lesing=> Sjekk dette for mer informasjon om testestimeringssuksess og metoder

# 2) ustabile bygg og andre tekniske problemer:

  • Feil ved røyk / tilregnelighet : Når de grunnleggende testene på AUT mislykkes etter distribusjon i QA-miljø, er det stort sett ingenting som QA-teamet kan gjøre mot testutførelse. Det er sant at vi kan jobbe med andre oppgaver mens dette skjer, men det vil fortsatt ikke fylle opp testsyklus tid. Så dette er en viktig bidragsyter til bortkastet tid.
  • Testdata utilgjengelig : Produksjonslignende data er et must for hvert testprosjekt. Å ikke få dette inn i QA-miljøet i tide er også en annen blokkeringsfaktor. Noen ganger kan testere omgå dette ved lage og administrere egne testdata , men det er tidkrevende og kan ikke alltid være på stedet.
  • Miljøspørsmål - Bygningen mislykkes distribusjoner, serveren blir stadig tidsavbrutt, mange flere slike problemer spiser testsyklusen din. Dette skyldes sannsynligvis at noen selskaper (ikke alle) undergraver viktigheten av et godt, levende miljø for effektiv kvalitetssikring. De prøver ofte å få unna servere med lav kapasitet og oppsett for make-do. Dette er virkelig en kortvarig løsning og gjør ingen fordeler. Faktisk kan det koste dem kvaliteten på testing og tap av verdifull testtid.

# 3) Manglende avtale mellom alle involverte parter:

Dette kan være et sjeldent problem med lag som følger Agile eller Sikker på grunn av de nære sirkler de jobber i, men mange lag lider fortsatt av uenighet eller feilkommunikasjon om når Dev, Ops og QA skal motta leveranser fra hverandre. Derfor forsinkelser.

For å forstå kommunikasjonsfinesser, sjekk dette => Hvordan Business, Development og QA kan samarbeide for å få prosjektet gjennomført

Nå som vi kjenner problemene, er det noen måter å løse det på.

beste cpu og gpu temp monitor

Hvordan kan testere få nok tid til testing?

# 1) Beregn nøyaktig. Når du er i tvil, overestimerer du med en rimelig margin, men ikke undervurderer. Ikke glem å gjøre estimatjusteringer basert på teamet ditt, verktøy og prosesser. Når du er ferdig, må du søke offisiell avmelding slik at alle er klar over og blir holdt i løkken.

#to) Ta hensyn til historiske data - Test Management-verktøyet er din beste venn .

  • Hvor lang tid tok de tidligere utgivelsessyklusene?
  • Hva slags problemer forårsaket forstyrrelser i forrige testsyklus?
  • Hvor mange løp tok de fleste testsaker før de besto?
  • Hvilke mangler ble rapportert?
  • Hvilke mangler førte til at testingen ble avbrutt?

# 3) Still disse spørsmålene og planlegg deretter i crunch-tid:

  • Finn ut viktig funksjonalitet er prosjektet ditt?
  • Finn ut høyrisikomodulen for prosjektet?
  • Hvilken funksjonalitet er mest synlig for brukeren?
  • Hvilken funksjonalitet har størst sikkerhetspåvirkning?
  • Hvilken funksjonalitet har størst økonomisk innvirkning på brukerne?
  • Hvilke sider ved applikasjonen er viktigst for kunden?
  • Hvilke deler av koden er mest komplekse, og dermed mest utsatt for feil?
  • Hvilke deler av applikasjonen ble utviklet i rush- eller panikkmodus?
  • Hva tror utviklerne er de mest risikofylte aspektene ved applikasjonen?
  • Hva slags problemer vil føre til den verste publisiteten?
  • Hva slags problemer vil forårsake flest klager om kundeservice?
  • Hva slags tester kan lett dekke flere funksjoner?

Tatt i betraktning disse punktene, kan du i stor grad redusere risikoen for at prosjektet slipper under mindre tidsbegrensning.

# 4) Bruk et Test Management-verktøy. Dette vil redusere mengden forberedelse, rapportering og vedlikeholdstid og krefter.

=> For listen over de mest populære valgene for testhåndteringsverktøy , sjekk ut her :

# 5) Det er ikke mye vi kan gjøre med feil bygg / tekniske problemer, men den ene tingen som kan hjelpe er å se på enhetens testresultater. Dette vil gi oss en ide om byggingen var en suksess eller ikke, og hva slags tester mislyktes - så vi oppfinner ikke hjulet på nytt.

Hvis din Test Management Tool støtter CI-integrasjon , har du den informasjonen tilgjengelig uten oppstyr, slik at du forstår applikasjonens stabilitet bedre.

# 6) Mål produktiviteten og fremgangen din ofte . Ikke la statusrapporter leveres bare til fordel for de eksterne teamene. Sørg for at du følger nøye med på dine daglige mål og din evne til å oppnå dem.

Sørg også for ikke å komme inn i den klassiske forundringen 'Velocity vs. Quality'. Fordi når du rapporterer, si 50 feil per dag, kan det se ut som om du er superproduktiv. Men hvis de fleste av dem kommer tilbake som ugyldige, har du fått deg et problem.

Så overvåke, overvåke og overvåke litt mer :)

Konklusjon:

Til slutt, til tross for alle forholdsregler og tiltak hvis du fremdeles er knust i tid, be om hjelp .

De fleste lag er villige til å delta i en krigsromsøkt for å få ting tilbake på rett spor.

Om forfatteren: Disse nyttige testtipsene er levert av STH-teammedlem Swati S.

Hva er triksene dine for å holde deg i tide og levere en kvalitetstjeneste? Hvilke poeng i artikkelen ovenfor har også gjenklang hos deg?

Vi setter pris på tilbakemeldingene dine og verner om lesertallet ditt. Takk for at du leser!

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

^