Hva er pilottesting? Definisjon, betydning, eksempler

โšก Smart oppsummering

Pilottesting plasserer et fungerende system foran en utvalgt gruppe reelle brukere under live driftsforhold, og verifiserer gjennomfรธrbarhet, kostnader, risiko og ytelse i vinduet mellom brukeraksepttesting og full produksjonsdistribusjon.

  • ๐ŸŽฏ Posisjon i syklusen: Pilotprogrammet kjรธres etter brukeraksepttesting og fรธr systemet lanseres til alle brukere.
  • ๐Ÿ‘ฅ Deltakere: En liten, representativ gruppe av ekte sluttbrukere, ikke prosjektteamet, produserer tilbakemeldingene som betyr noe.
  • ๐Ÿงญ Fem trinn: Planlegg, forbered, distribuer og test, evaluer, og forbered deretter for produksjonsdistribusjon.
  • ๐Ÿ”€ Fem utfall: Stabl fremover, rulle tilbake, suspender, oppdater og fortsett, eller distribuer.
  • ๐Ÿ“Š Utgangskriterier: Bli enige om terskler for mangler, ytelse og tilfredshet fรธr pilotprosjektet starter, aldri etter at dataene har kommet.
  • ๐Ÿ‡ง๐Ÿ‡ท Ikke betatesting: En pilot er kontrollert, mรฅlt og intern for et valgt sted; betaversjoner gรฅr til offentligheten.

Pilottesting av lansering av et system til en valgt brukergruppe fรธr full produksjonsutrulling

Hva er pilottesting?

Pilottesting er definert som en type programvaretesting som verifiserer en komponent i systemet eller hele systemet under sanntidsdriftsforhold. Formรฅlet med pilottesten er รฅ evaluere gjennomfรธrbarheten, tiden, kostnadene, risikoen og ytelsen til et prosjekt fรธr det lanseres til alle.

Denne testingen gjรธres nรธyaktig mellom UAT og produksjon.

I pilottesting prรธver en utvalgt gruppe sluttbrukere systemet under testing og gir tilbakemelding fรธr full utrulling av systemet. Med andre ord er det en generalprรธve for den pรฅfรธlgende brukervennlighetstesten, og det bidrar til tidlig oppdagelse av feil i systemet.

Diagrammet nedenfor viser denne ordningen: den ferdige byggingen slippes til en begrenset pilotgruppe og overvรฅkes der, mens den bredere brukerbasen forblir pรฅ det eksisterende systemet inntil resultatene er klare.

Pilottesting av et nytt system med en begrenset brukergruppe fรธr full utrulling

Pilottesting er opptatt av รฅ installere et system pรฅ et kundested (eller et brukersimulert miljรธ) for testing mot kontinuerlig og regelmessig bruk.

Den vanligste metoden er รฅ holde systemet i kontinuerlig bruk for รฅ finne ut av dets svake omrรฅder. Disse svakhetene sendes deretter tilbake til utviklingsteamet som feilrapporter gjennom den vanlige prosessen. prosess for feilhรฅndtering, og feilene blir rettet i neste systemversjon.

I lรธpet av denne prosessen er noen ganger aksepttesting ogsรฅ inkludert som en del av Test av kompatibilitet. Dette skjer nรฅr et system utvikles for รฅ erstatte et gammelt.

In Engineering programvarePilottesting svarer ogsรฅ pรฅ et kommersielt spรธrsmรฅl, nemlig om produktet eller tjenesten har et potensielt marked.

Hvorfor pilottesting er viktig

En pilottest er den siste muligheten til รฅ lรฆre noe billig. Alt etter den er en produksjonshendelse. Mer spesifikt leverer en pilottest fรธlgende:

  • Feilsรธker programvaren og prosedyrene som brukes til รฅ teste og stรธtte den.
  • Bekrefter om produktet virkelig er klart for fullskala implementering.
  • Stรธtter bedre beslutninger om tid, budsjett og ressursallokering for utrullingen.
  • Mรฅler reaksjonen til mรฅlgruppen pรฅ produktet eller programmet.
  • Mรฅler programmets suksess mot avtalte kriterier snarere enn meninger.
  • Gir teamet en รธving pรฅ aktivitetene de skal bruke under brukervennlighetstesten.

