{"id":25111,"date":"2016-09-06T00:00:00","date_gmt":"2024-09-13T08:48:17","guid":{"rendered":"https:\/\/wordpress-583806-4798031.cloudwaysapps.com\/fredagsfix-och-andra-fienden-till-framgangsrik-testautomatisering\/"},"modified":"2024-11-15T16:22:22","modified_gmt":"2024-11-15T15:22:22","slug":"fredagsfix-och-andra-fienden-till-framgangsrik-testautomatisering","status":"publish","type":"post","link":"https:\/\/informator.se\/en\/fredagsfix-och-andra-fienden-till-framgangsrik-testautomatisering\/","title":{"rendered":"Fredagsfix och andra fienden till framg\u00e5ngsrik testautomatisering"},"content":{"rendered":"

<\/p>\n

Automatisering av testfall \u00e4r en av inneaktiviteterna i mjukvarubranschen just nu, men samtidigt \u00e4r det inte ovanligt att h\u00f6ra uttalanden som “Vi testade att automatisera, men det fungerade inte” eller “Vi har lite automatiserade tester, men vi anv\u00e4nder dem inte f\u00f6r de g\u00e5r s\u00f6nder hela tiden”. M\u00e5ste det bli s\u00e5 h\u00e4r? Naturligtvis inte. H\u00e4r kommer n\u00e5gra viktiga checkfr\u00e5gor. De kan l\u00e5ta sj\u00e4lvklara, men vara nog s\u00e5 viktiga att p\u00e5minna sig om emellan\u00e5t.<\/span><\/b>

<\/span><\/b><\/p>\n
<\/a><\/div>\n


<\/span><\/b><\/div>\n


<\/span><\/b><\/div>\n
1. G\u00e5r det att automatisera det du vill testa?<\/b><\/o_p><\/span><\/div>\n
F\u00f6rsta fr\u00e5gan som b\u00f6r st\u00e4llas \u00e4r s\u00e5 klart om det \u00f6verhuvudtaget g\u00e5r att testa det du vill s\u00e4kerst\u00e4lla p\u00e5 ett bra s\u00e4tt. \u00c4r det ett API eller ett UI som ska testas s\u00e5 \u00e4r det oftast lugna puckar, men hur testar du till exempel att videon som str\u00f6mmas till anv\u00e4ndaren inte hackar eller ser d\u00e5lig ut? Visst kan man kolla bit rates och j\u00e4mf\u00f6ra olika frames och annat, men fr\u00e5gan \u00e4r: \u00c4r insatsen som beh\u00f6vs v\u00e4rd besv\u00e4ret, eller blir det effektivare att forts\u00e4tta testa hela eller delar av testbasen manuellt?<\/o_p><\/span>

<\/span><\/div>\n
2. \u00c4r testobjektet tillr\u00e4ckligt stabilt?<\/b><\/o_p><\/span><\/div>\n
Hur mycket kommer gr\u00e4nssnittet att f\u00f6r\u00e4ndras under projektets g\u00e5ng? Ska du testa ett redan publicerat API? Go for it! Ska du testa ett UI vars arkitekt best\u00e4mmer sig f\u00f6r ett nytt utseende varje vecka? Gl\u00f6m det! Manuella testare \u00e4r oftast b\u00e5de anpassningsvilliga och luttrade efter m\u00e5nga projekt med luddiga och f\u00f6r\u00e4nderliga kravspecar, men ett testramverk \u00e4r ytterst bokstavstroget. En knapp som har flyttats eller bytt namn l\u00f6ser testaren f\u00f6r det mesta med ett h\u00f6jt \u00f6gonbryn, medan det automatiska testfallet f\u00e5r krupp och v\u00e4grar forts\u00e4tta. Dessutom kr\u00e4vs det varje g\u00e5ng en inte obetydlig insats f\u00f6r att r\u00e4tta till de tester som g\u00e5tt s\u00f6nder.<\/o_p><\/span>

<\/span><\/div>\n
3. Automatiserade testfall kr\u00e4ver tid till underh\u00e5ll!<\/b><\/o_p><\/span><\/div>\n
Detta f\u00f6r oss os\u00f6kt \u00f6ver till n\u00e4sta punkt p\u00e5 listan: Det g\u00e5r inte att tro att man kan l\u00e4gga en stund p\u00e5 att automatisera sina testfall och att man sen bara beh\u00f6ver exekvera dem f\u00f6r all framtid. Testfallen beh\u00f6ver underh\u00e5llas kontinuerligt om inte anstr\u00e4ngningen f\u00f6r att laga dem ska bli f\u00f6r stor, vilket leder till att ramverket faller ur bruk och lika g\u00e4rna kan sl\u00e4ngas. Allts\u00e5 kan man inte allokera 100% av resurserna till att utveckla nya testfall eller att exekvera manuella testfall – det kommer att straffa sig i l\u00e4ngden!<\/o_p><\/span>

<\/span><\/div>\n
4. Kan det \u00e5teranv\u00e4ndas? G\u00f6r det!<\/b><\/o_p><\/span><\/div>\n
I alla mjukvaruprojekt \u00e4r underh\u00e5llbarhet superviktigt. Men i automatiseringsprojekt d\u00e4r det ofta \u00e4r f\u00f6rh\u00e5llandevis f\u00e5 resurser som ska l\u00f6sa allt fr\u00e5n att skriva nya och underh\u00e5lla gamla testfall till att utveckla testramverket och att rapportera resultat, s\u00e5 \u00e4r det ofta kritiskt. \u00c4r klockan 16 p\u00e5 en fredag och utvecklarna har precis sl\u00e4ppt ett antal API-f\u00f6r\u00e4ndringar som ska testas i helgen? Vill du beh\u00f6va \u00e4ndra p\u00e5 ett st\u00e4lle i en utility-fil eller i alla dina 500 testfall? Trodde v\u00e4l det… <\/o_p><\/span>

<\/span><\/div>\n
\u00c4r de n\u00f6dv\u00e4ndiga f\u00f6r\u00e4ndringarna i ramverket s\u00e5 stora att de tar dagar att fixa, s\u00e5 \u00e4r antingen projektet blint f\u00f6r mjukvarans kvalitet eller s\u00e5 uppt\u00e4cks inte regressioner n\u00e4r de kommer in. Detta inneb\u00e4r ofta att det tar minst lika l\u00e5ng tid att uppdatera ramverket som det tar att reda ut orsakerna till alla nya fallerande testfall. Dessutom kan personer som \u00e4r upptagna med underh\u00e5ll inte anv\u00e4ndas till att skriva nya testfall.<\/o_p><\/span>

<\/span><\/div>\n
5. All makt \u00e5t integrat\u00f6rerna! <\/b><\/o_p><\/span><\/div>\n
Naturligtvis g\u00e5r det att undvika mycket av dessa problem om man har processer p\u00e5 plats f\u00f6r att 1) f\u00f6rvarna testutvecklarna om att f\u00f6r\u00e4ndring \u00e4r p\u00e5 g\u00e5ng s\u00e5 att de kan uppdatera ramverket i tid och 2) sl\u00e4nga ut eventuella f\u00f6r\u00e4ndringar som f\u00f6rst\u00f6r testresultaten. Har man dedikerade integrat\u00f6rer s\u00e5 \u00e4r dessa ofta bra personer att st\u00e5 p\u00e5 god fot med som testare. De har koll p\u00e5 vad som \u00e4r p\u00e5 g\u00e5ng och de vet ofta vad som troligtvis orsakar problem, speciellt om det \u00e4r ett continuous integration-system d\u00e4r testautomatiseringen \u00e4r inbakad i integrationsmilj\u00f6n. Har intergat\u00f6rerna makt att inte ta in eller sl\u00e4nga ut d\u00e5lig kod eller kod som inneh\u00e5ller beteendef\u00f6r\u00e4ndringar som inte rapporterats i f\u00f6rv\u00e4g och inte st\u00e4ndigt blir \u00f6verk\u00f6rda av ivriga projektledare eller produkt\u00e4gare, s\u00e5 kan detta g\u00e5 v\u00e4ldigt smidigt och kvaliteten \u00f6ver tid blir ofta h\u00f6g. \u00c4r leverans NU det viktigaste, s\u00e5 f\u00e5r projektet r\u00e4kna med att det uppst\u00e5r luckor i testt\u00e4ckningen och att kostnaderna f\u00f6r underh\u00e5llet \u00f6kar.<\/span>

<\/b><\/span><\/div>\n
<\/o_p><\/b><\/span><\/div>\n
6. Testa testkoden! Eller: \u00c4ndra aldrig n\u00e5got viktigt p\u00e5 en fredag…<\/b><\/o_p><\/span><\/div>\n
Tyv\u00e4rr \u00e4r det ju inte bara utvecklarna av produktionskod som kan sl\u00e5 s\u00f6nder ett testramverk, \u00e4ven testutvecklarna sj\u00e4lva brukar vara bra p\u00e5 detta. Speciellt problematiskt brukar detta bli om man “bara” ska \u00e4ndra “den d\u00e4r lilla grejen som inte p\u00e5verkar n\u00e5got annat” en fredag eftermiddag eller strax innan man k\u00f6r ig\u00e5ng den d\u00e4r kritiska testsviten innan leverans. Det slutar ofta med gr\u00e5t och tandagnisslan. <\/o_p><\/span><\/div>\n
Att testare orsakar instabilitet brukar tyv\u00e4rr ocks\u00e5 resultera i att utvecklarnas och projektets f\u00f6rtroende f\u00f6r testresultaten minskar drastiskt och ofta under en l\u00e5ng tid.<\/span>

<\/span>\u00c4r resultaten kritiska f\u00f6r projektet? Se d\u00e5 till att 1) testa och granska alla f\u00f6r\u00e4ndringar i testramverket ordentligt innan de kommer i produktion och 2) g\u00f6r inga kritiska f\u00f6r\u00e4ndringar i till exempel centrala delar i ramverket precis innan n\u00e5gra extra viktiga tester ska k\u00f6ras. Jag hoppas att jag inte har skr\u00e4mt bort alltf\u00f6r m\u00e5nga med mina exempel p\u00e5 allt som kan g\u00e5 fel… Det viktiga \u00e4r att du ser p\u00e5 testutveckling p\u00e5 samma s\u00e4tt som du ser p\u00e5 utveckling av produktionskod. D\u00e5 kommer s\u00e4kert \u00e4ven ditt projekt att bli ett lyckat exempel p\u00e5 testautomatisering!<\/span>

<\/span>Informator erbjuder flera sp\u00e4nnande kurser inom Kravhantering och Testmetodik. <\/span>Se alla v\u00e5ra kurser inom Krav och Test h\u00e4r<\/a><\/div>\n
<\/o_p><\/span><\/div>\n


<\/span><\/p>\n

\/Daniel Johansson, Test Automation Engineer<\/span><\/o_p><\/span><\/div>\n

<\/span><\/span><\/p>\n

\u00a0<\/span><\/span><\/h4>\n

<\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Automatisering av testfall \u00e4r en av inneaktiviteterna i mjukvarubranschen just nu, men samtidigt \u00e4r det inte ovanligt att h\u00f6ra uttalanden som “Vi testade att automatisera, men det fungerade inte” eller “Vi har lite automatiserade tester, men vi anv\u00e4nder dem inte f\u00f6r de g\u00e5r s\u00f6nder hela tiden”. M\u00e5ste det bli s\u00e5 h\u00e4r? Naturligtvis inte. H\u00e4r kommer […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[570,922,580],"tags":[],"class_list":["post-25111","post","type-post","status-publish","format-standard","hentry","category-blogg","category-blogi","category-krav-och-test"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t