Innholdsfortegnelse:
Demo And Die!
Har du noen gang levert en kundepresentasjon eller trening, og noe bryter halvveis gjennom? Eller har du noen gang gitt noen et sett med instruksjoner og innsett at du gikk glipp av noe, eller at det ikke fungerte helt som du håpet? I hvert av disse tilfellene tar du i bruk sluttbrukerens perspektiv og jobber med programvaren i den personen. Sjansen er at du gjorde noe annerledes fordi du tenkte som en bruker, snarere enn en utvikler.
Gå inn i brukerens sko
Den unike vinkelen ved bruk av akseptstesting (UAT) er å teste programvare som sluttbruker. Programvare er bygd for å gi brukere konkrete resultater. For eksempel tillater e-handelsnettsteder kunder å kjøpe produkter. Når en kunde legger inn en ordre, varsler e-handelsnettstedets programvare butikkadministratoren, slik at den valgte varen kan dras og pakkes for sending. Det kan være forskjellige typer programvarebrukere, så dette testfasen lar utviklingsgruppen bekrefte at sluttbrukere oppnår forventede programvareresultater.
En kort UAT-historie
Før bruk av internett ble mest programvare distribuert for et kjent brukerpublikum. Hvis et selskap utviklet programvare for en kunde, hadde en tildelt leder myndighet til å verifisere at programvaren oppfylte avtalevilkårene. Dette var ment å representere et punkt der programvaren var "fit for purpose", som ble oppnådd ved å velge sluttbrukerrepresentanter til å utføre testing og gi en rapport med resultater. Fordi brukerne var en kjent, lukket gruppe, kunne hver og en trent i bruk av programvaren, typisk gjennom veldig detaljerte testtrinn. Mottoet for dagen var at flere detaljer var bedre.
