Problemer med testautomatisering og moderne kvalitetssikring
Hva er noen vanlige problemer med testautomatisering i agile og DevOps?
Moderne programvareutvikling og QA fokuserer for mye på testautomatisering og ikke nok på utforskende testing.
Slipper vi programvare av bedre kvalitet med mer automatiserte tester? Jeg tror ikke!
Jeg kom nylig over et innlegg på et sosialt medienettverk som sa
Det jeg ser i de fleste test- og QA-hendelser i dag, er for det meste DevOps, kontinuerlig integrasjon og testautomatisering.
Selv om det hele er veldig hyggelig, ser jeg mange skitne testtilfeller blir automatisert.
Jeg ser få feil rapportert under integrasjonstester og funksjonstester, selv om de alle er automatiserte.
I UAT finner brukerne flere og flere feil fordi testteamene ikke identifiserer dem i tidligere faser.
Hvis vi ikke lærer folk å skrive gode testsaker, vil vi ende opp med helautomatiske ...
Og min tolkning av ... er 'dritt'. :-)
Uansett, la oss se hva er virkelig skjer i verden av moderne QA og testautomatisering.
Problemer med moderne QA
Det meste av 'Testautomatisering' i den smidige utviklingen er i en alvorlig tilstand. Programvareindustrien setter inn enorme summer for å ansette 'Test Automation Experts' for å få en følelse av tillit til at programvaren de bygger er av høy kvalitet. Likevel blir merkbare feil og / eller andre problemer funnet under UAT eller glir gjennom i produksjonsmiljøer. Så hva skjer?
Merk:Av Test Automation refererer jeg mest til LØK Test automatisering.Automatisert testing er nå kjernen i enhver moderne programvareutviklingsprosess. Hensikten er å hjelp levere programvare av høy kvalitet på repeterbar basis, men er det virkelig?
Tester testere fremdeles?
Sannheten i saken er at i de fleste smidige team tester ikke testere lenger.
Manuell testing har mistet dyden, takket være utviklingspraksis og kulturer som smidig og DevOps , som har skapt et skille i QA-rommet - de som kan kode og de som ikke kan.
Du vil ofte høre ting som 'Jeg er en 100% automatiseringsingeniør', eller '80% automatisering 20% manuell', eller enda verre, 'Jeg hater manuell testing'. Sjokkerende!
I DevOps blir vi ført til å tro at alt skal automatiseres. Det er ikke noe sted for manuell inngrep, f.eks. manuell testing.
I dag sliter de fleste testere i et smidig team for å holde tritt med “Test Automation” -kravet. Det er press for å automatisere hver historie i sprinten, og det er ikke nok tid til grundig utforskende testing.
Problemet, spesielt i Agile-utvikling, er at kvalitetssikring tar en brukerhistorie og automatiserer akseptkriteriene. Mens de gjør det, er deres viktigste og eneste fokus å bryte med sine begrensede kodingsferdigheter bare for å få testen bestått.
Naturligvis skaper dette et smalt fokus når du bare er interessert i å automatisere testen og se den passere i bygningsrørledningen. Dette beviser bare hva som sto i akseptkriteriene - riktig eller galt - som fungerer, og du har en tendens til å glemme det store bildet.
Nedgangen i manuell testing
Flere og flere “tradisjonelle testere” går over til “smidig testing” ved å ta noen kodingstimer og bli mer tekniske.
Ikke misforstå meg; alt dette er bra. Jeg tror som testere, vi bør alltid strebe etter å lære nye og nye teknologier for å være ressurssterke. Vi bør forstå tech stack hvis vi ønsker å teste et system til en høy grad av kvalitet.
Imidlertid er den virkelige grunnen til at de fleste manuelle testere tar disse initiativene at det er en felles tro på at 'automatisert testing' er bedre enn manuell testing, og hei, koding er gøy, ikke sant?
Merk:Ved manuell testing er jeg det IKKE med henvisning til den gamle skolemåten for å følge et skript og utføre trinnene. Jeg refererer til de såkalte “exploratory testers” - de som gjør den virkelige testen og er nysgjerrige på å undersøke systemets oppførsel ved å utøve interessante og gjennomtenkte scenarier.Dessverre ser det ut til å være en stor nedgang i markedet for utforskende testere. Dette er ganske tydelig. Bare kjør et par søk etter 'manuell tester' og 'automatiseringstester' på et hvilket som helst IT-jobbsted, og se resultatet for dere selv.
Problemer med testautomatisering
La oss nå se hvorfor det meste av testautomatiseringsinnsatsen ikke gir noen verdi.
Vanlige feil jeg ser skje gjentatte ganger:
- Å ha feil forventning om automatiserte tester
- Automatisere tester på feil lag, på feil tidspunkt og bruke feil verktøy
- Automatiserer ubrukelige tester
- Forsømmelse av viktige områder
- Manglende viktige scenarier
Feil forventninger
For en stund tilbake skrev jeg et blogginnlegg på hvorfor vil du automatisere en test ? Hvis du ikke har lest den, er det verdt å lese.
Sammendraget av denne artikkelen er at du automatiserer tester som du vil kjøre regelmessig. Per definisjon er dette dine regresjonstester som bekrefter at systemet fortsatt fungerer.
Imidlertid, hvis automatiserte kontroller finner mange regresjonsproblemer, vil jeg sette spørsmålstegn ved utviklernes ferdigheter og utviklingsprosessen. UI automatiserte tester bør ikke [holdes på bekostning av] eller [kompenseres] for elendig koding.
Feil lag, feil verktøy og feil tid
Flertallet av 'Test Automation Engineers' i smidige team, ser på en brukerhistorie og automatiserer akseptkriteriene. Mesteparten av tiden gjøres dette ved en kombinasjon av selen og agurk.
Moderne webapplikasjoner er nå tydelig delt mellom backend og frontend. Bakenden består for det meste av et antall REST-nettjenester eller APIer med lett tilgjengelige sluttpunkter.
Applikasjonens logikk kan testes på API-laget. Imidlertid tyr de fleste testautomatiseringsingeniører til å validere funksjonalitet ved UI-laget, som i beste fall er tungvint.
Det er testverktøy der ute, for eksempel Karate og trygg, som forenkler API-testing. Vi bør bruke disse verktøyene under utviklingen. Dessverre kjenner noen testautomatiseringsingeniører ikke engang grunnleggende om HTTP , enn si å være i stand til å skrive API-testscenarier.
Når det gjelder UI-tester automatisering, Cypress er et flott verktøy. Det er mer som et TDD-verktøy for frontend-utviklerne. Utviklerne får veldig rask tilbakemelding på oppførselen til de nye UI-komponentene.
Både Karate og Cypress fungerer som “utviklingstestverktøy”, dvs. verktøy som veileder og støtter utvikling. Begge er lette, enkle å integrere og kan gi tillit til utvikling .
Vi kan da bruke Selenium eller Cypress til å utforme bare en håndfull scenarier som utøver systemet fra ende til annen. Disse scenariene danner vår lette regresjonspakke og gir tillit til forretningskontinuitet .
Ganske ofte hører jeg ting som, 'vi venter til funksjonen er fullt utviklet og stabil, før vi automatiserer tester'. Enhver bevisst tester vet at de nye funksjonene er større enn regresjonsfeil. Det er større sjanse for å finne problemer med den nåværende utviklingsfunksjonen, enn en stabil funksjon.
Hvis du skal bruke tid på å automatisere tester, gjør du dem parallelt med utvikling når de kan gi mer verdi.
Automatisering av ubrukelige tester
Ikke automatiser hver 'test' bare for den skyld. Sett noen tankeprosesser i spillet. Studer arkitektoniske diagrammer på høyt og lavt nivå. Spør hva som muligens kan gå galt. Undersøk integrasjonspunktene og se etter potensielle feilpunkter.
Ta en risikobasert tilnærming innen automatisering slik du (forhåpentligvis) gjør med den generelle testtilnærmingen. Hva er sannsynligheten for at noe mislykkes, og hva er innvirkningen av feilen? Hvis svaret er høyt, bør disse scenariene automatiseres og utføres på alle bygg.
I hver sprint ender vi ofte med å skrive automatiserte tester rundt brukerhistorier for den sprinten og glemmer integrasjonen med andre funksjoner. Det er enten svake eller ingen integrasjonstester.
Husk at automatisering av 'tester' tar tid. Husk også at ved å automatisere en test, tester du ikke egentlig, du bare sjekker at den aktuelle funksjonen tilfredsstiller noen akseptkriterier.
Du kan ikke automatisere testing, men du kan automatisere kontrollen av kjente fakta.
Derfor, hver gang du bruker automatisering av en 'test', tenk på tiden du kaster bort ved ikke å teste!
Forsømmelse av viktige områder
Jeg ser mer og mer av denne uaktsomheten siden DevOps-kulturens fødsel.
I DevOps er leveringsrørledningen, sammen med distribusjonsskriptene, ryggraden for programvareutvikling og levering, men de blir nesten aldri testet.
I løpet av de siste årene kunne jeg lett si at jeg har sett mye mer “miljøproblemer” enn funksjonelle feil. Miljøproblemer som problemer med CI-serveren, distribusjonsskriptene, testmiljøene og så videre.
Miljøspørsmål har en alvorlig innvirkning på utviklings- og testinnsatsen. De bruker mye utvikler og DevOps-tid og bremser distribusjonsprosessen enormt, men det er ingen vurdering å teste og dermed forhindre disse problemene.
Vi godtar dem bare som en del av den moderne programvareleveransen.
Vi bruker mye krefter på å automatisere funksjonell atferd og ser helt bort fra 'tingene' som betyr mest. Enda verre er det å måtte stole på Selen-tester for å indikere om distribusjoner fungerer eller ikke!
Manglende nøkkelscenarier
Scenarier er konge! Tross alt er det scenariene som avslører feil.
Ofte lekker et alvorlig problem i produksjonen fordi ingen tenkte på det aktuelle scenariet. Antallet utførte automatiserte tester spiller ingen rolle. Hvis et scenario ikke ble tenkt på eller testet, forteller lov om sod at det er en feil der inne.
Dessverre er det i de fleste smidige utviklingsmiljøer ikke nok dedikasjon til denne viktige 'Scenario Workshop' -aktiviteten.
Problemer med prosessen
La oss se hvordan de ovennevnte problemene manifesterer seg i et typisk utviklingsscenario:
- Produkteier skriver brukerhistorier med enten ingen eller minimum akseptkriterier.
- Ikke nok tid viet til historieforbedringsøkter for å diskutere ulike scenarier for en brukerhistorie.
- Akseptkriterier tolkes som akseptantester - Ja, det er en forskjell mellom de to !
- Testere automatiserer bare akseptkriteriene i brukerhistoriene, for det meste ved bruk av selen og / eller agurk.
- Automatisert testing er nesten alltid ansvaret for “automatiseringstestere”.
- Utviklere aner ikke hva som er dekket i testpakningene eller vet ikke engang hvordan de skal utføre de automatiserte testene.
- De automatiserte testene blir lagt til en stadig utvidende 'regresjonspakke' og tar derfor lenger og lenger tid å kjøre hver gang.
- UIs automatiserte funksjonstester er integrert i bygningsrørledningen, noe som er bra, men ...
En utvikler presser en enkel endring og må vente i 30 minutter på at de automatiserte testene blir grønne før den nye funksjonen eller feilrettingen kan distribueres til produksjon. Ventetiden på 30 minutter er bare hvis testene består første gang. Hvis de mislykkes på grunn av noen test- eller miljøproblemer, kan det ta lengre tid.
Ettersom de automatiserte testene kjører og QA etterforsker tilfeldige feil, har utvikleren og / eller produkteieren bekreftet den nye implementeringen og er glade for å gi ut, men de kan ikke fordi bygningen ikke er grønn.
Etter en stund blir enten byggingen grønn eller så blir ledelsen frustrert over de sviktende testene og tar en beslutning om å frigjøre allikevel. Så, BOOM, etter noen minutter i produksjon, er det en økning i 500 serverfeil.
Infrastrukturfeil
Feilene ser ut til å vise et lignende mønster
- Svikt i integrasjonspunkter.
- Feil i kommunikasjon med tredjepartsapper.
- Webtjenester er ikke 'opp' og forespørsler til API-endepunktene mislykkes.
- En feil konfigurasjon på en av virtuelle maskiner eller noder, og resulterer dermed i periodiske problemer.
Og likevel er det ingen prosess på plass for å kontrollere disse problemene som en del av utviklings- eller leveringsprosessen.
Fokus for testautomatiseringsingeniørene er å automatisere funksjonstester. Det er ikke noe fokus på ytelse, sikkerhet eller spenst. Og det er absolutt ingen testing av infrastrukturen!
Sammendrag
Tiden er kommet for å skifte fokus fra automatisering av funksjonelle tester som har liten sjanse for å fange funksjonelle problemer til de mer alvorlige og vanlige miljøspørsmålene som plager utviklingen.
Test automatisering, hvis gjort feil eller uten tankeprosess , er bortkastet tid og gir ingen verdi for noen. Crappy automatiserte tester kan medføre enorme vedlikeholdskostnader og hindre utvikling. Til slutt er den eneste løsningen å kaste testene.
I den moderne programvareutviklingen brukes mesteparten av 'Test Automation Engineers' med å kjempe med automatiseringskode og få 'testene' til å fungere i stedet for å fokusere på riktig testing og utforsking av systemet.
Det er bokstavelig talt ikke nok tid til å skrive automatiseringskode og utføre utforskende testing. Vi automatiserer historie etter historie og glemmer integrasjonstester, glemmer det store bildet.
Ofte ender vi med å utføre tonnevis av automatiserte tester, men utforskende testing finner de fleste feil. Så retrospektivt skriver vi en automatisert test for feilene som ble funnet ved utforskende testing for å fange regresjonsfeil.
Vi bør være selektive på hva vi skal automatisere og bedømme vår beslutning basert på risiko. Hva kan gå galt, hva er sannsynligheten for at det går galt, og hva vil innvirkningen ha på brukeren eller virksomheten hvis det gikk galt?
Hvis du driver med 'Test Automation', må du ikke bruke Selenium til å teste funksjonaliteten til APIer eller UI-komponenter. Bruk i stedet Selen til å automatisere bare en håndfull nyttige og forretningskritiske scenarier for å gi tillit til forretningskontinuitet før hver utgivelse.
Og til slutt, hver gang du bruker automatisering av en 'test', tenk på tiden du kaster bort ved ikke å teste!
Videre lesning:
