Livet som ytelsestester

I forbindelse med softwareutvikling er det mange ulike aktører som bidrar til det fullstendige produktet. Utviklere, prosjektledere, testere, tekniske og funksjonelle arkitekter er bare noen av de som på hver sin måte setter sitt preg på produktet og arbeidet generelt. Som alt annet i verden defineres ulike sterotyper til hver av disse rollene; Utvikleren er datanerden med korte sosial antenner. Prosjektlederen er den strenge mammafiguren som passer på at «barna» ikke gjør noe ugang. Mens testeren er en sur gammel mann som ikke kan brukes til annet enn å trykke seg rundt i skjermbildene til produktet. Disse stereotypene er selvsagt langt fra sannheten, og jeg skal i dette bloginnlegget prøve å rette søkelyset på testeren, nærmere bestemt Ytelsestesteren, og hva han gjør til daglig. Fokuset vil være på hvordan jeg har opplevd tiden fra jeg begynte med ytelsestesting i starten av oktober 2011 frem til nå.

Det hele startet våren 2011 da jeg kom fersk ut av skolen med en teknisk utdannelse. Jeg så på meg selv som en potet, en som stort sett kunne anvendes overalt. Jeg fikk i studietiden øynene opp for testing, men selv om jeg aldri helt klarte å fokusere noe særlig på det ved siden av studiene, lå det hele tiden i bakhodet. Jobb var sikret i Visma Consulting (da Visma Sirius) og jeg var bestemt på at jeg ville jobbe med utvikling og testing. Jeg fikk fort anbefalt å se nærmere på ytelsestesting, en disiplin som inneholdt testing med et teknisk perspektiv. Jeg så på dette som en stor mulighet til å kunne utvikle meg og takket derfor ja til å prøve dette.

Jeg ble i oktober satt ut i et vedlikeholdsprosjekt hvor vi som leverandør leverer ett produkt som brukes av opp til åtte tusen aktive og inaktive personer samtidig. Disse personene bistår «mannen i gata» hver eneste dag og det er derfor essensielt at systemet responderer på en tilfredstillende måte. Typiske kvalitetsaspekter vi ser på er responstider, stabilitet, skallerbarhet, knekkpunkt, ressursbruk og  at funksjoner som introduseres ikke reduserer ytelsen i systemet. Før en levering til produksjon er nettopp vi, ytelsestesteren, et hinder produktet skal forbi. Hvis vi sier ytelsen er god nok vil mest sannsynlig produktet slippes videre til produksjon, gitt at kunden akseptansetest går bra. Hvis produktet dermed viser dårlig ytelse i bruk, står ansvaret på oss. Dette er et ganske stort ansvar og skyld å ta når det er innblandet mye penger, personer og prestisje.

For å unngå at slike ting skjer jobber vi derfor tett med utviklerne og holder kontakten med arkitektene av de forskjellige løsningene. Kundekontakt er også svært viktig, og vi har jevnlige statusmøter for å forsikre at vi har alt vi trenger. Når tiden strekker mot systemtest får vi ofte beskjed om å gjøre en ytelsestest. Som regel innebærer dette å kjøre en responstidstest, som har til hensikt å teste responstider i systemet, og en stabilitetstest, som har til hensikt å se hvordan systemet oppfører seg over tid. Noen ganger setter vi i gang andre typer tester også, men fremgangsmåten er som regel nesten den samme. Vi arbeider derfor etter følgende overordnede faser: Planlegging, Verfisering, Eksekvering og Rapportering.

I planleggingsfasen er vi analytiske og finner de ulike testobjektene våre. Det utarbeides en testplan hvor vi spesifiserer hvilket miljøer som må tilgjengeliggjøres, hva som skal testes og gjennomføring. Det er også her vi finner ut om vi trenger nye/oppdaterte testskript til ytelsestesten. Verktøyet vi for øvring bruker for å generere last mot systemet er levert av HP, applikasjonen Load Runner (se illustrasjon under for enkel forklaring på hvordan det brukes i praksis).

 

I verifiseringsfasen verifiserer vi at alle testskript fungerer mot systemet og eventuelt fikser de hvis det er gjort endringer i systemet som må reflekteres her. Generering av testdata til test skjer også her. Generering av data gjøres basert på spørringer mot databaser, og disse er produsert gjennom mange år i forbindelse med prosjektet.

Selve eksekveringen består av å kjøre de testene som er spesfisert i planleggingen. I denne fasen gjøres det intensiv monitorering av ulike delsystemer og logging av data som brukes i forbindelse med rapportering.

I rapporteringsfasen går vi analytisk til verks for å tyde resultatene fra testene. Analysen er grunnlaget for rapporten som i bunn og grunn er produktet vi ytelsestestere leverer. Rapporten er en overordnet representasjon av datalogger fra testene detaljert med grafer, nøkkelord og nøkkeltall. Rapporten gir til slutt en anbefaling om hva som bør gjøres i forbindelse med leveransen. Enkelte ganger kan det være aktuelle tuning-tiltak, hvor vi som oftest får utviklere til å se om enkelte funksjoner kan kodes om slik at ytelsen øker, mens andre ganger kan alt være i orden. Det kan også hende vi anbefaler at leveransen bør utsettes til vi har fikset store svakheter som påvirker ytelsen negativt, men dette har foreløpig ikke skjedd.

Arbeidet vårt avsluttes som regel med en retest hvis det er nødvendig etter tuning, etterfulgt av en presentasjon av resultatene og anbefalinger for kunde. Kunde bestemmer seg så for om de er tilfreds med resultatene fra ytelsestestene og systemtestene generelt, gjør sin akseptansetest og gir klarsignal til å produksjonssette produktet.

Og sånn er livet til en ytelsestester, litt overordnet! 😀

Har du noen lignende erfaringer, historier eller spørsmål, ikke nøl med å kommentere!

Konsulent i Visma Consulting. Utdannet Sivilingeniør i datateknikk fra NTNU og jobber primært med ytelsestesting.
Kontakt Geir Ole: