Hva er alfatesting? Prosess, eksempel
⚡ Smart oppsummering
Alfatesting identifiserer feil i et programvareprodukt før det når virkelige brukere. Denne siden forklarer hvem som utfører de to fasene, testlaboratorieprosessen, start- og sluttkriterier, fordeler og begrensninger, og hvordan det skiller seg fra betatesting.
Hva er alfatesting?
Alpha Testing er en type programvaretesting som utføres for å identifisere feil før programvaren frigis til de virkelige brukerne eller offentligheten. Det er en type aksept testing. Hovedmålet med alfa-testing er å avgrense programvareproduktet ved å finne og fikse feilene som ikke ble oppdaget gjennom tidligere tester.
Denne testingen omtales som en alfatesting bare fordi den gjøres tidlig, nær slutten av utviklingen av programvaren og før Beta-testing. Sjekke Forskjeller mellom alfa-testing og beta-testing
Alfa-testing utføres vanligvis av interne programvareingeniører eller QA-ansatte. Det er den siste testfasen før programvaren slippes ut i den virkelige verden.
Fordi det drives internt, kommer personene som utfører det fra to forskjellige grupper.
Hvem er involvert i Alpha-testing?
Alfa-testing har to faser,
- Den første fasen av testingen utføres av interne utviklere. De bruker enten maskinvareassisterte feilsøkingsprogrammer eller feilsøkingsprogramvare. Målet er å fange feil raskt. Vanligvis vil en tester under alfatesting støte på mange feil, krasj, manglende funksjoner og dokumentasjon.
- Mens den andre fasen av alfa-testing gjøres av programvare QA-ansatte, for ytterligere testing i et miljø. Det involverer både svart boks og Hvit Box Testing.
Så alfa-testing kan ses for seg som en nettapplikasjon som ikke er helt klar for bruk, men som har blitt åpnet for å få noen innledende tilbakemeldinger.
Inngangs- og utgangskriterier for alfatesting
Alfatesting er en formell fase, ikke en åpen aktivitet. Å bli enige på forhånd om hva som må være sant før den starter, og hva som må være sant før den erklæres ferdig, forhindrer at fasen enten starter for tidlig eller varer i det uendelige.
Inngangskriterier er betingelsene som må være oppfylt før den første alfatesten kjøres.
- Krav og designspesifikasjoner gjennomgås og godkjennes.
- En omfattende testplan og testtilfeller skrives og godkjennes.
- Byggingen er funksjonskomplett for omfanget som testes, og røyktester består.
- Et dedikert testlaboratoriemiljø og testdata er tilgjengelige.
- En defekt tracKing-verktøyet er på plass, og teamet er trent på det.
Utgangskriterier er betingelsene som viser at fasen har oppnådd sitt formål.
- Alle planlagte testtilfeller er utført, og resultatene er registrert.
- Alle kritiske og svært alvorlige feil blir rettet og verifisert ved ny testing.
- Gjenværende defekter av lav alvorlighetsgrad dokumenteres og formelt aksepteres.
- Sammendragsrapporten for alfatesten er levert og godkjent.
- Produktet vurderes som stabilt nok til å eksponeres for eksterne betabrukere.
Når disse grensene er avtalt, kan den daglige prosessen beskrives.
Eksempel på alfatesting
Vanligvis foregår alfatesting i testlaboratoriemiljøet på et separat system. I denne teknikken samarbeider prosjektlederen med utvikleren for å definere spesifikke mål for alfatesting, og for å integrere resultatene i utviklende prosjektplaner.
Som sådan alfa-testing utføres på en prototype, kan dyptgående pålitelighetstesting, installasjonstesting og dokumentasjonstesting ignoreres.
En god alfatest må ha en veldefinert Testplan med omfattende testcases. Ulike aktiviteter involvert i alfa-testing er loggingsdefekter, fiksing av defekter, retesting, flere iterasjoner, etc.
Selv om alfatesting ikke er helt funksjonell, må kvalitetssikringsteamet sørge for at alt som er tilgjengelig testes grundig, spesielt de delene som må sendes til kunden.
For beste praksis bør QA-teamet tidlig samle inn all tilleggsinformasjon som tilbakemeldinger om brukervennlighet på en alfa-trinns lagringskode, utseende og følelse av programvaren, navigasjonsskjema osv.
Det anbefales også å sende en e-post til kunden med henvisning til alle detaljene om testen for å gjøre kunden oppmerksom på den nåværende tilstanden til programvaren.
Hvordan utføre alfatesting
For å utføre alfatesting effektivt for programvaretesting, vi må først gjennomgå designspesifikasjonen og funksjonskravene, deretter utvikle en omfattende testplan og testtilfeller, deretter utføre testplanen for å finne loggfeil og fikse disse feilene og til slutt teste på nytt når problemene er løst for jevn funksjon av programvare.
Alfatesting vs. Betatesting
Alfa- og betatesting er påfølgende stadier, ikke alternativer. Alfa kommer først og kjøres av folk i organisasjonen på en kontrollert versjon. Betatesting følger når produktet er stabilt nok til å overleve kontakt med virkelige brukere på deres egne maskiner. Å forvirre de to fører til at teamene eksponerer en ustabil versjon for kunder, eller utsetter ekstern tilbakemelding til det er for sent å handle på den.
| Forskjellens poeng | Alpha Testing | Betastesting |
|---|---|---|
| Fremført av | Interne utviklere og QA-personell | Ekte sluttbrukere og kunder |
| Vårt kontor: | Et kontrollert testlaboratorium på utviklerens nettsted | Brukerens eget miljø |
| Teknikker | Både svartboks- og hvitboks-testing | Kun testing av svarte bokser |
| Bygg modenhet | En prototype eller komplett funksjonsbygging | En kandidat som snart er løslatt |
| Defekter funnet | Funksjonsfeil, krasj, manglende funksjoner | Brukervennlighetsproblemer og virkelige kanttilfeller |
| Fiks behandlingstid | Feil blir rettet i løpet av fasen | De fleste rettelser er utsatt til en senere utgivelse |
Fordeler med alfatesting
- Bedre innsikt om programvarens pålitelighet i de tidlige stadiene
- Frigjør teamet ditt for andre prosjekter
- Reduser leveringstiden til markedet
- Tidlig tilbakemelding bidrar til å forbedre programvarekvaliteten
Ulemper med alfatesting
Den samme interne innstillingen som gjør alfatesting rask begrenser også hva den kan bevise.
- Ikke et ekte miljø: Testlaboratoriet matcher sjelden utvalget av enheter, nettverk og konfigurasjoner som kundene bruker, så miljøspesifikke feil overlever fasen.
- Intern skjevhet: Testere som vet hvordan produktet er ment å brukes, unngår de uventede veiene som virkelige brukere tar, noe som skjuler brukervennlighetsproblemer.
- Begrenset dybde på en prototype: Dyptgående testing av pålitelighet, installasjon og dokumentasjon hoppes ofte over, så disse risikoene forblir åpne.
- Kostnad for et dedikert laboratorium: Å opprettholde et separat miljø og bemanne to testfaser øker kostnadene som små team kan ha problemer med å rettferdiggjøre.
- Planleggingstrykk: Fordi alfa-versjonen skjer rett før utgivelse, vil eventuelle forsinkelser tidligere i prosjektet ofte komprimere denne fasen først.

