Testinnsikt 2022

Dataene er noe mangelfulle. Kun 60 respondenter oppgir minst ett verktøy som er i bruk. Av de som oppgir at integrasjonstest er automatisert, er det bare 2/3 som oppgir noe verktøy.

Tabellen viser de som oppgir minst ett verktøy fordelt på rolle. Det er klart at utviklerne har best oversikt over hvilke verktøy som er i bruk, på alle nivåer. Totalt sett har ca. 40% av respondentene oppgitt at en nivå er automatisert, men uten å vite hvilke verktøy som er i bruk.

Verktøy for enhetstest per plattform

Som forventet følger valg av verktøy for enhetstest skarpe skillelinjer mellom plattformer.

Men er det slik at noen plattformer bruker en større palett av verktøy enn andre? Grafen under viser fordelingen av relevante enhetstestverktøy per plattform. Både Java og JavaScript-miljøene ser ut til å ha en sterk preferanse, mens .Net ser ut til å fordele seg litt bredere. De andre språkene i undersøkelsen hadde ikke nok data til å trekke ut noe signifikant.

Bruk av generelle verktøy per plattform

Er det forskjell i verktøy-preferanser mellom plattformene? Grafen viser hyppighet av bruk av verktøy per plattform. Postman er mest brukt og mye brukt av alle miljøer. Cypress er også populært, i mye større grad enn konkurrenter som Selenium, Webdriver.io osv. SoapUI ser ut til å være overrepresentert i Java-miljøer, mens Python har størst innslag av egenutviklede testrammeverk.

Hvor oppdatert er prosjektene på verktøyfronten?

Er det mange som er låst fast i fortiden og bruker gamle verktøy av gammel vane? En opptelling av alle verktøy som er nevnt tyder ikke på det. Gamle travere som TestComplete og MicroFocus (HP) er nevnt henholdsvis 3 og 1 gang. Selenium, som er av de eldste verktøyene for nettleserautomatisering er nevnt bare en tredjedel så ofte som Cypress, et nyere alternativ.

Av de eldre verktøyene som er mye i bruk, peker SoapUI og Postman seg ut. Det har nok sammenheng med at det ikke er så mange gode alternativer dersom man trenger de spesielle egenskapene SoapUI tilbyr. Postman har etablert seg som et mye brukt fellesverktøy.

Samtidig er det få eller ingen som nevner verktøy som bruker maskinlæring eller lignende for å hjelpe testprosessen.

Hva vil folk lære mer om?

Topp 5 verktøy respondentene ønsker å lære mer om

1. Cypress
2. k6
3. Postman
4. Playwright
5. Selenium

Hypotesen er at antallet som har automatisering øker jo oftere man releaser ny programvare. Hvis vi deler datasettet i to ser vi følgende fordeling.

• 85% av de som har utrulling hver uke eller oftere har automatisering
• 60% av de som har utrulling hver andre uke eller sjeldnere har automatisering

Grafen “utrullingshyppighet” viser antall releaser og ja/nei om man har automatisering.
Så ja, det er en stigning i antallet som ikke har automatisering i relasjon til utrullingshyppighet, slik vi forventet. Men resultatet er egentlig bare utslagsgivende ved de ytterliggående alternativene flere ganger om dagen og sjeldnere.

Vi observerer at ved flere ganger om dagen har alle automatisering, heldigvis! Men at det allerede ved flere ganger i uka er noen som ikke har automatisering, kondolerer!

Ved en nærmere titt på datasettet ser det ut til å være en sammenheng mellom releasehyppighet og hvem som skriver de automatiserte testene for integrasjon. Som vi ser av grafen er enhetstest relativt likt mellom de to intervallene, det er i hovedsak utviklere som gjør den automatiseringen. Mens det for integrasjonstest og hver uke er en økning i at både tester og utvikler gjør testautomatiseringen. Fører hyppigere releaser til et tettere bånd mellom tester og utvikler?

Sulten på mer info om hvem som skriver testene, scroll videre.

Av de 123 besvarelsene, var det 26 som svarte at de ikke har noen form for testautomatisering. Grunnlaget for å vurdere om testautomatiseringen er høy gjøres da basert på de 97 som svarte «Ja»

I undersøkelsen ble du spurt om på hvilke testnivåer dere har testautomatisering. De tre testnivåene i undersøkelsen var

• Enhetstest
• Integrasjonstest / API
• Verdikjede / E2E

Du ble også spurt om å anslå hvor stor andel av regresjonstestene som var automatiserte. Her kunne du skyve måleren her fritt for å indikere den valgte summen. Summen kunne være mellom 0 og 100.

Opprinnelig tenkte vi oss å sette et krav til å akseptere hypotesen, nemlig at en høy grad betyr automatisering på tre nivåer og minst 70% automatiserte regresjonstester. Svarene her ga kun 18 av 97, altså er det lite som støtter påstånden.

Hvis vi senker kravet til at du har automatisering på minst to nivåer og har automatiserte minst 50% av regresjonstestene, får vi grafen under.

Vi ser at at

• Gruppen av de som har over 50% automatiserte regresjonstester er mye større blant de som har automatisering på minst to nivåer enn de som kun har det på ett nivå
• Men vi ser også at det i gruppen som har automatisering på minst to nivåer er de som har automatisert under halvparten av regresjonstestene som størst.

Tallene kan dermed ikke sies å støtte hypotesen. Men kan de si oss noe annet?

Hvis vi fokuserer på de som har automatisert med enn halvparten av regresjonstestene sine, ser vi at det å ha automatisering på alle tre testnivåene først skiller seg ut når vi kommer over en andel automatiserte regresjonstester på over 70%. Disse tallene må ses i lys av at antallet svar her er 28 av 97 totalt.

Det er vanskelig å konkludere noe bombesikkert her. Selv om tallene kan antyde at det er en sammenheng mellom å ha automatisering på flere nivåer og det å ha mange automatiserte regresjonstester – så kan vi ikke si at det er en årsakssammenheng ut fra disse tallene:

Er andelen automatiserte regresjonstester høy fordi man har tester på alle nivåer, eller er det slik at dere som har tester på alle nivåer også er mer tilbøyelige til å ha flere automatiserte regresjonstester?

Vi må ta forbehold at vi her måler antall regresjonstester, og det er sannsynlig at det i svarene skjuler seg flere andre typer automatiserte tester som dere ikke vil kalle regresjonstester. Disse testene kan da også være mange og ha stor testdekning, og vil da ikke måles slik undersøkelsen er satt opp.

Testinnsikt har et inntrykk av at vi testere har blitt mer tekniske de siste årene, at vi graver dypere i materien og at vi er mer involvert i det som skjer i kodebasen, ikke bare sluttresultatet. Vi har derfor utformet en hypotese rundt dette:
Vi er i ferd med å få et skifte i testingen, der testere skriver tester på lavere nivåer.

Så hvor vanlig er det egentlig at testere skriver tester på lavere nivåer, som enhetstester eller integrasjonstester. Og lager utviklere noen gang verdikjedetester? La tallene svare for oss.

Enhetstest

25% av de som svarer at enhetstester er automatisert oppgir at testere eller forretningsressurser er med på å skrive enhetstester. I 87,5% av disse tilfellene oppgis det at også utviklere skriver enhetstester. Hvorfor er ikke dette oppgitt til å være 100%? Ut ifra dataene er det sprikende årsaker til dette, som det er vanskelig å trekke noen konklusjon fra. Men det er visse elementer som tilsier at det fortsatt er testledere som ikke helt vet forskjellen mellom de ulike testnivåene.

Et interessant moment er at det er tre prosent som hevder de har automatiserte enhetstester som skrives av verken utviklere, testere eller forretningsressurser.

Vi ser en helt klar trend i at det stort sett er utviklere som står for enhetstestene, men at det faktisk er et gjeldende utvalg testere og forretningsressurser som bidrar på dette området.

Integrasjonstest

Når det gjelder integrasjonstester ser vi at ansvarsfordelingen er jevnere. De fleste som har svart på undersøkelsen hevder at integrasjonstester skrives av både utviklere og testere eller forretningsressurser. Henholdsvis 18 og 29% hevder de kun skrives av testere/forretningsressurser eller utviklere.

Her må vi ta et forbehold om at det kan være ulike tolkninger for hva en integrasjonstest er. Noen kan mene dette er systemintegrasjonstester der integrasjoner mellom ulike komponenter i et system testes. Andre kan mene at dette er komponenttester der integrasjoner for en enkelt komponents integrasjoner testes med mocker og stubber. Andre igjen, kan mene at begge deler går under denne kategorien. Det kan derfor hende svarfordelingen hadde sett annerledes ut om spørsmålet i undersøkelsen hadde vært mer spisset mot det ene eller det andre.

Verdikjedetest

For verdikjedetest ser vi at ansvarsfordelingen er snudd i forhold til enhetstest. Det er dog flere utviklere som skriver verdikjedetester enn det er testere som skriver enhetstester. Totalt ser vi at 92% svarer at testere i det minste er med på å skrive disse testene. Det er kun 8% som besvarer at det enten kun er utviklere som skriver verdikjedetester, eller at dette ikke er relevant for de.

Selv om det er en del testere som bidrar med å skrive tester på lavere nivåer er trenden helt klar. Det er stort sett utviklere som holder i disse testene. Ser man på nivåer lenger opp flyttes ansvarsområdet gradvis over på testere og forretningsressurser. Vi ser også fra dataene at ansvaret for integrasjonstester er fordelt jevnt mellom testere/forretningsressurser og utviklerne.

Uten noe historisk grunnlag må vi kunne si at hypotesen er tilbakebevist. Selv om testere er svært aktive i utvikling av integrasjonstester er enhetstester fortsatt utviklerens revir, og testerne holder fortsatt et grep rundt verdikjedetester. Men, for de prosjekter som faktisk har automatisert tester ser vi at testere nesten alltid er involvert på minst ett testnivå. Dette kan være et bevis på at det er en del testere som har teknisk kompetanse og som er i stand til å skrive automatiserte tester.

Når vi ser på fordelingen av automatiserte regresjonstester så ser vi at mengden automatiske regresjonstester er jevnt fordelt.

Det er kun 4 av de 125 som svarte på undersøkelsen som har sagt at de ikke ønsker mer testautomatisering. Det er ingen tydelig sammenheng i forhold mengde automatiserte regresjonstester og ønske om ikke å automatisere mer. 2 av disse 4 har automatisert va 50% av sine regresjonstester. En parallell vi ser er at de som har sagt at de ikke ønsker mer automatisering er på ledernivå (Testleder, leder (team/prosjekt/scrum master). Det er ingen respondenter i “tekniske” roller som har svart at de ikke ønsker mer testautomatisering.

Grunnen til at de ikke ønsker mer testautomatisering spriker fra at plattformen er gammel, det er for dyrt og ikke mulig, til at de føler det ikke er behov for mer på dette tidspunktet.

Hypotesen om at de som har 70% eller mer automatiserte regresjonstester ikke ønsker mer er helt feil. Alle som har over 70%, faktisk alle som har over 50% automatiserte regresjonstester, ønsker mer automatisering.

Blant de som besvarte undersøkelsen var rundt 40 prosent tilhørende to kategorier (49 av 123 besvarelser):

• Leder (team/prosjekt/scrum master)
• Testleder

Ser vi på svar som enten var «vet ikke» eller som var mangelfulle er det disse to rollekategoriene som dominerer.

• Testledere var flest av de som svarte «Vet ikke» på spørsmålet om hvilket programmeringsspråk som brukes i prosjektet. Av de 13 som svarte «vet ikke», var 10 testledere.
• Testledere og Leder-kategorien var også flest i besvarelsene som ikke hadde svart på spørsmål om testnivåer, verktøy og hvem som skriver de automatiserte testene. Av 12 tomme besvarelser var 8 fra testledere og ledere.

Tallene er selvfølgelig altfor lave til at vi kan konkludere noe om sammenhengene her. Funnet er likevel interessant å dvele ved.

Hvis det er slik at en forholdsvis stor mengde ledere og testledere ikke trenger, ønsker eller kan få tilgang til denne informasjonen om testautomatisering, så er dette noe som er verdt å undersøke mer.

Kan grunnene være oppgavefordelingen i teamene, en bevisst håndtering av testprosess/risiko og en delegering nedover?

Eller er det snakk om at automatisering blir for mye eller for teknisk for ledere og testledere å ta hensyn til gitt tid, ressurser, ansvar og kompetanse?

TestInnsikt er SOCOs nye plattform for detaljerte analyser av test. Les mer om bakgrunnen for testinnsikt!