Hvordan utfรธre pilottesting

Nivรฅet pรฅ pilottesting avhenger av stรธrrelsen og omfanget av migrasjonsprosjektet. Selve pilottestingen utfรธres i et dedikert omrรฅde eller laboratorium hvor brukere kjรธrer en rekke prosedyrer, transaksjoner og rapporter mens de simulerer programvarens funksjonalitet.

Pilottesting kan utfรธres avhengig av prosjektets kontekst:

  • For en generell bedrift kan en pilottest utfรธres med en gruppe brukere pรฅ et sett med servere i et datasenter.
  • For et webutviklingsselskap kan en pilottest utfรธres ved รฅ hoste nettstedfiler pรฅ staging-servere eller mapper live pรฅ internett.
  • For kommersielle programvareleverandรธrer kan en pilottest utfรธres med en spesiell gruppe tidlige brukere.

Uansett hvilken kontekst som gjelder, fรธlger pilottesting en skriftlig testplan bygget opp av fem trinn.

Trinn 1: Lag en pilotplan

Trinn 2: Forbered deg til pilottesten

Trinn 3: Implementer og test pilottesten

Trinn 4: Evaluer pilottesten

Trinn 5: Forbered deg pรฅ produksjonsdistribusjon

Fรธr man gjennomfรธrer en pilottesting, mรฅ fรธlgende ting vurderes:

  • Gi deltakerne tilstrekkelig opplรฆring.
  • En utrullingsplan for utrulling av serverne og klargjรธring av systemer for pilotprosjektet.
  • Dokumentasjon av installasjonsprosessen.
  • Testskript for hver programvareapplikasjon. Det bestรฅr av sjekklister over funksjoner som skal utfรธres.
  • Gi design- og testteamene kontinuerlig tilbakemelding fra brukere via e-post eller nettsteder.
  • Angi evalueringskriteriene for piloten, som informasjon om antall brukere som var misfornรธyde, antall stรธtteanrop og forespรธrsler osv.
  • Engasjer en arbeidsgruppe av partnere i lokalsamfunnet eller interessenter som har investert i prosjektet ditt, og som vil mรธtes regelmessig for รฅ diskutere fremdriften.
  • Utvikle en evalueringsplan og evalueringsinstrumenter eller -verktรธy for รฅ fange opp nรธdvendig informasjon om kunnskap, endringer i holdninger og atferd i pilotgruppen.

Under pilottesten samler og evaluerer teamet testdata. Basert pรฅ disse dataene vil teamet velge en av fรธlgende strategier.

  • Stagger fremover โ€“ Implementer en ny releasekandidat til pilotgruppen.
  • Rull tilbake โ€“ Utfรธr tilbakestillingsplanen for รฅ gjenopprette pilotgruppen til dens tidligere konfigurasjonstilstand.
  • suspendere โ€“ Stopp pilottestingen.
  • Patch og fortsett โ€“ Implementer oppdateringer for รฅ fikse den eksisterende lรธsningen.
  • Distribuer โ€“ Gรฅ videre til en utrulling av lรธsningen.

Tilbakerullingsalternativet er grunnen til at det i det hele tatt er verdt รฅ kjรธre en pilot, sรฅ gjenopprettingsstien mรฅ รธves inn pรฅ samme mรฅte som gjenopprettingstesting รธver pรฅ hรฅndtering av feil, i stedet for รฅ skrives ned og antas รฅ fungere.

Inngangs- og utgangskriterier for pilottesting

En pilot uten avtalte kriterier blir til en meningskrangling nรฅr tilbakemeldingene kommer inn. Begge kriteriesettene godkjennes fรธr den fรธrste brukeren logger seg inn.

Inngangskriterier โ€“ pilotprosjektet kan starte nรฅr:

  • Brukeraksepttestingen er fullfรธrt, og ingen รฅpne feil har en alvorlighetsgrad som blokkerer det daglige arbeidet.
  • Pilotmiljรธet speiler produksjonen nรฅr det gjelder konfigurasjon, datavolum og integrasjoner.
  • Pilotgruppen har blitt valgt ut, trent og fortalt formรฅlet med og varigheten av รธvelsen.
  • En testet tilbakerullingsplan og en supportkontakt finnes for pilotperioden.

