Skal QA være en del af agile teams?

For at sige det lige ud, er der noget som har gået mig på længe: spørgsmålet om den rigtige sammensætning af et agilt team. Et agilt team er jo selv-organiserende og tværfunktionel hvis man følge best-practice, og dermed skal teamet besidde alle de nødvendige kompetencer for at kunne levere et klar-til-release produkt fra iteration til iteration. Det vil sige ingen hængere ift. test, ingen afsluttende “test runs” så test må ikke være en flaskehals. Betyder det så at test bør være en stærk kompetence hos et agilt team? Ja! Er det så ikke bare med at ansætte flere testere?

Sagen er at titler og roller som “Tester” udvandes i den agile ideologi. Mens der er mange agile teams benytter sig af Scrum, skriver Ken Schwaber og Jeff Sutherland i deres “The Scrum Guide” fra 2013 om et typisk Scrum team:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Så der er ingen titler, ingen undergrupper og ansvaret ligger altid hos teamet. Det er netop op til teamet at søge de nødvendige kompetencer – enten ved at tage dem ind på teamet eller søge dem ude. Traditionelt har testen ligget til sidst i udviklingsprocessen, selv om gode intentioner har forsøgt at skube den tidligere, som i V-modellen.

På et agilt team tester vi ideelt hele tiden, så snart der er noget klar til det. Realiteten kan være en anden – det afhænger af hvor god er teamet til at planlægge og styre igennem mængen af opgaver, så der er noget at lave til alle.

Efter nærmere overvejelse hos den lokale HR manager tilknyttet vores fiktive team, bør testerens profil matche typen af de test opgaver der kan forekomme:

  • Tidlig test kan være at review’e stories og accept kriterier for at sikre dem efter INVEST og på den måde få kvalitetssikring tidligere ind i processen
  • Tidlig og løbende test er at sikre alle acceptkriterier er testet, intet er glemt og eventuelle ændringer (som helt sikkert vil være der!) er reflekteret i fælles forståelse og evt dokumentation i form af tests eller tekstuel beskrivelse
  • Tidlig test kan indebære review af arkitektur med henblik på testbarhed.
  • Tidlig test kan indebøre review af produktionskode og input til automatiseret test (som regel kode igen)
  • Tidlig test kan indebære at teste REST/ API interfaces med tools, både funktionelt og måske med heblik på performance og sikkerhed.

Disse er blot for at nævne nogle, ud fra egne erfaringer – men de illustrerer ret godt et billede af en mere teknisk profil der er i stand til at arbejde sammen med teamet meget tidligt i processen. Samtidig har profilen en rigtig god forretningsforståelse, overblik og kommunikationsevner. Findes der sådan en rolle vi kan “hyre ind” på teamet?

Der er højst sandsynligvis få som er gode til det hele på en gang. Og det er netop pointen med agile / scrum teams at der skal ikke være sådan nogle roller! Kompetencer bør være spredt, og ideelt kan udviklere også teste, mens de test mindede førhenværende testere skal kunne finde sin anvendelse i at understøtte testen på alle mulige måder — også ved at skrive (test) kode. Hermed er agil QA født som en kompetence, snarere end en rolle!

Poul sagte:

  • Agil QA: et mindset du kan tilegne dig for at blive rigtig god til at kvalitetssikre(ok det er nok ikke kun mig der har sagt det, men jeg har i hvert faldt skrevet det her)

Tilbage ved spørgsmålet om hvorvidt bør QA være en del af et agilt team: forudsat teamet har et behov, er det en rigtig god ide! Jeg ved at svar der indeholder et “men” har en begrænsende virkning, så måske kunne man formulere det som “det afhænger af kontekst, såsom teamets sammensætning og typen af opgaver”.

Hvis teamets mindset ligger langt fra “vi skal også tænke på testbarhed og teste selv”, eller når disse mangler decideret som kompetencer — så kan man ikke komme udenom det. En eller flere personer med stærke kompetencer, eller om ikke andet viljen til at lære QA kan så frø og starte en kultur hvor test er en naturlig test af udvikling (så ja til en dedikeret QA i en periode). En del af opgaven vil også være at lære teamet om QA, hvilket er ret svært uden at være en del af teamet.

Et mere modent team med kompetencer i kvalitetssikring kan måske undvære en dedikeret QA i en periode. Der vil dog være fare for at fokus på god kvalitetssikring vil blive udvandet, og her kunne man tænke et setup hvor QA rollen er “assisterende” i form af en Test Coach der både kan stille de rigtige spørgsmål og rette teamets opmærksomhed efter de ting som kræver dette. Men hvem bestemmer så om hvorvidt teamet er modent nok til at undvære en dedikeret QA..? Jeg ville ønske jeg kunne være fagligt korrekt og skrive “teamet”, men i realiteten har organisationen ofte den sidste ord. Økonomi, projektmål og politik vil jeg ikke ind på i dette indlæg, så tilbage står en klar anbefaling om at teamet i hvert fald giver udtryk for hvad er i deres overbevisning et behov for at være gode og effektive til deres arbejde, og ikke mindst selv søge veje derhen (hvilket jeg også skrev om i et tidligere indlæg).

ps. på samme måde kunne man tage en dialog om roller / kompetencer som user experience (UX), Business Analyst (BA) osv. Hvis teamet laver et produkt der er afhængig af god UX, skal denne kompetence ikke være en mangelvare eller en flaskehals. Selv den bedste dedikeret UX’er tage på ferie, blive sygmeldt eller generelt  være en eftertragtet person alle vil tale med 😀 – et agilt team bør ikke være afhængig af enkelte personer hverken på eller udenfor teamet!

Reklamer

Valg af Test Management Tool

Når man overvejer at introducere et Test Management Tool, er det som at skulle kigge efter en ny bil. Der er mange alternativer, og alle er enige om at det skal være brugbart, brugervenligt, have plads nok til det nødvendige, have de ønskede features og for nogle også være lidt smart 🙂

