BLOG
SOFTWARETEST

Blog: Building quality in

Implementering af rammeværktøjer som f.eks. SAFe, giver ikke garanti for "Built in quality". Det handler om den gode user story, de gode accept kriterier, forretningsmodellering så vi forstår den kontekst softwaren skal supportere.

Building quality in – det nye sort

Bevæger du dig rundt i blogverdenen, deltager du i agile konferencer, eller tager du måske kurser i agil udvikling og test, så vil du med stor sandsynlighed have stødt på begreberne “build quality in” og “shift left" flere gange. Ser vi på Scaled Agile Framework, findes der på deres poster et fint lille ikon nede i højre hjørne, ikonet har skriften ”built-in-quality”, og indikerer, at også i denne kontekst er det i fokus. Fokus sker i en sådan grad, at jeg oplever, at mange fejlagtigt tror, at implementerer man ”bare” SAFe frameworket, så har man built-in quality gratis med i pakken. Men her skal man ikke blive fanget, og huske at trykke på ikonet, og læse detaljerne 😊 Man opdager så, at det, som med mange andre metoder, ikke er helt så nemt, også her er der nødt til at ske et skift i måden vi arbejder på – og i højeste grad et skift i vores mindset. Der findes en række metoder og aktiviteter, der støtter op om konceptet, alle under paraplyen ”test-first”. Disse er:

-        Test driven development (TDD)
-        Acceptance test driven development (ATDD)
-        Behaviour driven development (BDD)

Ganske kort om de enkelte:

Test driven development baserer sig på iterative forløb, og fokuserer på, at udvikleren skriver tests til de enkelte units i koden INDEN udvikleren skriver selve koden, der skal testes. Når koden har bestået testene, udføres refaktorering, så koden bliver så ren og vedligeholdelsesvenlig som mulig. Udvikleren bliver altså guidet i sin kodning af de automatiske testcases, der udvikles først – tests der er kodefokuserede.

Acceptance test driven development definerer accept kriterier under udarbejdelsen af user stories, som nedbrydes i konkrete accept test cases, inden udviklingen igangsættes på baggrund af disse. Det er altså en kollektiv opgave, der løses i samarbejdet mellem team og forretning – tests der er kundefokuserede. Disse kan efterfølgende automatiseres og blive en del af continuous integration, men allerede som test scenarier i manuel form giver de stor værdi, da de har fokus på forretningens forventninger til den nye funktionalitet.

Behavour driven development kunne man kalde en specialisering af ATDD. Den har det samme formål - at fokusere på hvilken opførsel det fremtidige system skal have, her beskriver vi det dog i en specifik syntax frem for ”bare” at skrive test scenarier. Syntaxen kaldes Gherkin og et eksempel kan være:

Given some initial context, When an event occurs, Then ensure some outcomes.

Når acceptkriterier formuleres I denne syntax kan vi efterfølgende, ved hjælp af behaviour driven development frameworks, skabe automatiske testcases, som efterfølgende kan blive en del af continuous integration.

Udover disse formelle tilgange til test-first mindsettet, handler built quality in helt simpelt om, at forstå hvad det er vi skal lave, inden vi laver det. 😊 At forstå forretningens kontekst, hjælpe forretningen med at udtrykke disse behov på en måde, der dels er letforståelig for alle interessenter, men også er pragmatisk og letdokumenteret – vi er absolut ikke på vej tilbage til de klassiske kravspecifikationer. Det handler om den gode user story, de gode accept kriterier, forretningsmodellering så vi forstår den kontekst softwaren skal supportere og så videre.

I de kommende måneder dykker vi ned i nogle af disse områder, og diskuterer, hvordan vi, som agilt team, kan være med til at fokusere på at bygge kvaliteten ind i de løsninger, vi har ansvaret for. Hvis du ikke kan vente, og vil have en smagsprøve, så besøg Sogeti Labs hjemmeside og læs Barteks indlæg om TDD: http://labs.sogeti.com/investing-in-tdd/

Bartek Rohard Warszawski er sammen med Mohammad El-Wali den del af vores trænerteam, der fokuserer på TDD, BDD og automatisk test generelt

todo todo