Avslutningskriterier โ€“ pilotprosjektet avsluttes nรฅr de avtalte mรฅlingene er tilgjengelige, vanligvis:

  • Feil telles etter alvorlighetsgrad, med terskelen over hvilken utrullingen utsettes.
  • Oppgavefullfรธring og feilrater for forretningsprosessene systemet stรธtter.
  • Ytelse mรฅlt mot grunnlinjen til systemet som skal erstattes.
  • Stรธttebelastning, for eksempel antall anrop eller saker som genereres per bruker per uke.
  • Brukertilfredshet innhentet gjennom en strukturert undersรธkelse i stedet for uformelle kommentarer.

Disse mรฅlingene gir grunnlag for en enkelt beslutning om รฅ gรฅ eller ikke gรฅ, og de samme tallene gir vanligvis grunnlag for det bredere risikobasert testing vurdering som avgjรธr hvor mye ekstra dekning utgivelsen trenger fรธr generell tilgjengelighet.

Pilottesting kontra betatesting

De to aktivitetene blir ofte forvekslet fordi begge setter uferdig programvare foran brukerne. Forskjellen er kontroll: en pilot er en mรฅlt prรธveperiode innenfor en definert gruppe, mens en beta er en รฅpen utgivelse som samler inn tilbakemeldinger om volum.

Aspekt Pilottesting Betatesting
Publikum En utvalgt, representativ gruppe pรฅ et kjent sted Ethvert medlem av offentligheten som velger รฅ delta
Miljรธ Produksjonslignende miljรธ kontrollert av teamet Brukerens egne enheter og nettverk
timing Etter brukeraksepttesting, fรธr utrulling Etter piloten, nรฆrmere generell utgivelse
Formรฅl Bevis gjennomfรธrbarhet, kostnader, risiko og beredskap til utplassering Samle inn bred tilbakemelding og avdekk sjeldne miljรธproblemer
Mรฅling Formelle inn- og utgangskriterier med avtalte mรฅlinger Rapporterte problemer og brukstelemetri
Rollback Planlagt og รธvd inn for pilotgruppen Brukere avinstallerer eller tilbakestiller pรฅ egenhรฅnd

Pilottesting er like forskjellig fra brukeraksepttesting, som spรธr om systemet oppfyller de avtalte kravene, og fra alfatesting, som skjer internt fรธr noen kunde ser bygget.

Fordeler og ulemper med pilottesting

Avveiningen er enkel: en pilot kjรธper bevis, og betaler for disse bevisene med tidsplan og koordineringsinnsats.

Fordeler Ulemper
Avslรธrer feil under reelle bruksmรธnstre som et laboratorium ikke kan reprodusere Legger til en fase i tidsplanen mellom UAT og utgivelse
Validerer installasjonstrinn, opplรฆringsmateriell og stรธtteprosedyrer Krever et produksjonslignende miljรธ og dedikert supportdekning
Produserer mรฅlte bevis for beslutningen om รฅ gรฅ eller ikke gรฅ Resultatene er bare sรฅ representative som den valgte pilotgruppen
Begrenser eksplosjonsradiusen for en feil til รฉn gruppe i stedet for hver bruker En kort pilot kan gรฅ glipp av mรฅnedsslutt, toppbelastning og sesongmessig atferd
Bygger interessentenes tillit fรธr den bredere utrullingen Deltakerne kan nรธle med รฅ rapportere problemer i sitt eget live-arbeid

Begge kolonnene argumenterer for รฅ behandle piloten som en planlagt fase innenfor livssyklus for programvaretesting med sin egen plan og eier, snarere enn som en uformell blรธtleggingsperiode lagt til slutten av systemtesting.

God praksis for pilottesting

  • Planlegg pilottesten to dager fรธr brukstesten.
  • Ikke start pilottesten fรธr alle brukere, kunder og prosjektteamet er enige om kriteriene for et vellykket resultat.
  • Be brukere om รฅ merke eventuelle problemer pรฅ sine kopier av materiell, beskrive deres bekymringer og komme med forslag (hvis de har noen) for forbedringer.
  • Informer brukerne om formรฅlet, varigheten og fremdriften til pilotprosjektet.
  • Velg deltakere som gjenspeiler den faktiske brukerpopulasjonen, inkludert de mindre selvsikre, fordi en gruppe entusiaster rapporterer et flatterende resultat.
  • Fรธr รฉn logg over problemer, tilbakemeldinger og beslutninger, slik at sluttgjennomgangen fungerer fra รฉn post.

To ytterligere fremgangsmรฅter kommer fra selve miljรธet. Dekk enhets-, nettleser- og operativsystemspredningen til pilotgruppen sรฅ nรธye som mulig. konfigurasjonstesting ville, og bekrefte at daglige operasjoner som sikkerhetskopiering, overvรฅking og batchjobber fungerer som de skal, som er grunnlaget som dekkes av operasjonell aksepttesting.

Eksempel pรฅ pilottesting

Fรธlgende er noen vanlige eksempler pรฅ pilottesting:

  • Microsoft kjรธrer Windows Insiderprogram, slipper forhรฅndsutgivelse Windows byggeprosjekter til frivillige kanaler fรธr disse byggeprosjektene blir allment tilgjengelige.
  • Google kjรธrer Android Beta Program, som registrerer stรธttede Pixel-enheter til prรธveversjon av forhรฅndslansering Android bygger seg opp fรธr den offentlige utgivelsen.
  • HP kjรธrer nettbaserte pilotprogrammer for sine produkter og tjenester.

Hvert eksempel har samme form: en begrenset, selvvalgt populasjon kjรธrer det virkelige produktet, telemetri og tilbakemeldingsflyt tilbake til leverandรธren, og den bredere utgivelsen venter pรฅ disse bevisene. Hvor teknikken befinner seg blant de andre tilgjengelige tilnรฆrmingene er beskrevet i typer programvaretesting.

Spรธrsmรฅl og svar

Stor nok til รฅ inkludere alle roller, lokasjoner og enhetsprofiler som er viktige, og liten nok til รฅ stรธtte ordentlig. Representativitet overgรฅr antall ansatte: tjue brukere som dekker alle arbeidsflyter er mer nyttige enn to hundre fra รฉn avdeling.

Lang nok til รฅ dekke minst รฉn full forretningssyklus for den aktuelle prosessen. Et lรธnnssystem trenger en lรธnnsrunde, et detaljhandelssystem trenger en dag med hรธy handelsbelastning. Alt som er kortere, mรฅler nyhet snarere enn normal bruk.

Nei. Aksepttesting spรธr om systemet oppfyller de avtalte kravene, vanligvis gjennom skriptede scenarioer. En pilot spรธr om det overlever daglig uskriptet bruk pรฅ et ekte sted, og den kjรธrer etter at aksepten er signert.

Den bรธr bruke produksjonsrealistiske data i volum og form, fordi ytelsesfeil skjuler seg i skala. Der dataene er personlige eller regulerte, bevarer en maskert kopi volumet uten รฅ eksponere kundedata under prรธveperioden.

Forretningsbrukere som skal bruke systemet daglig, en kontaktperson for supportdesk, en infrastruktureier for miljรธet og en sponsor som kan godkjenne om systemet skal gรฅs eller ikke. Kursholdere blir med der utrullingen inkluderer nye prosedyrer.

Nรฅr endringen er liten og reversibel, nรฅr ingen gruppe kan isoleres uten รฅ forstyrre virksomheten, eller nรฅr et realistisk miljรธ ikke kan tilbys. I slike tilfeller gir en trinnvis utrulling med rask tilbakerulling vanligvis bedre verdi.

Maskinlรฆring grupperer fritekstkommentarer og stรธtteforespรธrsler i temaer, flagger sentimentendringer i lรธpet av pilotperioden og korrelerer telemetri med rapporterte problemer. Den avdekker mรธnstre raskt, men vurderingen av om man skal gรฅ eller ikke, forblir hos sponsoren.

Ja, for de mekaniske delene โ€“ stillasarbeid for tilbakemeldingsskjemaer, overvรฅkingsspรธrsmรฅl, tilbakerullingsskript og utkast til sjekklister fra eksisterende scenarier. Pilotomfanget, deltakerutvalget og terskler for utgang er forretningsavgjรธrelser som ingen assistent bรธr ta.

Oppsummer dette innlegget med: