Användargränssnittstesting
Under de första åren av mjukvaruutveckling hade processen som jag skrev om i förra inlägget ofta räckt eftersom programmen alltid skrevs som kommandoradsprogram. Det är mycket lättare att automatisera testning av kommandoradsprogram jämfört med dagens avancerade användargränssnitt som dessutom är en större del av den kodbas som måste kvalitetssäkras jämfört med de enklar kommandoradsbaserade programmen som förr utvecklades.
I drygt 25 år har jag sett olika försök att bli av med den kostsamma , felbenägna, och tidsödande manuella testningen. Så länge jag kan minnas har idén varit att spela in från användaren och sedan spela upp den senare för att leta efter felaktigheter i produkten som introduceras när uppdateringar görs . Detta är naturligtvis mycket bekvämt eftersom det är lätt att spela in interaktion samtidigt som du testar, vill lära sig produkten, eller gör andra uppgifter med produkten.
Jag har märkt att det största problemet med denna strategi är att även mycket små ändringar i användargränssnittet ofta gör att testerna fallerar och det tar tid att rätta till dem, antingen genom att uppdatera redan inspelade testfall eller spela in dem på nytt. Tyvärr slutar det ofta med att du kastar bort dem och fortsätter med manuell testning då du kommer att få så många falsklarm samtidigt som testarna är upptagna med att uppdatera de automatiska testfallen i stället för att testa din produkt
Varför automatiska användarinteraktiontester misslyckas i många organisationer
Min erfarenhet är från företag som jag har arbetat på och från diskussioner med många kolleger genom åren om detta ämne . På ett företag var de bra på automatisk testning , både för lågnivåtestning och funktionell testning , men de gjorde manuell testning av användargränssnittet. De hade möjlighet att förbättra den manuella testningen eftersom verktyget man utvecklade kunde testa den utvecklade mjukvaran, oftast ett telekomsystem, genom att simulera olika scenarier genom att slumpmässigt skicka extern fördefinierade händelser till systemet.
Redan då insåg jag att det skulle vara möjligt att genomföra automatisk användargränssnittstester i en utvecklingsorganisation. Jag har försökt att övertyga olika organisationer att göra det, men de alltid misslyckas på en särskild organisationsfråga, de vill separera testorganisationen från utvecklingsorganisation. Genom att göra denna separation synkroniseras inte utvecklingen av testkoden med systemkoden.
Denna separation av testfallsutveckling från produktutveckling resulterar i att det verkar som att testfallen utvecklas parallellt med systemet , men när man integrerar testfallen med produktkoden börjar problemen. När systemkoden är integrerad är det första gången testarna kan använda de utvecklade gränssnitten och då, även om olika diskussioner har ägt rum, upptäcks missförstånden och det tar det tid för testarna att anpassa testfallen , ta bort buggar i testfallen etc , och när de verkligen är redo att testa systemet då har utvecklarna integrerat nya versioner av systemet, vilket medför att testarna hela tiden ligger steget efter. Även utvecklarna har infört felaktigheter som gör att alla tester inte kan köras, så kallade blockerande fel, vilket även det tar tid att rätta till och felaktig kod kommer in i systemet och man tvingas utveckla mot en instabil kodbas då annan funktionalitet i den nya kodbasen krävs av andra utvecklare. Att stanna på en gammal och stabil kodbas blir allt svårare ju längre tillbaka i tiden denna stabila kodbas finns.
Vad som behövs och vad Purple Scout har gjort i sin kvalitetssäkringsprocess, är att integrera testfallsutveckling som en del av produktutvecklingsprocessen. Det är ett team som utvecklar och levererar både systemetkod och testfallskod som en paket. Detta omfattar alltså även användargränssnittstestfallen. En ny funktion anses inte klar förrän testfallen passerar och testfallen har granskats i Gerrit tillsammans med systemkoden.
Resultatet är att användargränssnittestfallen kan vara en del av kvalitetskontrollen av varje ändring av systemet. Detta medför att granskarna av koden kan fokusera på att förbättra kvaliteten och säkerställa att implementeringen är korrekt, och låta verktyg göra det de är bäst på.
Jag anser att integrering av testfallsutveckling och verifiering av dem i utvecklingsteamet är nödvändigt för att få någon avkastning på investeringen av automatiska testfallsutveckling. Naturligtvis måste ett valideringsteam fortfarande köra testfall och valideringsteamet skall arbeta oberoende av produktutvecklingsteamet. Deras fokus är förstås att validera att kunden får vad kunden förväntar sig. Genom att automatisera de tråkiga uppgifter kan testarna fokusera på att förstå kundens behov och att använda systemet som det förväntas i produktionen när den släpps.
Fortsättning följer