Hvad er pilottest? Definition, betydning, eksempler

⚡ Smart opsummering

Pilottestning placerer et fungerende system foran en udvalgt gruppe af virkelige brugere under live-driftsforhold og verificerer gennemførlighed, omkostninger, risiko og ydeevne i vinduet mellem brugeraccepttest og fuld produktionsimplementering.

🎯 Position i cyklussen: Pilotprojektet kører efter brugeraccepttest og før systemet frigives til alle brugere.
👥 Deltagere: En lille, repræsentativ gruppe af ægte slutbrugere, ikke projektteamet, producerer den feedback, der betyder noget.
🧭 Fem trin: Planlæg, forbered, implementering og test, evaluer, og forbered derefter til produktionsimplementering.
🔀 Fem resultater: Vask fremad, rul tilbage, suspender, opdatering og fortsæt, eller implementering.
📊 Udgangskriterier: Aftal tærsklerne for defekter, ydeevne og tilfredshed, før pilotprojektet starter, aldrig efter dataene er ankommet.
⚖️ Ikke betatestning: Et pilotprojekt er kontrolleret, målt og internt for et valgt sted; betaversioner går til offentligheden.

Læs mere

Hvad er pilottest?

Pilot test defineres som en type softwaretest, der verificerer en komponent i systemet eller hele systemet under realtidsdriftsbetingelser. Formålet med pilottesten er at evaluere et projekts gennemførlighed, tid, omkostninger, risiko og ydeevne, før det frigives til alle.

Denne test udføres nøjagtigt mellem UAT og produktion.

I pilottestning afprøver en udvalgt gruppe slutbrugere systemet under test og giver feedback inden den fulde implementering af systemet. Med andre ord er det en generalprøve til den efterfølgende brugervenlighedstest, og det hjælper med tidlig opdagelse af fejl i systemet.

Diagrammet nedenfor viser denne ordning: den færdige build frigives til en begrænset pilotgruppe og overvåges der, mens den bredere brugerbase forbliver på det eksisterende system, indtil resultaterne foreligger.

Pilottest handler om at installere et system på et kundested (eller et brugersimuleret miljø) til test mod kontinuerlig og regelmæssig brug.

Den mest almindelige metode er at holde systemet i kontinuerlig brug for at finde dets svage områder. Disse svagheder sendes derefter tilbage til udviklingsteamet som fejlrapporter via den normale proces. proces til håndtering af fejl, og fejlene rettes i den næste systemversion.

Under denne proces er accepttest nogle gange også inkluderet som en del af Test af kompatibilitet. Dette sker, når et system udvikles til at erstatte et gammelt.

In Software EngineeringPilottestning besvarer også et kommercielt spørgsmål, nemlig om produktet eller tjenesten har et potentielt marked.

Hvorfor pilottest er vigtigt

En pilottest er den sidste mulighed for at lære noget billigt. Alt efter den er en produktionshændelse. Helt konkret leverer en pilottest følgende:

Fejlfinder softwaren og de procedurer, der bruges til at teste og understøtte den.
Bekræfter, om produktet reelt er klar til implementering i fuld skala.
Understøtter bedre beslutninger om tid, budget og ressourceallokering til udrulningen.
Måler målgruppens reaktion på produktet eller programmet.
Måler programmets succes i forhold til aftalte kriterier snarere end meninger.
Giver teamet en prøve på de aktiviteter, de vil bruge under brugervenlighedstesten.

Sådan laver du pilottest

Niveauet af pilottest afhænger af størrelsen og omfanget af dit migreringsprojekt. Selve pilottesten udføres i et dedikeret område eller laboratorium, hvor brugerne kører adskillige procedurer, transaktioner og rapporter, mens de simulerer softwarens funktionalitet.

Pilottestning kan udføres afhængigt af projektets kontekst:

For en generel virksomhed kan en pilottest udføres med en gruppe brugere på et sæt servere i et datacenter.
For en webudviklingsvirksomhed kan en pilottest udføres ved at hoste webstedsfiler på staging-servere eller mapper live på internettet.
For kommercielle softwareleverandører kan der udføres en pilottest med en særlig gruppe af tidlige brugere.

Uanset hvilken kontekst der gælder, følger pilottestning en skriftlig testplan, der er opbygget af fem trin.

Trin 1: Opret en pilotplan

Trin 2: Forbered dig til pilottesten

Trin 3: Implementer og test pilottesten

Trin 4: Evaluer pilottesten

Trin 5: Forberedelse til produktionsimplementering

Før en pilottest udføres, skal følgende ting overvejes:

Sørg for tilstrækkelig træning til deltagerne.
En udrulningsplan for implementering af serverne og klargøring af systemer til pilotprojektet.
Dokumentation af installationsprocessen.
Testscripts for hver softwareapplikation. Det består af tjeklister over funktioner, der skal udføres.
Giv design- og testteams konstant feedback fra brugerne via e-mails eller hjemmesider.
Indstil evalueringskriterierne for piloten, såsom oplysninger om antallet af brugere, der var utilfredse, antallet af supportopkald og -anmodninger osv.
Inddrag en arbejdsgruppe af lokalsamfundspartnere eller interessenter, der har investeret i dit projekt, og som vil mødes regelmæssigt for at drøfte dine fremskridt.
Udvikl en evalueringsplan og evalueringsinstrumenter eller -værktøjer til at indsamle de nødvendige oplysninger om viden, ændringer i holdninger og adfærd i pilotgruppen.

Under pilottesten indsamler og evaluerer teamet testdata. Baseret på disse data vælger teamet en af følgende strategier.

Skub fremad – Implementer en ny releasekandidat i pilotgruppen.
Rul tilbage – Udfør rollback-planen for at gendanne pilotgruppen til dens tidligere konfigurationstilstand.
Suspender – Suspendér pilottestning.
Patch og fortsæt – Implementer patches for at rette den eksisterende løsning.
Implementer – Fortsæt med en implementering af løsningen.

Tilbagerulningsmuligheden er grunden til, at et pilotprojekt overhovedet er værd at køre, så gendannelsesstien skal øves på samme måde som gendannelsestest øver håndtering af fejl i stedet for at blive skrevet ned og antaget at virke.

Indgangs- og udgangskriterier for pilottestning

Et pilotprojekt uden aftalte kriterier udvikler sig til en diskussion om meninger, når feedbacken modtages. Begge sæt kriterier godkendes, før den første bruger logger ind.

Adgangskriterier – pilotprojektet kan starte, når:

Brugeraccepttestningen er fuldført, og ingen åbne defekter har en alvorlighedsgrad, der blokerer det daglige arbejde.
Pilotmiljøet afspejler produktionen i konfiguration, datamængde og integrationer.
Pilotgruppen er blevet udvalgt, trænet og har fået besked om formålet og varigheden af øvelsen.
Der findes en testet rollback-plan og en supportkontakt i pilotperioden.

Afslutningskriterier – pilotprojektet afsluttes, når de aftalte målinger er tilgængelige, typisk:

Fejl tælles efter alvorlighedsgrad, med den tærskel, over hvilken udrulningen udskydes.
Opgavefuldførelse og fejlrater for de forretningsprocesser, som systemet understøtter.
Ydeevne målt i forhold til basislinjen for det system, der udskiftes.
Supportbelastning, såsom antallet af opkald eller supportsager, der rejses pr. bruger pr. uge.
Brugertilfredshed indsamlet gennem en struktureret undersøgelse i stedet for uformelle kommentarer.

Disse målinger danner grundlag for en enkelt beslutning om at gå eller ikke gå, og de samme tal danner normalt grundlag for den bredere risikobaseret testning vurdering, der afgør, hvor meget ekstra dækning udgivelsen har brug for før generel tilgængelighed.

Pilottest vs. Betatest

De to aktiviteter forveksles ofte, fordi begge stiller ufærdig software til rådighed for brugerne. Forskellen er kontrol: et pilotprojekt er en målt prøveperiode inden for en defineret gruppe, mens en betaversion er en åben udgivelse, der indsamler feedback fra mængden.

Aspect	Pilottest	Betatestning
Publikum	En udvalgt, repræsentativ gruppe på et kendt sted	Ethvert medlem af offentligheden, der vælger at deltage
Miljø	Produktionslignende miljø styret af teamet	Brugerens egne enheder og netværk
Timing	Efter brugeraccepttest, før udrulning	Efter pilotafsnittet, tættere på den generelle udgivelse
Formål	Bevis gennemførlighed, omkostninger, risiko og implementeringsberedskab	Indsaml bred feedback og afdæk sjældne miljøproblemer
Mål	Formelle ind- og udgangskriterier med aftalte målinger	Rapporterede problemer og brugstelemetri
Tilbagerulning	Planlagt og øvet til pilotgruppen	Brugere afinstallerer eller fortryder selv

Pilottestning er lige så forskellig fra test af brugeraccept, som spørger, om systemet opfylder de aftalte krav, og ud fra alfa test, hvilket sker internt, før nogen kunde ser byggeriet.

Fordele og ulemper ved pilottestning

Afvejningen er ligetil: en pilot køber bevismateriale, og den betaler for det bevismateriale med tidsplan og koordineringsindsats.

