När jag skötte mjukvaruutveckling var ett av de mest förvirrade och minst effektiva områdena systemtestområdet som skapades så att utvecklare kunde testa sina applikationer.
I kampen för att möta snäva projektdeadlines fokuserade vi på att allokera QA-testresurser till applikationer, stadier och produktion. En lägre prioritet gavs åt att skapa en system “sandlåda” så att utvecklare kunde testa sina applikationer medan de skrev dem.
SER: Anställningssats: Python-utvecklare (TechRepublic Premium)
Resultatet blev ett växande antal bortkastade systemresurser som ingen tog bort efter att ha utfört enhetstester. Appar som tog längre tid att klara QA, och de kunde till och med misslyckas i produktionen – allt eftersom utvecklare i de tidiga stadierna av apputvecklingen tvingades testa sina appar mot föråldrad data.
För att vara ärlig så fanns det anledningar till att butikerna fungerade så här. Tanken i applikationsutvecklingsgruppen var att QA-teamets uppgift var att testa och fånga buggar i applikationer. Allt utvecklaren behövde göra var att se till att koden kompilerades och att applikationen fungerade. Dessutom var databasen och systemgrupperna alltid överfulla av arbete. Det var inte svårt för någon av dessa grupper att deprioritera uppdateringen av programsandlådedata.
Denna tankegång var och är fortfarande vanlig på många IT-avdelningar, men med dagens resurser behöver det inte vara det.
Hur du förbättrar ditt applikationstestsystem
Här är tre sätt som webbplatser kan använda för att förbättra sina testmiljöer för nya applikationer:
Använd mallsystemskript för distribution
Om en applikationsutvecklare behöver testa sin applikation på en specifik distribution och utgåva av Linux-operativsystemet måste han ha tillgång till ett vanligt OS-provisioneringsskript och måste endast göra mindre justeringar. Det finns ingen anledning att manuellt skriva ett skript för att tillhandahålla rätt operativ miljö för din applikation.
Måste läsa utvecklare täckning
Om vi fortsätter med Linux som ett exempel, finns det flera leverantörer av detta operativsystem som redan har automatiskt tillhandahållande av nya operativsystem för enhetstesteapplikationer. Att automatisera OS-provisionering eliminerar behovet för utvecklare att manuellt koda sina egna skript för att skapa test-OS-miljöer för sina applikationer. Det eliminerar också risken för mänskliga fel som kan introduceras när du skriver ett manus manuellt.
Automatisera resursallokering och frigöring
Ett andra hinder i applikationsenhetstestning är allokeringen av databaser och andra systembibliotek som måste laddas för att skapa en korrekt testmiljö för applikationen.
Applikationsutvecklare måste ofta vänta i en kö på att databasen och systemgrupperna ska vara tillgängliga för att ställa in dessa testregioner och resurser för dem.
För att lösa problemet finns det ett antal leverantörer som nu erbjuder peka-och-klicka-gränssnitt för utvecklare som låter dem välja den databas och systemresurser de behöver för sina testmiljöer för applikationsenheter. Detta peka-och-klicka urval av resurser tillåter utvecklare att konfigurera sina egna enhetstestmiljöer utan att behöva be databasen eller systemgrupperna om hjälp – och sparar tid och ansträngning för alla.
När en applikation är helt enhetstestad i utvecklingsbackend, finns det vanligtvis inget behov av att underhålla systemresurserna och lagringen som reserverades för enhetstestet. Tyvärr glömmer utvecklare oftast bort detta, så lagring och resurser står tomma.
SER: Anställningssats: Backend-utvecklare (TechRepublic Premium)
Denna förlust kan elimineras om databasen och/eller systemgruppen ställer in parametrar för att automatiskt ta bort testregioner. Till exempel kan ett meddelande skickas till utvecklaren som säger: “Efter nittio dagar kommer din testregion för applikationen xyz att avprovisioneras om ingen användning upptäcks.” Detta ger utvecklaren en varning.
Utför regelbunden uppdatering av testdata
Datauppdateringar utförs ofta sällan i applikationstestmiljöer. När data är inaktuella finns det en större risk att applikationer som testas mot den datan misslyckas med QA och till och med misslyckas i produktionen.
Databasgruppen bör ha ett regelbundet schema för att uppdatera testdata. Detta sparar alla tid under testning och QA och eliminerar möjligheten för ett betydande applikationsfel som kan uppstå i produktionen.
