Innehåll
- Demo And Die!
- Gå in i användarens skor
- En kort UAT-historia
- UAT berättar hur användbart systemet är
- Vem kan utföra UAT?
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- Framgång och misslyckanden
- Fördelar med UAT
Källa: Lightcome / iStockphoto
Hämtmat:
När programvaran har genomgått enhets-, integrations- och systemtestning kan behovet av godkännandeprovning verkar överflödigt. Varför är test av användareaccept (UAT) fortfarande viktigt? Här kan du lära dig om fördelarna med UAT och varför det är unikt.
Demo And Die!
Har du någonsin levererat en kundpresentation eller utbildning, och något bryter halvvägs igenom? Eller har du någonsin gett någon en uppsättning instruktioner och insett att du missat något, eller så fungerade det inte som du hoppades? Under vart och ett av dessa fall antar du slutanvändarens perspektiv och arbetar med programvaran i den personan. Chansen är att du gjorde något annorlunda eftersom du tänkte som en användare snarare än som en utvecklare.
Gå in i användarens skor
Den unika vinkeln för användaracceptantestning (UAT) är att testa programvara som slutanvändare. Programvara är byggd för att ge användare konkreta resultat. Till exempel tillåter e-handelssajter kunder att köpa produkter. När en kund gör en beställning meddelar programvaran för e-handelssajter butiksadministratören, så att det valda objektet kan dras och packas för leverans. Det kan finnas olika typer av programvaruanvändare, så det här testningssteget gör det möjligt för utvecklingsgruppen att verifiera att slutanvändare uppnår förväntade mjukvaroresultat.
En kort UAT-historia
Innan internet började distribuerades mest mjukvara för en känd användare. Om ett företag utvecklade programvara för en kund, hade en tilldelad chef befogenhet att verifiera att programvaran uppfyllde avtalsvillkoren. Detta var tänkt att representera en punkt där mjukvaran var "lämplig för syfte", som uppnåddes genom att välja slutanvändarrepresentanter för att utföra tester och ge en rapport med resultat. Eftersom användarna var en känd, sluten grupp, kunde var och en utbildas i användningen av programvaran, vanligtvis genom mycket detaljerade teststeg. Dagens motto var att mer detalj var bättre.
När allt mer mjukvara utvecklades för kunder på webben blev slutanvändarnas publik mer öppen. Det var inte längre möjligt att identifiera och utbilda alla troliga slutanvändare, så programvarudesignen måste innehålla en mycket större betoning på användbarhet och måste vara lättförståelig - även med minimal information. Så UAT var tvungen att ändra för att uppfylla dessa krav.
UAT berättar hur användbart systemet är
Så, inte bara berättar UAT om omfattningen av funktionalitet för en mjukvara, utan den berättar också hur användbar den är. De flesta UAT utförs bäst av individer som förstår den riktade slutanvändaren som kommer att uppleva programvaran med lite förkunskaper och kan ge en riktig indikation på programvarans användarvänlighet och vad som behöver förbättras.
Vem kan utföra UAT?
När utvecklare testar programvara kommer de ihåg detaljer om hur ett system skrivs. Denna kunskap kan påverka testning, och utvecklare kan vidta andra steg än slutanvändare, till exempel att utföra steg snabbare eller avföra fina detaljer som slutanvändare kan hitta förvirrande. Således är utvecklare inte de bästa UAT-kandidaterna. Så vem är det?
Många organisationer använder specifika testteam som inte är involverade i teknisk design och utveckling. Mindre organisationer tilldelar antingen tester till icke-utvecklingspersonal, som de som utför administrativa uppgifter, eller använder tjänster från ett externt företag. Vissa organisationer använder det som kallas "korridortestning", där de bokstavligen handplockar medarbetare som inte är aktivt anställda i projektet och ber dem prova systemet från slutanvändarnas perspektiv. Ett exempel skulle vara att beställa produkt online.
Efter interntestning kan pilot- eller betatestningssteg inträffa, varvid programvaran görs tillgänglig för små grupper av "riktiga" användare som är inbjudna att använda produkten gratis eller till en betydande rabatt, i gengäld för detaljerad återkoppling av användningen.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
Progressiva UAT-stadier med olika målgrupper ökar förtroendet för mjukvarans användbarhet. I kombination med faser av iterativ utveckling kan flera UAT-cykler utföras för att testa nya funktioner när de levereras, samtidigt som man kontrollerar tidigare funktioner.
Bra UAT-testare är nyfiken på att se vad som händer om de tar olika vägar till ett visst mål. När allt kommer omkring, alla närmar sig användningen av programvara på olika sätt, så om många möjligheter kan täckas av en liten grupp människor, är programvarans förtroende i driftsläge högre.
Framgång och misslyckanden
UAT-processer bör verifiera att varje typ av programvaruanvändare får de konkreta resultaten som krävs för både framgång och misslyckanden.
I ett framgångsflöde går en slutanvändare bort med ett förväntat resultat, till exempel att göra en produktorder. I ett felflöde stöder programvaran slutanvändaren genom någon form av felscenario, till exempel när en kund tillhandahåller ogiltig kreditkortsbetalningsinformation.
För att verifiera funktionaliteten måste viss information tillhandahållas testare. Annars vet de inte vad programvaran ska göra. Men för att testa användbarheten måste detta vara minimalt - bara en uppgift eller krav baserade, till exempel att köpa "x" (produkt) och betala "y" (med hjälp av kreditkortsuppgifter). Onus måste placeras på testare för att registrera observationer, framgångar och misslyckanden.
Fördelar med UAT
En viktig fördel med bra UAT är att det håller de pågående underhållskostnaderna så låga som möjligt. Det är billigare att fixa problem med funktionalitet och användbarhet tidigt. Det är mycket svårare att fixa ett fel när det finns mer kod runt det för regressionstest eller om den ursprungliga utvecklaren inte är tillgänglig.
UAT som utförs i flera steg och med olika typer av testgrupper ger optimala möjligheter att identifiera och reparera trasiga funktioner / användbarhetsproblem i de tidiga faserna av testen. Att hålla UAT-mål på uppgifts- och kravnivå gör det möjligt för testare att observera och märka mycket mer och till och med försöka steg utanför utvecklarens omfattning.
Återkoppling från UAT-cykler kan matas in i efterföljande iterationer av utveckling, öka programvarubarheten och användbarheten. Tidsbestämd, även betatestfaser kan komplettera marknadsförings- och försäljningsaktiviteter genom att ge referenser och feedback från fallstudier.