Meny

Hva er Longevity Testing? Hvordan fange feil før kunden finner det

what is longevity testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne artikkelen forklarer betydningen av “ Lang levetidstesting ”Og hvordan det hjelper å vurdere stabiliteten til systemet eller produktet og redusere de manglene som er funnet av kunden, dvs. ' Fang feilene internt før kunden finner den ”.

Mot slutten av denne artikkelen vil QA Managers, Leads and Testers ha god kunnskap om:

  • Hva er Longevity Testing?
  • Hvorfor kreves det lang levetidstesting?
  • Planlegging og gjennomføring av levetidstester
  • Hva er fordeler og ulemper ved lang levetidstesting?

Lang levetidstesting

.net intervju spørsmål og svar for erfarne

Hva du vil lære:

Hva er Longevity Testing?

Longevity Testing er en testaktivitet:

  • For å validere system- eller produktstabilitet og brukervennlighet over lengre tid mot passende belastning og belastning med sanntidstrafikk og applikasjoner
  • For å redusere forekomsten av mangler som dukker opp på kundens nettsted

Flytskjema for håndtering av kunderapporterte problemer (fig. 1)

Hva er Longevity Testing

Bakgrunn for lang levetidstesting

#1) Vanligvis, i løpet av de første ukene av distribusjonen av produktet eller etter en oppgradering til den siste programvareutgivelsen på kundesiden, går alt bra. Men over en periode på noen uker begynner en kunde å rapportere problemene.

#to) Mange av problemene kan være enkle funksjoner ettersom de rapporteres av kunden og ikke er enkle å reprodusere internt. De trenger mye tid og nøye analyser av Expert Team over hele spekteret. Tips: Tid = $$$ !!!

# 3) Ett eller flere av følgende skjer når kunder (e) finner feilen (fig. 1)

  • Alvorlighetsgraden av mangelen vil ha en direkte innvirkning på kundens virksomhet, dvs. $$$
  • Enhver serviceforespørsel til Technical Support Center koster $$$ for Product Engineering Organization
  • Sjelden problemer løst av kunden løses av front-end teknisk supportteam
  • Slike forespørsler eller billetter eskaleres til Escalation Support Team
  • Eskalering av kundebilletter koster mer $$$ for organisasjonen
  • Hvis opptrappingsgruppen ikke klarer å løse problemet, må det nå involvere ingeniørteamet (utvikling og kvalitetssikring)
  • Nå ville kostnaden $$$ for å løse problemet også ha økt betydelig
  • Jo lengre feiloppløsningen øker sannsynligheten for misfornøyde kunder som ikke vil gi gjentatte bestillinger, og det verste scenariet er når kunden bestemmer seg for å flytte til en konkurrent løsning på et passende tidspunkt. I begge tilfeller er det imidlertid et inntektstap for enhver Product Engineering Organization

4) Den høyere prosentandelen av slike problemer rapportert av en eller flere kunder er relatert til typisk system- eller produktstabilitet i kombinasjon med kundetopologi, infrastruktur, trafikk og applikasjonsspesifikk.

Hvorfor kreves det lang levetidstesting?

1) Enhver ‘Defekt’ som oppstår av Kunden som rapporterte problemet er vanligvis en Test Escape.

to) Eventuelle slike feil koster bunnlinjen $$$ for kunden så vel som ingeniørorganisasjonen som tilbyr løsninger og tjenester til kundene.

3) I et normalt scenario burde feilen ha blitt lagt merke til internt under forskjellige testsykluser, inkludert regresjonstesting av en eller flere testere fra testteamet, avhengig av kompleksiteten i problemet.

implementere binært søketre i java

4) Viktigst, slike feil som oppstår på grunn av kunderapporterte problemer, peker også på et passende testscenario eller at en testsak blir savnet på tidspunktet for gjennomføringen av testplanen.

5) Mange av testerne må ha opplevd at en bestemt funksjon mislykkes på kundesiden, men passerer internt i forskjellige testsenger som

  • Trekk
  • Regresjon
  • Laste
  • Understreke
  • Opptreden
  • System
  • Løsning
  • Alpha
  • Beta

6) Viktige observasjoner som skal vurderes -

  • Under en hvilken som helst programvareutgivelsessyklus, blir System Under Test (SUT) eller Device Under Test (DUT) i alle testsenger ofte myke eller harde omstart på grunn av ting som lasting av ny kodefall, feilbekreftelse etc.
  • Selv automatiserte regresjonstestpakker starter eller tilbakestiller vanligvis SUT- eller DUT-utførelse av et bestemt testcase-script eller en serie testcase-script
  • Så SUT eller DUT kjører ikke lenge nok uten en myk eller hard omstart
  • Mens situasjonen er en helt annen på kundesiden. Kunden har ikke råd til å fortsette å starte systemet ofte, noe som resulterer i produktivitetsforstyrrelser
  • Kunder følger en velprøvd praksis der de kunngjør et riktig vedlikeholdsvindu til den tiltenkte målgruppen og deretter utfører programvareoppgradering eller maskinvareutskifting etc.
  • Slike vedlikeholdsvinduer kan være i en bestemt periode fra kvartalsvis til årlig, avhengig av interne retningslinjer og prosedyrer for kundens organisasjon
  • I virkeligheten er det faktiske helsebildet av systemet eller produktet på kundens nettsted helt annerledes enn det for testsenger under en gitt programvareutgivelsessyklus i en hvilken som helst produktteknisk organisasjon.
  • Mange kunder ser også etter et autorisert kvalitetsdokument som har bestått bestemte vertikale modelltesting, spesielt økonomi-, helsetjenester- og føderale vertikaler

Tatt i betraktning få testhull som nevnt ovenfor =>

  • Det er åpenbart at systemet eller produktet skal gjennomgå lengre tester eller lang levetidstester med end-to-end-scenario som etterligner kundesiden eller vertikaler
  • Lengre varighet kan være 72-720 timer. (3-30 dager) eller passende varighet basert på EFD eller CFD data og spesifikke kundesaker
  • Det er en anbefalt praksis for QA Managers, Leads and Testers å utføre Longevity Testing som en egen aktivitet i en gitt programvareutgivelsessyklus.
  • Net-Net, Longevity Testing er veldig relevant for stabiliteten til systemet eller produktet, da det har direkte forhold til organisasjonens bunnlinje $$$

Planlegging og gjennomføring av levetidstester

Det er viktig at QA Managers, Leads og Testers inkluderer Longevity Testing som en del av deres generell teststrategi .

Planlegger

Planlegging og gjennomføring av levetidstester

  • Ingeniørorganisasjoner gjennomfører intern testanalyseanalyse ( TE ) trener fra tid til annen for mange produkter (maskinvare og programvare). Noen har til og med en integrert og automatisert mekanisme for å grave Test Escape-data vanligvis basert på ‘Eksternt funnet feil ( EFD ) ’Eller‘ Kundefeil ( CFD ) ’Logget av Support Escalation Team
  • EFD-er eller CFD-er bør analyseres nøye i sammenheng med kundens Live-distribusjon fra end-to-end perspektiv, ikke bare infrastrukturen, men også sluttbrukerenheter, applikasjoner, trafikkmønstre

Forstå kundevertikaler:

Kunder faller vanligvis inn i en av nedenstående bredere vertikaler:

  • Helsevesen
  • Detaljhandel
  • Finansiere
  • utdanning
  • Transport
  • Produksjon
  • Ingeniørfag
  • Føderal (stat)

Aktiviteter

#1) Utvikle en egen testplan og testtilfelle for levetidstesting. Dette vil også bidra til å spore testutførelsen, feillogging og verifisering

#to) Identifiser testsaker basert på Test Escape-analyseinnganger - vanligvis feilskrubb av EFD eller CFD

# 3) Det er veldig viktig at QA-teamet etterligner testbed av en eller flere vertikaler, avhengig av organisasjonens bransje med antall vertikaler

programvareingeniør i spørsmål om testintervju

# 4) Dedikert testseng (er) burde ha

  • Nettverkstopologi som ligner på en beregnet vertikal eller flere vertikaler
  • Infrastruktur med lignende brytere, rutere, back-end-servere, brannmurer osv
  • Ofte og mest brukte applikasjonsservere fra en gitt vertikal (er)
  • Ofte og mest populære sluttbrukerdadgets fra en gitt vertikal (er)

# 5) Egnede verktøy for å generere belastning, stress og sanntidstrafikk

# 6) Identifiser manuell kjøringsressurs

# 7) Identifiser ressurs / strategi for automatisering for raskere og gjentatt gjennomføring

# 8) Identifiser START og END for Longevity Testing for en gitt utgivelse

To tilnærminger for START og END av Longevity Testing:

I) Tilnærming 1:

  • Programvarekode eller maskinvare skal være i stabil tilstand
  • START på slutten av FEATURE Test Fullført
  • SLUT før kodefrysning

II) Tilnærming 2:

  • Ta en mindre hit ved å tillate litt ustabil kode
  • START ved 70% fullføring av FEATURE-testsyklusen
  • SLUT før kodefrysning

# 9) Feilbekreftelse for løste feil

# 10) Flytt levetidstesting til regresjon for påfølgende regresjonstesting

Henrettelse

  • Sett opp testbed (e) for å etterligne en eller flere kundevertikaler
  • Forsikre deg om at all back-end Infra, Application og Database inkludert smaker ligner på kundens
  • Forsikre deg om at sluttbrukerenheter ligner på brukerens bruk, er tilgjengelige og brukes under gjennomføring av testplan
  • Sørg for at passende verktøy er tilgjengelig for å generere moderat stress og belastning på systemet eller produktet
  • Utfør hele testpakken fra Longevity-testplanen uten myk eller hard omstart av SUT eller DUT, back-end-servere til andre Infra-relaterte enheter
  • Flere testkjøringer bør kjøres på ovennevnte måte for en definert nonstop-varighet fra spor 72-720 timer.
  • Registrer resultatene
  • Logg alle identifiserte feil
  • Bekreft alle feilene

Hva er fordeler og ulemper med lang levetidstesting?

Fordeler

  • Hjelper identifisere kritiske feil før kunden finner den
  • Hjelper med å stabilisere systemet eller produktet for dets brukbare funksjoner som er avgjørende for kundens produktivitet og virksomhet
  • Hjelper med å øke kundetilfredsheten
  • Sparer mange kostnader $$$ til organisasjonen - sparte penger er opptjente penger !!!
  • Testrapport for lang levetid kan også gjøres om til et kvalitetssertifiseringssikkert for ulike vertikaler

Ulemper

  • Startkostnad for å inkludere Longevity Testing og tilhørende aktiviteter som en del av en gitt frigjørings- og regresjonsaktiviteter
  • Ideelt egnet for Fossmodell
  • Agile / Scrum-modeller trenger tilpasning av varighet og dekning

Konklusjon

Mange av ‘Feilene’ som oppstår på grunn av problemer som kunden rapporterer, skyldes først og fremst Test Escape. Dette i sin tur ber om mange spørsmål som utvikling av testplan, gjennomgang, dekning og gjennomføring.

Eksternt funnet feil (EFD) eller CFD (Customer Found Defects) har en forretningseffekt ($$$) for kunden så vel som for produktorganisasjonen.

Longevity Testing er unik, og bør hjelpe enhver produktorganisasjon med å forbedre kundetilfredshet ved å identifisere og løse mangler før kunden får dem. Test av lang levetid bidrar også til å forbedre stabiliteten, noe som resulterer i robust kvalitetssystem eller produkt.

Om forfatteren: Denne artikkelen er skrevet av STH-forfatter Vinayak. Han har 12 års erfaring med kvalitetssikring / test i Fortune 500-selskaper.

Gi oss beskjed hvis du har spørsmål eller forslag til denne artikkelen.

Anbefalt lesing

^