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.

Les mer

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 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.