Hoppa till huvudinnehåll
Menu

Den här sidan använder cookies. Om du fortsätter använda sidan så accepterar du användandet av cookies. Läs mer om cookies

Jag förstår

Behovsdriven utveckling och automatiska tester - Espresso Talk

Idag snackar José och Colin om hur vi jobbar med behovsdriven utveckling (BDD) och automatiska tester för några aktuella kunder.

Det är inte alla projekt som kräver det, men alla projekt som vidareutvecklas över tid bör ha någon typ av automatisk testning på plats för att minska riskerna för att tidigare åtgärdade fel återuppstår.

Det finns ingenting värre än att släppa nyutvecklad och vältestad funktionalitet på en webbplats för att först efter driftsättning upptäcka att tidigare utvecklad funktionalitet inte fungerar som den ska. Vad exakt var det som gjorde att det gick fel? I värsta fall upptäcks inte felet förrän långt efter driftsättningen. Det kan vara ett spamfilter på ett kontaktformulär som inte släpper igenom några svar eller det kan vara en sökfunktion som slutar indexera en viss typ av innehåll. Det kan ta väldigt lång tid att härleda ett sådant fel.

På en stor sajt blir det nästintill omöjligt att manuellt testa all viktig funktionalitet i alla miljöer (devices och webbläsare) vid varje ny release av ny funktionalitet. Det är här de automatiska testerna kommer in. 

Varför testa?

Först bör man ställa sig frågan, varför testar vi överhuvudtaget? I grund och botten handlar det om att vi vill säkerställa att vi möter projektets (kundens) förväntningar på kvalitet och funktion. 

Låt kunden skriva testerna

Vi har jobbat med automatiska tester i varierande utsträckning under 3 års tid. Det vi har insett är att det är svårt att skriva testfall för oss som leverantör. Det bästa vore om kunden (produktägaren) skrev testerna själv eftersom det är kundens krav och förväntningar vi testar för. 

Tanken med behovsdriven utveckling är att man innan man börjar implementera en funktion beskriver hur den ska fungera i läsbar form. I grund och botten är det en User Story + How To Demo som behövs. Först när den beskrivningen finns på plats kan vi starta utvecklingen.  

Behat = skriv tester som alla förstår

Behat är ett ramverk som hjäper produkägare att översätta User Stories till automatiska tester som teamet kan utveckla mot. Först när en funktion har passerat testet är funktionen klar.

Så här kan det se ut när man skriver testfall i Behat:

Behat Example

 

Colin och José demonstrerar hur vi använder oss av Behat i kombination med Selenium och Behat Drupal Extension för att hantera några olika scenarios. Colin visar hur han drar igång 7 olika webbläsare och upptäcker ett test som inte klaras av i Internet Explorer på en windowsmaskin som står i entrén (geeky!). Applåder! Wow! 

Varje gång vi släpper ny funktionalitet så kan vi köra våra tester. Vi kan se direkt om något går sönder vid släpp av ny funktionalitet. Vi kan testa på alla möjliga miljöer och upptäcka fel så tidigt som möjligt. När sajten blir större är det ovärderligt.

Vill ni veta mer prata med: Colin, Jose eller Miles.

Vi hjälper dig nå resultat. Kontakta oss Ring direkt på 08-20 90 04.

Frukostföreläsning: Få koll på trenderna och ligg steget före i den digital transformationen 2017

Beställ materialet i efterhand och få koll på de trenderna 2017 för digital transformation och hur du möter din publik digitalt.

Kraftsamling behövs för digitaliseringen av offentlig sektor

Vi har varit på Offentliga Rummet 2016 i Malmö och tagit tempen på hur det går med digitaliseringen i den offentliga sektorn.
MDN

Sunsdvall bygger öppen e-tjänstplattform

Vi har pratat med IT-strategen Janne Koponen om Sundsvalls kommuns arbetet med sin öppen källkodsplattform för att skapa etjänster.

Utbilda dig som produktägare

Vi utbildar och coachar i produktägarskap för dig som är ansvarig för en större webbsajt, intranät eller webbapplikation.
MDN