Fordele	Ulemper
Afdækker defekter under reelle brugsmønstre, som et laboratorium ikke kan reproducere	Tilføjer en fase til tidsplanen mellem UAT og udgivelse
Validerer installationstrin, træningsmateriale og supportprocedurer	Kræver et produktionslignende miljø og dedikeret supportdækning
Producerer målt evidens for beslutningen om at gå eller ikke gå	Resultaterne er kun så repræsentative som den valgte pilotgruppe
Begrænser eksplosionsradiusen for en fejl til én gruppe i stedet for hver bruger	En kort pilot kan gå glip af månedsafslutning, spidsbelastning og sæsonbestemt adfærd
Opbygger interessenternes tillid inden den bredere udrulning	Deltagerne kan tøve med at rapportere problemer i deres eget live-arbejde

Begge kolonner argumenterer for at behandle pilotprojektet som en planlagt fase inden for livscyklus for softwaretest med sin egen plan og ejer, snarere end som en uformel blødningsperiode tilføjet til slutningen af system test.

God praksis for pilottestning

Planlæg pilottesten to dage før usability-testen.
Start ikke pilottesten, før alle brugere, kunder og projektteamet er enige om kriterierne for et vellykket resultat.
Bed brugerne om at markere eventuelle problemer på deres kopier af materialer, beskrive deres bekymringer og komme med forslag (hvis de har nogen) til forbedringer.
Informer brugerne om pilotprojektets formål, varighed og fremskridt.
Vælg deltagere, der afspejler den reelle brugerpopulation, inklusive de mindre selvsikre, fordi en gruppe entusiaster rapporterer et flatterende resultat.
Hold en samlet log over problemer, feedback og beslutninger, så exit-gennemgangen fungerer ud fra én registrering.

To yderligere fremgangsmåder kommer fra selve miljøet. Dæk pilotgruppens enheds-, browser- og operativsystemspredning så omhyggeligt som muligt. konfigurationstest ville, og bekræfte at daglige operationer såsom backup, overvågning og batchjob fungerer korrekt, hvilket er det grundlag, der er dækket af operationel accepttest.

Eksempel på pilottest

Følgende er nogle almindelige eksempler på pilottest:

Microsoft kører Windows Insiderprogram, udgiver pre-release Windows builds til frivillige kanaler, før disse builds bliver generelt tilgængelige.
Google kører Android Beta-program, som tilmelder understøttede Pixel-enheder til prøveversioner af pre-release Android bygger forud for den offentlige udgivelse.
HP kører online pilotprogrammer for sine produkter og tjenester.

Hvert eksempel deler den samme form: en begrænset, selvvalgt population kører det virkelige produkt, telemetri og feedbackflow tilbage til leverandøren, og den bredere udgivelse venter på disse beviser. Hvor teknikken placerer sig blandt de andre tilgængelige tilgange er beskrevet i typer af softwaretestning.

Ofte Stillede Spørgsmål

Stor nok til at omfatte alle roller, lokationer og enhedsprofiler, der er vigtige, og lille nok til at understøtte ordentligt. Repræsentativitet overgår antallet af medarbejdere: tyve brugere, der dækker alle arbejdsgange, er mere nyttige end to hundrede fra én afdeling.

Lang nok til at dække mindst én fuld konjunkturcyklus for den pågældende proces. Et lønsystem har brug for en lønkørsel, et detailsystem har brug for en spidsbelastningsdag. Alt kortere måler nyhedsværdi snarere end normal brug.

Nej. Accepttestning spørger, om systemet opfylder de aftalte krav, normalt gennem scriptede scenarier. En pilottest spørger, om det overlever daglig uscriptet brug på et rigtigt sted, og den kører, efter accepten er blevet underskrevet.

Den bør bruge produktionsrealistiske data i både volumen og form, fordi ydeevnefejl skjuler sig i skala. Hvor dataene er personlige eller regulerede, bevarer en maskeret kopi volumen uden at eksponere kundedata under prøveperioden.

Erhvervsbrugere, der skal betjene systemet dagligt, en kontaktperson i supportafdelingen, en infrastrukturejer for miljøet og en sponsor, der kan godkende beslutningen om at gå eller ikke gå. Trænere deltager, hvor udrulningen omfatter nye procedurer.

Når ændringen er lille og reversibel, når ingen gruppe kan isoleres uden at forstyrre forretningen, eller når et realistisk miljø ikke kan skabes. I disse tilfælde giver en gradvis udrulning med hurtig tilbagerulning normalt bedre værdi.

Maskinlæring grupperer fritekstkommentarer og supportsager i temaer, markerer ændringer i holdninger i løbet af pilotperioden og korrelerer telemetri med rapporterede problemer. Det afdækker hurtigt mønstre, selvom vurderingen af, om man skal gå eller ikke, forbliver hos sponsoren.

Ja, for de mekaniske dele — stilladsering af feedbackformularer, overvågningsforespørgsler, rollback-scripts og udkast til tjeklister fra eksisterende scenarier. Pilotprojektets omfang, deltagerudvælgelse og exit-tærskler er forretningsbeslutninger, som ingen assistent bør træffe.