Lige som med et godt valg af en bil, når man længere med et velvalgt tool – men der er altid risiko for at man kommer til at betale mere end nødvendigt. Betydelige omkostninger, som er forbundet med en investering får os til at lave analyser og sammenligning af valgmuligheder for at vælge den bedste, og processen er langt fra altid en nem opgave. I modsætning til det med biler, er der også omkostninger i forbindelse med introduktion af værktøjer. Opstart, undervisning men også tiden der er brugt i forbindelse med opsætning, oprettelse af krav, test cases og meget andet som er en forudsætning før det valgte værktøj kan begynde at give afkast. Vælger vi forkert, skal vi måske gøre det om igen – i tilfælde vores data ikke kan nemt flyttes i mellem alternative værktøjer.

Hvordan vælger vi det rigtigt første gang? For nyligt skulle jeg forholde mig til sådan en situation og jeg fik genopfrisket mine erfaringer med disse overvejelser:

  • Den oplagte start er ikke krav / kriterier men i stedet processen man ønsker at automatisere. Hvorfor det? En ineffektiv proces som understøttes eller automatiseres med et værktøj bliver kun hurtigere men ikke bedre af det. Et eksempel kunne være at man først skriver krav, dernæst laver design, test cases og til sidst skriver kode (den såkaldte vandfaldsproces), hvor informationen fortolkes og skrives ned igen flere gange i forskellige former. På den måde risikerer vi både at tabe detaljer og den rigtige vinkel på formålet med det vi laver – processen kan blive en slags ”broken phone” leg når det endelige resultat langt fra matcher det oprindelige udgangspunkt.

Hvis vi starter med at kigge på processen, har vi måske mulighed for at forbedre det i samme omfang vi introducerer et tool. Hvad med at gøre krav og test til en og samme arbejdsprodukt, sådan som det fungerer i Behaviour Driven Development (BDD)? Man behøver slet ikke at introducere store forandringer i specifikationsprocessen for at kunne blive enige om at alle krav illustreres med eksempler, som kan bruges til at verificere kravet med. Eksemplet tjener både det formål at kommunikere hvad er ideen, udgangspunktet og slutmålet med ønsket er og samtidig også bruges som et test-scenarie. Eksemplet kan nemt skrives i prosa, hvis man ikke gider at bruge nye former for specifikationssprog, men gerne køres igennem et review med testbarheden for øje. Ændringerne i krav medfører ændringer i test, hvilket reducerer risikoen for at test grundlaget kommer ude af trit med krav.

Det er blot et eksempel på en procesforbedring, hvor standard for specifikation er et og et bedt emne. Vi kunne også kigge på test data management, test strategi og arbejdsmetoder, kommunikation og quality intelligence (overblikket over tværgående aspekter i organisationen på tværs af processer og værktøjer). Jo mere harmonerer vores tool med alle disse, desto større gevinst får vi – f.eks ved at tænke på kvalitetssikring i alle stadier af et produktudviklingsforløb!

  • Mennesker, og ikke mindst deres mål (og i mindre grad – deres behov) i forbindelse med deres relationer til test og kvalitetssikringsprocesser. Et værktøj kan være smart for nogle men en forhindring for andre. Det offentlige sundhedsvæsen er et eksempel, hvor logning og tidsregistrering giver bedre information til ledelsen men ses som et byrde af dem der skal udføre dette. Er detaljeret overblik over udførte test cases virkelig nødvendigt, hvis det betyder at testere når at teste mindre? På nogle projekter er det. Måske har vi brug for overblikket for at kunne koordinere på tværs af personer, teams og endda afdelinger i forskellige lande. I så fald er vi tilbage til det første punkt, med spørgsmålet om hvordan gør vi det smartest.
  • Næste punkt er drivkraften, for hvis der er fordele må der også være nogle som høster dem. Måske er det en god ide disse mennesker er med til at vælge / teste den valgte løsning før denne bliver virksomheds standard. Det er lige som med den agile udvikling: involvering af slutbrugeren er altafgørende for at forstå kravene!
  • Beskrivelsen af kriterier, som måske kunne udføres med eksempler i stedet for den sædvanlige punktopstilling i tabelform. Tænk over situationer i stedet for adjektiver og sætninger som beskriver det åbenlyse meget generelt.

I stedet for ”brugervenlig” – ”man skal kunne oprette en test case alle steder i programmet”, eller ”en søgning efter en bestemt testcase bør ikke tage mere end 10 sekunder”.

I stedet for ”nem at integrere med” -> ”skal kunne indlæse eller linke til krav i Jira”, eller ”skal kunne eksportere test cases til CSV og Excel filformat.

Ud over eksempler på funktionalitet, kunne der også eksempler på hvilket overblik man ønsker at skabe for test-relaterede personer. Kunne rapportering fra automatiseret test, defect tracking og nylige ændringer i krav være en del af overblikket?

  • Bredden af mulige alternativer – hvor langt ud skal vi kigge? Hvis vores eneste krav er håndtering af nedskrevne test cases der kan deles mellem flere testere, behøver vi måske ikke en dyr Content-Management System (CMS) pakket ind som et Test Manageent Tool.. At flere vælger at bruge CMS til teststyring er ikke nødvendigvis et problem, men måske snarere afspejling af de egentlige behov der kan løses med simplere systemer. Når disse ikke længere kan modsvare voksende krav, i takt med procesoptimeringer, er der tid til at kigge på andre. Dog kan man stadig kigge bredere – f.eks er der et standard system som vedligeholdes af en ekstern part som kan tilpasses til behovet?

Disse punkter er mine personlige forudsætninger som gerne skal overvejes før den endelige valgproces, som jeg ikke vil gå i dybden med. Der findes mange måder at træffe beslutninger, hvilket er nærmest et emne for sig selv. Det eneste sikre er at processen med fordel kunne gøre brug af et pilotprojekt, som kan give ro i maven over den valgte løsning.

God jagt på den bedste Test Management Tool derude!

38341d85f8c136873d5176303ff24a9a

ps. der findes jo også gode sammenligninger af forskellige tools på nettet (her tænker jeg ikke på dem der er lavet af selvsamme producenter af disse tools). Jeg ville ikke bruge tid på at skrive om noget alle kan google, men til gengæld vil jeg gerne høre om jeres erfaringer i forbindelse med valg af test management tools og skrive en case-baseret guide til samme emne 🙂

https://www.linkedin.com/in/pouls

 

 

Om at finde sin vej

En af de mest inspirerende samtaler jeg har haft i nyere tid handlede om det med at komme til succes og opnå mere i sit liv. Det råd jeg fik, handlede slet ikke om at sætte mål og finde måder at komme derhen (som jeg f.eks skrev om i min tidligere blog om succes og udfordringer). Det gik ud på at lave det man elsker at lave, finde sine værdier og det større formål man brænder for, og det var hele opskriften. Det var ikke nødvendigt at lave en større plan med langsigtede mål. Der også noget fedt, grænseoverskridende og ud-af-min-komfort-zone ved at slippe styring efter mål, sætte efter det man brænder for og stole på at det vil bringe en et godt sted hen.

I den relation synes jeg at det minder en del om Connecting the dots historien fra Steve Jobs utrolig inspirerende Standford Commencement speech (2005):

You can’t connect the dots looking forward. You can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. Because believing that the dots will connect down the road will give you the confidence to follow your heart even when it leads you off the well-worn path and that will make all the difference.

Vi lever tit med en forestilling om hvad vi og vores liv burde være. Nogle af disse forestillinger hænger godt sammen med hvem vi er; andre har sine rødder i vores syn på forventninger og den anerkendelse vi modtager fra vores omgivelser. Steve siger noget om dogma; om ikke at være fanget i forestillinger og rammer, som ikke er vores egne. Det synes jeg egentlig er en god pointe, som hænger godt sammen med det råd jeg fik. Nogle gange bliver man nødt til at afvige fra en vej, som ikke viser sig at være ens eget.

Success er ikke kun resultater på papiret, eller noget som kan sættes i udmærkelser-sektion på ens CV. Success er også at være tilfreds med og at kunne stå inde for det man laver – og det kan også være grunde til at afvige fra den lagte rute.

Og måske behøver det ikke være et valg – enten at være metodisk og planlægge sin vej til den success, eller bare at slippe det hele løs og kun være i nuet. Måske kan man være tilpas fleksibel navigation efter mål baseret på ens værdier, som man udforsker løbende. En styring der tillader at være interesseret for andre ting end det der hænger sammen med målet. At bryde rammerne ned fra tid til anden betyder også at give sig selv plads til at få noget nyt under huden – som at tage kursus i kalligrafi eller noget andet, blot fordi man finder det spændende! Der er ligesom at tage en ny udfordring op, blot fordi udfordringen i sig selv er spændende, uden at det nødvendigvis ser ud til at bringe en et sted hen.

En god ven til mig har lige taget uddannelsen som coach, og ville derfor coach’e mig som en del af forløbet. Jeg havde selv taget noget lignede kursus om coaching principperne, og kunne derfor forudse nogle af spørgsmålene. Alligevel blev jeg mindet om det med “Hvorfor er det vigtigt for dig?“, “Hvad giver det dig?” som er nogle af de ting man bliver spurgt om når man begynde at beskrive hvad man vil i sit liv. Det får en virkelig til at tænke over sine værdier!

At vove sig ud i og at lære noget nyt er værdi i sig selv, efter min mening. Læring giver en større perspektiv, mental udfordring til hjernen og vejen til nye erfaringer (når man nu også husker at bruge sin viden til noget).

PISTOL

Why, then the world’s mine oyster.
Which I with sword will open.

Jeres app virker ikke

Det er faktisk irriterende når ens liv bliver forstyrret af software fejl. Det er nu ok, hvis Netflix ikke vil stream’e i aften – jeg kan læse en bog. Noget andet er de ting som bare skal virke. F.eks indkøb!

Herhjemme holder vi meget af at bruge mindre tid på indkøb og mere tid på familielivet. Derfor bruger vi en af de tjenester der leverer dagligvarer hjem. Deres app er på flere måder genialt, da den indeholder opskrifter til inspiration, og under disse finder man så varerne man kan passende bestille til opskriften. En anden god funktion jeg er ret glad for er ens top 200, som listen over de ting man bestiller oftest. Mælk, pålæg og grøntsager skal vi have hver uge, og derfor er det ret nyttigt man kan klikke de ting man plejer af, uden at skulle navigere rundt i varekataloget. Men sådan skulle det ikke gå denne gang.. Bang! Hvor end jeg prøver, kan jeg ikke se min top 200!!! (ked-af-det-smiley-med-krydser-i-stedet-for-øjne)img_1134Det er nu selvfølgelig svært at få medfølelse over luksusproblemer som denne, set ud fra situationen for mig som individ (jeg kom videre, jeg bestilte mine varer trods hjælpefunktionen ikke virkede). Var det et kritisk fejl for firmaet bag app’en? Faldt omsætningen? Det vides ikke.

Men jeg kom til at mindes min mentale tjekliste over releases for mobile app’s som blev gradvist opbygget gennem flere år.

QA’ens guide til gode App releases

  • Først, og altid først: definér release strategi! En app rulles typisk ud til alle brugere igennem opdateringsmekanismen. Dog kan vi i nogle tilfælde release til en vis procentdel af brugere for at se om der opstår kritiske fejl, som kun fåtal når at opleve inden disse bliver hurtigt fikset i en ny release.
    • Android har en funktion hvor man bestemmer hvor mange % af brugere får den nye release.
    • På iOS kan man det ikke, mig bekendt.
    • Når vi introducerer nye features, kan disse afprøves ved hjælp af Feature Toggles, som også kan kodes til at blive aktiveret procentvis
    • Release strategien er med til at bestemme QA indsatsen

Forudsat features, der er med i releasen er blevet grundigt og ordentligt testet, og vi har gode unit-, integrations- og regressionstest på systemniveau, har vi ikke så meget at bekymre os. Virkeligheden er ofte noget andet – ikke fordi man sløser, men fordi forudsætninger for god kvalitetssikring ikke altid er til stede.

Hvis der er alligevel bekymring kunne det give mening at benytte følgende strategi: identificér områder i koden, konfiguration og infrastrukturen, som blev ændret siden sidste app release, og lav en strategi for at sikre der ikke er opstået nye fejl på grund af disse. Dette kræver:

  • Overblikket over kodeændringer der fremtrylles som en diff mellem live og den kommende version. Review er ikke kun noget softwareudviklere gør for hinanden. Som en QA, får man mange hints om hvor det kunne være relevant at teste (QA perspektivet er også værdifuld i at spotte eventuelle problemer her, tidligt i udviklingen)
  • Konfiguration (også lokalt på devices) tjekkes på samme vis. Udfordringen her kan være transformation (altså en proces hvor en version bruges lokalt eller på et test miljø, mens en anden i produktion). Det kan være rigtigt svært at teste produktionskonfiguration hvis forudsætninger er ikke på plads. Et par ekstra øjne i form af review er at foretrække i dette tilfælde.
  • Teamet har typisk styr på hvad de har ændret i infrastrukturen (det skader aldrig at spørger en ekstra gang.

Berørte områder er ikke kun filer som er blevet rettet i. Hvis man retter i delte filer (programkode biblioteker) bliver den berørte flade meget hurtigt bredere.

Det bringer os frem til en af de vigtigste våben i kampen mod domino-effekten: regressionstest! Få status på CI: har vi automatiseret test på de berørte områder, og kører det godt. Sandsynligvis kender du dækningen allerede, hvis du har testet på platformen i noget tid 🙂

  • God regressionstest dækker alle funktioner med høj impact – forudsætningen softwaren overhovedet har en værdi for forretningen. Hvis jeg ikke kunne bestille varer ville det være skidt.
  • God regressionstest duplikerer ikke test cases, og slet ikke på samme lag. Et produkt af en betydelig størrelse kan have mange test scenarier i sin regressionstestsuite, hvorfor overblikket er essentielt her. Vi vil ikke spilde tid vi kan have brugt på at få feedback fra brugerne.
  • En god regressionstest forudsætter at brugeren kan have forskellige konfigurationer af hardware og software. Er der risiko for at automatiske test ikke tester på alle konfigurationer?

Efter disse overvejelser, burde der nu være et overblik over automatiseret del af regressionstesten. Det som vi ikke har dækket, kunne vi overveje at teste manuelt. Såfremt vi har tid (man kan passende spørge sig selv, kan vi leve med fejl i et af de områder som er ikke blevet regressionstestet?). Svaret er også ligetil, når man har en test- og produktstrategi som fortæller noget om fejltolerancen. Meget apropos:

quote-what-is-tolerance-it-is-the-consequence-of-humanity-we-are-all-formed-of-frailty-and-voltaire-30-37-37.jpg

QA mindset’et er en finurlig ting, og frembringer ofte flere spørgsmål end teamet når at forholde sig til, eller håndtere i løbet af release-forberedelserne. En god ting at huske sig selv på, er at jo tidligere man stiller de spørgsmål, desto større sandsynlighed for en god kvalitets release.

p.s. varerne er bestilt og kommer på søndag, det bliver dejligt at få tid til at lave mad og måske teste lidt mere på ting rundt omkring

 

Success afhænger (også) af udfordringen

Da jeg læste på universitetet fik jeg noget af et komplement fra en af mine bedste venner. Han var fascineret af min evne til at “forudse”  ting forud for de sker. Sådan så han mig, da jeg overvejede de mulige scenarier i jagten på muligheder og mål. På den måde så jeg forhindringer som kunne opstå på vejen, og måske var det med til at lede mig ind i QA for 5 år siden.

Den dag i dag kan jeg stadig ikke forudsige fremtiden, men det at følge sin intuition, fornuft og logisk tænkning kan også være en måde at lægge en strategi for at opnå noget. Intuition er en sjov ting: en QA-kollega til mig har ry for at være en som “kan få tingene til at gå i stykker”. Ikke blot som et resultat af dybdegående risikoanalyser og erfaring med netop de ting hun rørte ved, men blot ved at have det i sine hænder. En sjælden evne – eller måske den kvindelige 6. sans? Jeg ville ønske jeg havde den særlige evne, men endte i stedet at forsøge at finde vejen igennem læringens veje.

Continuous improvement i teorien og hos Toyota

Uanset om man bevæger sig inden for den ene eller anden branche, kan man godt have en ambition om at blive bedre. Det ses jo inden for sport, kunst eller folk med nogle særlige evner, at talent, uanset størrelse, udvikles med øvelse. Tanken om at selvudvikling kan og bør ske oftere, end de få gange man er på kursus eller til konference, havde da også strejfet mig mere end et par gange i løbet af min karriere.

I øjeblikket læser jeg bogen Toyota Kata, som handler om begrebet kontinuerlig forbedring (continuous improvement) inden for bilproduktion. Samlebånd og leveringstid har meget lidt at gøre med den intellektuelle process i det med at designe, kode og teste software. Alligevel synes jeg at man kan drage paralleller, både i forhold til test, organisationen, og sig selv som person.

Ideen med Toyota Kata er at man kan forbedre sin virkelighed ved at sætte en ambitiøs vision, der ligger langt ude i horisonten. Visionen fungerer som en ledestjerne, som man forsøger at nå, uden at kende hele vejen derhen. Kontinuerlig forbedring er arbejdsmetoden, snarere end tilføjelsen til det (som når man tager på kursus en gang om året). Forbedringen ligger så i at opdage nye og bedre måder at komme tættere på målet og det sker konstant: hver dag prøver man noget nyt!

Allerede nu kan man tænke, det har jeg ikke tid til – jeg har et arbejde jeg skal passe. Eller så kan man måske tænke: hvorfor skal jeg prøve noget nyt hvis jeg allerede er god til det jeg laver…? Lad os tage et par eksempler. Hvis jeg skal have gæster, og gerne vil servere en kage, er det nemt at konstruere planen: kør hen til den nærmeste bager og køb en. Jeg kunne også bage en kage, og dertil skal jeg bruge en opskrift og ingredienser – stadig en forholdsvis veldefineret plan, som kun kan gå galt hvis de lokale supermarkeder er lukket. Men hvis nu jeg i stedet definere mit mål som en karriereskifte: lad os sige jeg gerne vil blive en bager. Måske endda vil jeg gerne sigte efter at være den bedste og den mest efterspurgte bager i hele Danmark. Hvad vil planen så være? Og hvis andre er samtidigt i gang med at arbejde efter den samme mål, hvordan påvirker det så min plan..?

Der kan være forskel på mål, konkurrence og ikke mindst midler i forskellige industrier. Alligevel, det som altid er sikkert er, at ingen kender fremtiden, og da virkeligheden er i konstant forandring, kan vi som sådan ikke altid regne med at kunne lave en plan hen imod de mål vi sætter os. Vi kan selvfølgelig også altid bare hente kagen..

Kata er en måde at finde vejen til målet, når vejen er ikke kendt. Meget kort sagt, går det ud på at have en vision (1), forstå virkeligheden som den er nu (2), og så arbejde hen imod den næste mulige delmål (3) igennem en række små eksperimenter (4), som illustreret her: (tak til internettet for lån af billedet)

kata

Alt mellem 2 og 1 antages for at være “den grå zone” – et ukendt område, som vi ikke kan navigere med sikkerhed igennem. Eksperimenter er de små skridt vi kan tage hen imod målet. Fejler vi, så lærer vi også noget – men for at det gavner på længere sigt kræver det at vi ved om vi går i den rigtige retning. Derfor har vi også delmål med på vejen (de kaldes Next Target Condition), som tager udgangspunkt i og er en forbedring af virkeligheden som den er nu (Current condition).

Hvis jeg tror jeg kan synge, men det lyder kun godt i mit hoved, så er der altså en lang vej til at blive en sanger. Derfor er forståelsen af min nuværende situation er lige så vigtig som retning, i forhold til det med at vælge de næste skridt.

Continuous improvement inden for softwaretest

Produktionsvirksomheder som Toyota sigter efter at forbedre effektiviteten af produktionsprocesser. Hvad kunne vi bruge det til inden for softwaretest? Hvis man vil kan man drage et par paralleller de to verdener i mellem:

  • Fagligt: software test er også en proces som kan forbedres hen over tiden. Som en softwaretester kan man blive bedre til sit fag. Som en organisation kan vi kan blive bedre til at arbejde sammen effektivt.
  • Netværk og domæne: viden om test og ens organisation lever ikke hos den enkelte, men udvikler sig gennem kontakt til fællesskabet. Det gælder i store træk ens domæne (f.eks test) og omgangskreds (dem man arbejder sammen med). Man kan lære hvem der kan hvad i virksomheden og danne relationer og partnerskaber, som styrker samarbejdet og på den måde hjælper med at opnå ønskemål hurtigere og bedre.
  • Karriere: Ens karrierevej kan også ses som en udvikling der består af en masse forbedringer til ens kompetencer, som ud over de faglige kunne f.eks indebære evner til at håndtere mere kompleksitet, se i større perspektiv, være en bedre kommunikator og leder. Disse afhænger i princippet af vejen, om det er op ad stigen eller hen til en anden rolle

Softwaretest er en disciplin som styrkes med en række kompetencer, der afhænger af den type test man udfører. De enkelte komponenter kan gavne en personligt, men  ikke nødvendigvis garantere at vi kan blive bedre til at løse de udfordringer vi står med her og nu. Hvorfor det? Det afhænger af konteksten. F.eks kunne man have en idé om at kunne forbedre test effektiviteten ved at kunne en række test teknikker eller værktøjer som kan udvide ens kompetencer. Antagelsen her ligger i at tro man bliver mere effektiv og nyttig, fordi man er i stand til at udføre et bredere spektrum af opgaver inden for test.

Men man kunne også blive bedre til at samarbejde og drage nytte af de kompetencer som ens kolleger allerede har. De “bløde” kompetencer kan være en anden vej til at blive bedre: ved at være stærkere sammen, og ved at komplementere de kompetencer som findes hos dem man arbejder sammen med. Og så kan kunne man stadig forfølge de kompetencet og teknikker der giver mening i kontekst af at man er flere der arbejder sammen. Forbedringer sker sjældent i ensomhed, selv om man vælger selv om man vil gå vejen alene. En anden glimrende bog “Together is better” af Simon Sinek har en passende illustration til lejligheden:

Uanset hvad man vil sigte efter, er der noget basalt i ikke at starte med antagelsen om at en bestemt løsning kan være vejen til en bedre virkelighed. Ved at vende det rundt vil man kunne forestille sig en ny virkelighed, som en vision af det: hvordan vil jeg gerne virkeligheden skal se ud. Det starter med et “jeg” da man skal have et sted at starte, og have det godt i maven med den retning man vælger at sigte efter. Man kunne overveje:

  • At kunne afsætte tid til at hjælpe og vejlede mine kollegaer
  • At kunne definere en test plan på det niveau som kræves for projektet
  • At tage mere ansvar for test i min organisation

Visionen afhænger af ambitioner – de udfordringer man tør at sætte sig selv.

For at arbejde derhen, kunne man lave en opstilling:

Det nuværende tilstand Vejen derhen Vision/Udfordring
En softwaretester med en basal viden inden for test og testdesignteknikker Det næste mulige skridt.

At kunne agere Test Manager, planlægge og styre test på alle udviklingsprojekter som virksomheden udfører.

Mit næste realiserbare mål

Når der er langt til målet, kan det være svært at tage et skridt hen imod det. Men det første skridt er faktisk det vigtigste. Hvordan ved man hvad er det næste rigtige skridt? Ofte, specielt når man bevæger sig i et ukendt område, ved  man det slet ikke. Det er ikke sikkert man ved hvad der skal til for at planlægge og styre softwaretest endnu. Men bare det at man tager et skridt, er en sejr i sig selv.

Det næste skridt kan gå i retning af ens vision – ved at løfte det nuværende tilstand en tand eller 2 op:

  • Jeg kan blive bedre til at tænke på forudsætninger for at jeg kan teste effektivt, forberede test data og skaffe den nødvendige information i god tid
  • Jeg kan notere risici jeg opdager undervejs, mens jeg lærer om nye projekter og tiltag
  • Jeg kan lære at planlægge og designe test som reducerer risici ud fra de givne betingelser

Et eksempel på det næste realiserbare mål kunne altså være at blive bedre til at løse nogle af de problemer og udfordringer, som ligger til grunden for en god planlægning og styring af test. Ved at forstå processen og efter at have haft fingrene i det, bliver jeg bedre til at gøre det igen og igen og måske på en mere overordnet niveau (f.eks i en test plan).

I forhold til samarbejde, kan både vision og arbejde med realiserbare delmål udføres i en kontekst af et team. Et QA team kan f.eks have en vision om at blive verdens klasse QA team.

Vi må og skal fejle

Vi ved det egentligt godt at det kan være nødvendigt at fejle før man lykkedes. Man fejler ofte ved at prøve noget man ikke er god til, fordi man endnu ikke er i stand til at løse de problemer som der kræves.we-fall-off

Mange er tilbøjelige til at give op der hvor det bliver for svært, fordi vi instinktivt følger de veje vi allerede kender. Disse kræver mindre indsats og er derfor nemmere for hjernen at håndtere. Men hvis ikke vi fejler, så lærer heller ikke noget om hvad vi kan gøre bedre! Et eksperiment fejler således hvis det lykkedes at gennemføre det i første forsøg – for så har vi ikke lært noget. Toyota Kata har et glimrende citat om det:

No problem = Problem

Med andre ord, vi er nødt til at opleve udfordringer / problemer for at vokse med dem. Hvis ønsketilstanden er realiserbart, vil vi, med rette portion af motivation og vedholdenhed når det en dag, igennem en række små eksperimenter som vi lærer noget af. Når vi lærer noget, bør vi fejre, men vi bør også sætte efter det næste ønsketilstand. Vejen til idealet kan være lang, og hvem ved – måske ændrer idealet sig undervejs imens man bliver klogere.

stocksnap_1m9boe7xdz

På den måde kan man altså sige at visionen i sig selv er ikke destinationen. Toyota ser ikke foreløbigt det muligt at opnå 0-defects i deres produktion. Idealer behøver ikke at være opnåelige, men den forbedring man opnår undervejs er det faktiske gevinst man høster. Vi har brug for et ambitiøst mål, både for at definere retningen men også for at nå langt. Der skal mod, dedikation og indsats til for at opnå gode resultater. Men hvor gode de bliver afhænger også af hvor højt man sætter baren (og at man tør at sætte den). Success depends on your challenge.

/Poul

Vi laver jo software til mennesker og ikke omvendt

Behavior Driven Development. Et koncept, en tankegang, en filosofi eller blot en metode. Der er sandsynligvis mange fortolkninger af bevægelsen, som opstod i de agile kredse i tidligere 00’erne (ifølge mine kilde, I må gerne rette mig). Så mens Britney Spears, N-Sync og Christina Aguilera toppede hitlisten på MTV, udsprang der en ide om at TDD (Test Driven Development) kunne gøres bedre ved at fokusere på adfærd. Test i sig selv giver mere værdi hvis udgangspunktet for den er kravene til software, og vi kan udtrykke beskrivelsen af test som krav til den adfærd som forventes af systemet og brugeren som benytter det.

Hvordan startede det? Til at begynde med, var det ideen at ens Unit Test navngives som sætninger der starter med ordet should:

void shouldCalculateAccountBalance()

Dernæst kom BDD frameworks som JBehave, Cucumber som gjorde det muligt at beskrive krav som læsbar tekst med bagvedliggende kode, som omsat skrevne ord til automatiserede handlinger der testede kravene:

Given I log on to the system as System User

When I open account management

Then I see a list of active accounts sorted by modification date, newest first

Vi kom tættere på samarbejdet mellem dem som beskriver behov og dem som realiserer disse ved at udvikle software. Historisk set har der været en opdeling i “forretning” og “IT afdeling” de steder som beskæftiger sig med softwareudvikling. Problemer i kommunikation imellem disse får tit skylden for fejlede IT projekter, men sådan skulle det jo ikke blive ved med at gå.

For det handler jo som sådan ikke om automatisering, når vi snakker BDD. Det handler om at forstå hvilke behov software brugere har under de givne betingelser, og hvordan vi kan understøtte disse ved at lave software som hjælper dem i at opnå deres mål. Det er altså ikke et sæt af features der i sig selv er vigtig. Det er om brugeren kommer i mål – ved at bruge vores software!

Dermed bør vi først og fremmest starte med historien bag scenarierne, vores user story (den famøse WHY)

6808f5b0-594d-0132-0b73-0eae5eefacd9

User Story Example:

In order to provide world class support to our users

As a system administrator

I need to be able to manage account list effectively

Lige præcis denne del af BDD er måske den sværeste del af BDD – langt ud over udfordringer som ustabil browser automatisering, test coverage etc. Definere, hvad prøver vi at opnå og hvorfor? Hvilket formål har aktøren, og hvordan kan dette understøttes med det software vi vil lave?

En masse automatisering uden et klart-defineret formål er som et skib uden en styrmand. For hvis ikke vi hjælper brugeren med at løse opgaven på den bedste måde vi kan, så kan det da være lige meget om testen er automatiseret!

Der er skrevet rigtigt meget om hvad BDD er. Måske kunne det også være relevant at sige noget om det hvad det ikke er:

  • IKKE et projekt der går ud på at automatisere de krav som forretning har stillet. BDD handler først og fremmest om at definere krav sammen med sin forretning og udvikle med udgangspunkt i disse.
  • IKKE en proces som udføres af en enkel person! BDD indebærer samarbejde omkring krav på tværs af roller; f.eks når treenigheden, i form af forretnings-, udviklings- og QA perspektiv, mødes for at beskrive og udvælge nøgle-eksempler på brug af den feature vi har tænkt os at lave. De eksempler hjælper os med at forstå hensigten, og viser hvad de 3 musketerer er enige om 🙂three-musketeers
  • IKKE: En metode til at udvikle software. BDD er en tankegang, der hjælper os med at fokusere på de behov og udfordringer som vores brugere har. Vi kan stadig køre Scrum-sprints eller have en Kanban-tavle. Vi kan stadig skrive test før vi udvikler applikationskode eller udøve pair-programming.
  • IKKE: Noget smart udviklere har fundet på for at få lov at bruge mere tid på teknologi. BDD handler også om overblik og kvalitetssikring; når tests automatiseres løbende giver dette os levende dokumentation af det som allerede er udviklet, indsigt i hvor langt er vi henne i processen med udvikling på de stories som er i vores scope. Dokumentationen giver testere mindre regressions-byrde og mere tid til udforskende test med udgangspunkt i de beskrevne scenarier.

Når det er sagt, så handler det jo først og fremmest om brug af eksempler til at opnå fælles forståelse af det vi ønsker at lave. Det handler om samarbejde.

Historien, og Monty Python har bevist at kommunikationen kan være svær:

/Poul

En nyfødt søgemaskine savner en grundig test…

Søgning er en af betydelig del af det softwareunivers vi har omkring os i dag: shopping, research, underholdning og vidensbaseret arbejde — at komme godt i mål med det afhænger tit af ens evne til at søge… og af søgefunktionens kvalitet.

Udfordringen med at finde fejl bliver først rigtigt spændende når testen er udforskende, og der er få regler – hvilket kan være tilfælde med en ny søgemaskine som websitet lige har fået, og som skal testes og tilpasses til den bliver god og brugbar.

pexels-photo-67112Her kommer så spørgsmålet, hvad er en god søgefunktion? En som virker? (det geniale svar man med garanti kan få ved at spørge sine brugere). Et bud også kunne være: en som nemt, effektivt og hurtigt kan bruges til at finde hvad man har brug for.

Problemet med denne definition er at der nok er lige så mange måder at søge på, som der er mennesker og deri udfordringen — at give de fleste brugere en god og brugbar søgeoplevelse. Det kræver at man kender sine brugere 🙂

Artiklen giver et bud på baby-steps til hvordan man kan komme i gang med at teste sin nyfødte søgemaskine.

Et par ord om teknologi: det kan være værd at kende løsningsarkitekturen når testplanen udarbejdes. Søgemotoren kan både være bygget fra bunden, eller baseret på standard software for at spare tid og undgå at begå fejltagelser som andre har lært noget af. Standard software har den fordel at den er (som regel) allerede testet, både funktionelt, sikkerhedsmæssigt og i forhold til performance. Det betyder ikke at man kan springe testen over, tilgangen og indsatsen er blot anderledes. I dette indlæg vil jeg fokusere på test af tilpassede off-the-shelf søgemaskiner, hjemmebyggede systemer må vente til en anden dag 🙂

Testplanens byggeblokke

For at lave en god testplan må vi forstå problemet og nedbryde det i relevante risko-faktorer som skal undersøges.

Commercial off-the-shelf (COTS) som kan indeksere data og gøre det lynende hurtigt at søge ud fra de parametre som der indekseres på. Eksempler på disse er Microsoft FAST, Apache Solr og ElasticSearch som alle tilbyder en nogenlunde fornuftig analyse af tekst som brydes op i tokens, som man efterfølgende kan søge på.

Relevans

Første risikofaktor må siges at ligge i søgemaskinens evne til at finde relevante data. Som minimum skal søgeresultater indeholder den eller de søgeord som indgår i forespørgslen. Regler for tolkning af flere søgeord skal bestemme hvordan disse fortolkes. Er det:

  1. “AUDI” og “2.0”
  2. “AUDI” eller “2.0”?

Resultater kan være ganske forskellige, alt efter hvilken tolkning vælges.

Måden som søgemaskinen fortolker det indhold som der kan søges efter kan også bestemme hvor relevante resultater det giver. For eksempel nedenunder viser hvordan Elastic Search nedbryder en sætning i ord ved hjælp af standard implementationen:

skaermbillede-2016-12-06-kl-21-19-51
Sætningen “The 2 QUICK Brown-foxes jumped over the lazy dog’s bone.” bliver til en række søgbare ord

I dette eksempel opfattes bindestregen som en separator mellem to forskellige ord. Men i virkeligheden kan vi finde på ord som ikke skal deles op i to af et specialtegn: Wi-Fi, B&O, O’brian. Specielle tegn kan i sig selv være en del af søgeordet, f.eks: iPad Pro 9,7″.  Og hvad hvis man skrev 9.7″, eller 9.7 tommer – burde alle tre ikke give de samme resultater? Hvis man gerne vil hjælpe brugere der formulerer sig forskelligt og implementerer disse regler, vil det give anledning til en række specielle cases man kunne indføre som en del af regressionstesten for søgemaskinen.

Specielle cases

Kort sagt, specielle cases er en slags synonymordbog med specielle begreber som defineres for at hjælpe med at finde ting som ikke har en uniform/standard stavemåde (indførelsen af disse er med til at holde problemet i live, men det er en anden diskussion). Når man har/finder eksempler, kan disse blive til test cases – gerne i en automatiseret test-opsætning.

Eksempler:

  • Tjek unicode tegn: Kødpålæg, André, Citroën og Bülowstraße – find dine ord ved at kigge på indholdet eller brug en facitliste over tilladte og forbudte specialtegn til at lave cases med ord som burde og ikke burde kunne søges frem
  • Relevans af søgeresultater med sammensatte ord: søgning efter iphone 7 bør først og fremmest indeholde modeller med 7 tallet, og ikke tidligere iphones version 6, 5 osv.
  • Dele af søgeordet. Man søger sjældent på hele ord eller en sætning eksakt. F.eks –Maxi i stedet for MaxiCosi når jeg søger efter en autostol
  • Tekstanalyse: søgemaskiner kan kende til sprogets struktur og bøjninger, for at hjælpe brugeren med at finde relevant indhold. F.eks ordet cykel, kan også optræde som cykler eller cyklerne i teksten. En speciel case jeg har oplevet var udtrykket “Anders and”, som blev transformeret til “And and” af den generiske danske tekstanalyse, og derfor var skyld i at der ikke var muligt at finde blade med dette navn 🙂
  • Synonymer, hvis systemet oversætter udvalgte ord til andre. F.eks betingelser og vilkår, som kan have samme betydning for brugeren
etilbudsavis-opdatering
Et godt eksempel på forbedringer til en søgemaskine er denne opdatering af app’en eTilbudsavis. Her forstår man altså, at ikke alle kan stave til Anthon Berg i juletravlheden

Automatiseringsstrategi:

For at spare sig selv tid, er det en rigtig god ide at automatisere test af disse cases. Hvis det kan lade sig gøre at isolere den komponent som håndterer reglerne, kan unit test være en hurtig og stabil måde at sikre at specielle regler bliver testet så snart testen køres.

Søgeforslag

De fleste er efterhånden vant til “suggestion” – forslag ud fra den mængde tekst som allerede er indtastet. Derfor en del af søgningen kan være forudgående søgning efter det rigtige søgeord — en process hvor brugeren får forslag på sætninger som delvist matcher det som allerede er skrevet.

skaermbillede-2016-11-30-kl-22-39-24

At teste disse kan være en case i sig selv, og her gælder de samme regler for specielle cases som er beskrevet tidligere.

Paging

Der kan være mange søgeresultater, måske for mange til at være på en side. Bladring mellem siderne er en lidt hemmelig funktion, som er nem at overse.

  • Relevans af søgeresultater. Søgning kan blive totalt irrelevant på side 2.
  • Samme søgeresultater som optræder på flere sider
  •  Er der en ende? Af en eller anden grund kan man blive fristet til at finde den sidste side med resultater

Opdateret indhold

Når indholdet, som der kan søges på, ændres skal dette reflekteres i søgemaskinen. Her kan det være flere scenarier at kigge på:

  • Hvor hurtigt slår opdatering igennem for brugeren?
  • Hvis der skal opdateres, eller genindlæses en stor mængde af data – vil dette kunne fejle? – Hvis jobbet som udfører indeksering stopper på grund af en fejl, vil vi aldrig få opdateringer ud til brugeren og det kan være meget svært at opdage uden en overvågning af status og logs for indekseringsprocessen.

Performance

Performance kan være en vigtig kvalitetsattribut for en søgemaskine. Bare se hvordan det er blevet en konkurrencefaktor for Google. Ingen brugere gider at vente alt for lang tid på indlæsning af søgeresultater og søgeforslag er ligegyldige hvis brugeren når at taste færdig og trykke Enter.

COTS søgemaskiner kan konfigureres med forskellige indstillinger, og derfor er det både muligt og nødvendigt at “tweake” disse for at opnå bedre resultater.

En interessant tilgang jeg kom omkring var denne videnskabelig test af ElasticSearch performance: https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html

Som tester, er det godt at kende de søgninger som er “tunge”. Det kunne være dem som søger meget bredt, f.eks et tomt søgeord som vil matche alt (eller intet om speficikationen vil). Det kunne også søgninger på tværs af flere kilder/databaser, eller søgning i data som tilfældigvis ikke er indekseret efter de parametre som der søges på.

Sikkerhed

Sikkerhedsproblematikken er et emne i sig selv som bliver svært at dække med få ord.

Generelt kan man sige at fritekstsøgning, ligesom andre funktioner der tillader brugerinput, kræver fokus på sikkerheden. Det kan være taget hånd om i standard systemer, men ikke desto mindre er det nødvendigt at udforske mulige sårbarheder som kan afsløre mere data end nødvendigt, tillader manipulationen af det indekserede data eller kompromittere systemet på en anden vis.

Der er naturligvis også sikkerhedsaspektet i at præsentere søgeresultater for brugere, som kan indeholde ondsindede scripts og derfor skal tages hånd om.

Opsummering

Typiske og specielle cases kan være gode at få styr på, når søgefunktionen etableres. Hvis søgning er et af de mest afgørende funktioner for systemet, er det en rigtig god ide at automatisere de gængse og typiske søgninger som man efterhånden lærer af sine brugere (ved hjælp af logning og analytics)

Foruden for typiske funktioner, som visning af søgeforslag, resultater og filtre, er der også parametre som performance og sikkerhed som kan være vigtige at tage med i betragtning.