10 udfordringer som en agil tester

Efter at have rundet 6 år som en praktiserende agil tester, ser jeg ofte de samme udfordringer der går igen og igen. Det blev til en slags mental tjekliste for mig, som begyndte at tage form i løbet af det sidste år, når jeg startede med at bruge min erfaring som en rådgivende konsulent.

De 10 udfordringer viser sig at hænge sammen med nogle af de grundlæggende principper, der i virkeligheden er stykker af sund fornuft, der nogle gange udebliver af forskellige årsager.

De ting, vi siger til hinanden, når vi møder disse udfordringer, rummer ofte svaret på hvordan udfordringen er opstået – hvis man relaterer disse udsagn til de gode principper, som jeg vil opliste i denne artikel.

1. Gøre kvalitet til et fælles ansvar på teamet

At man kører projektet agilt er altså ingen undskyldning for ikke at teste! Som testere og QA ansvarlige er vi pionerer for kvalitet, og det indebærer at arbejde for at alle tænker kvalitet ind fra starten. Nogle gange lykkes det, andre gange ender vi alene med ansvaret.

Tid - Fælles QA ansvar
At der ikke er tid til test er ofte udtryk for, at der ikke er fokus nok på det. Er teamet enig i, at testen er en del af sprint målet og den samlede leverance?

“Testfaser” til sidst i sprintet, hvor alle defekter skal findes af testeren alene, er ofte udtryk for at ansvaret er placeret på et smalt sted.

Kvalitet - Fælles QA ansvar

At stå selv med ansvaret for kvalitet kan blive en tung og udmattende opgave for en enkel person, når hyppigheden af ændringer og fejl svinger meget. Måske kan teamet finde en fælles strategi – en QA-strategi – for at definere, hvordan alle kan bidrage med deres evner og kompetencer til testen. Strategien sikre at alle ved hvad de andre gør i forhold til kvalitetssikring, og denne information er meget værdifuld når det nogle gange går stærkt.

2. Skaffe den rette information på det rette tidspunkt

Arbejdet med afklaring af krav og udvikling foregår ofte i et andet tempo, når man kører korte iterationer/sprints. Man kan derfor opleve, at det er sværere at følge med i det hele.

Manglende viden - Kommunikation

Knap så megen dokumentation og viden der mest deles i forskellige samtaler, kan gøre det sværere at følge med i alle relevante detaljer og beslutninger.

Ideelt snakkede alle med alle på de rigtige tidspunkter, men når dette ikke sker, har vi udfordringen med manglende viden. Det er mindre kritisk på et team, hvor kvalitetssikring er et fælles ansvar, fordi der er en chance for, at nogen af de andre griber bolden. Alligevel kan viden om hvem, der har testet hvad, være nyttigt i det store perspektiv.

Fælles forståelse - Kommunikation

En anden side af det er forståelsesaspektet i de samtaler som finder sted på teamet. Et mangfoldigt team med både tekniske, analytiske og forretningsfaglige personer kan have et større spænd i deres fokusområder og faglige sprog. Tværfaglige teams forsøger at nedbryde siloer, men det kan stadig være svært at forstå alle aspekter af hinandens arbejde. Vi kan godt være eksperter i hver vores felt – QA/arkitektur/kodning – men vi er ikke alene om at bære ansvaret for kvalitet!

3. Kommunikere den rette information på det rette tidspunkt

Teamet har brug for hinandens viden for at være effektive. Det, vi kommunikerer ud, kan have afgørende betydning for succes med opgaver og projektet i helheden. Sagt med andre ord – jeg kan løse opgaven bedre og hurtigere, hvis først jeg taler med nogle, der har den rette viden og erfaring med netop den slags af problemstilling, som jeg selv sidder med.

Men i den gode tro, er det nemt at blive kloge-åge som rådgiver alle om alt, og måske slet ikke på opfordring.

Image result for kloge åge

Tanken er sikkert god – modtageren kunne få brug for den viden senere, men der er også risiko for information overload: Når vi prøver at sætte fokus på mange facetter og detaljer på en gang kan overblikket sløres, og det gør mere skade end gavn.

Set fra en anden side, kan vi blive for påpasselige med at snakke sammen. En Scrum Master kan blive så god til at afskærme folk, at de slet ikke må tale sammen uden en tilladelse.

Image result for network of people visualization

Det burde ikke handle om at minimere small talk, for det er ofte sådan folk opdager andre ved noget, som er relevant og spændende for dem!

Måske handler det om at få skabt en kultur hvor vi med tiden lærer hvordan vi bedst kan understøtte hinanden med den viden vi har, lige såvel som den bedste måde at overlevere den viden på.

4. At kommunikere effektivt og med respekt

Ud over mængden af kommunikation, er det også måden man kommunikerer på, som er afgørende. Det er især vigtigt, fordi agile projekter i højere grad afhænger af god og effektiv kommunikation og mindre overlevering af arbejdet, mennesker imellem. Vi kommunikerer altså mere med hinanden og sandsynligheden for, at det ikke altid går som smurt, er bare større. Det sker, når vi får sagt ting, som vi ikke mener, eller ikke har tænkt os om og bare lader os påvirke af øjeblikket og den situation vi står i.

Respekt - Kommunikation

God kommunikation kan blive sværere under tidspres, konstante forandringer og ikke mindst problemer af projektmæssige karakter. Når det sker, har teamet stadig brug for at kunne tale sammen effektivt og beholde respekten for hinanden, for at kunne klare de udfordringer der opstår.

Det siges at både afsenderen, modtageren, iagttageren og autoriteten har deres andel i at sikre, at den gode kommunikation bliver opretholdt. Det kræver at: afsenderen er klar over effekten af sine udmeldinger, modtageren kan sige fra, mens iagttageren og autoriteten som minimum bør blande sig når det gælder.

Nogle vil sige at årlig kommunikation på grund af stress og tidspres kunne være symptomer på helt andre udfordringer med samarbejdet i teamet, der starter med den måde hver enkel på teamet vælger at prioritere sin tid på.

5. At kunne prioritere sin tid og opgaver

I agile projekter hvor man arbejder sammen som et team, er det teamet og teamets mål som vægtes højest. Når man konsistent vægter egne opgaver og mål højere, løber man risikoen at hele teamet taber som en helhed. Man har altså større ansvar overfor andre, når vi sidder i samme båd.

Tasks - Prioritering

Sat på spidsen, betyder det at man hverken får point for ikke-testet kode eller forberedelse af testen der aldrig bliver til noget. Den daglige status belyser teamets fokus og udfordringer. Kunsten er at være i gang med de opgaver, som bidrager til at der bliver leveret mest muligt værdi i sidste ende. (Og ja det er en svær øvelse som de modne teams mester). I sidste ende er det bedre at få en del af pakken som virker helt, end at få hele pakken som virker halvt. Det er her den større grad af samarbejde viser sit ansigt.

6. At komme tættere på udvikling og kode

I stedet for at finde mange fejl til sidst, giver det langt større afkast at arbejde sammen på at gøre et godt stykke arbejde første gang. Tidlig test giver mulighed for at rette fejl billigere og hurtigere, men det kan give udfordring når det der skal testes er alt andet end noget man kan klikke på i brugergrænsefladen. Det kan være services, komponenter og kodestumper som returnerer talbaserede koder. Det kan også være datamodeller og databaser opsætninger, som kræver adgang og kendskab til værktøjer.

Tidlig test - Samarbejde

Ikke tekniske testere kan godt finde flere veje og måder at bidrage til den tidlige test, men kan med tiden indse fordele ved at have mere af det tekniske know-how. Det betyder i princippet også at komme tættere på automatisering. Gentagne opgaver, klargøring af test miljøer, oprettelse af test data og naturligvis også test automatisering kan være gode eksempler på situationer hvor det kan betale sig at kunne kode en smule. Imens andre koder features..

Men skal vi under enhver pris kunne kode for at være agile testere? Måske ikke.

7. At kunne tilpasse sig teamet og deres behov

Alle teams er forskellige, men specielt i de agile teams er der mindre fokus på roller. Opgavens art kan variere, nogle gange kan der være rigtigt meget test og alle skal hjælpe til med at teste. Andre gange er der for lidt og man må begå sig ud i andre typer af opgaver hvis ikke man vil sidde på sine hænder og vente på test opgaver.

Kompetencer - Team

Det kan resultere i at man selv lærer at producere sine egne test data, snakker selv med brugere for at bedre kan forstå deres adfærd eller skriver et selenium script til at teste den skrøbelige test case som altid bliver glemt eller ofte fejler. Vi kan blive mere effektive som et team når vi er mindre afhængige af bestemte personer til at løse en bestemt type af opgaver. Vi behøver ikke alle at være generalister, men chancen for at bidrage positivt er større når man kan andet end en bestemt kompetence!

Kigger man på teamets omgivelser, miljø / organisation og netværk af eksterne kontakter, finder man andre muligheder for at hjælpe teamet med at fungere mere effektivt.

8. Tættere og oftere samarbejde med forskellige roller og aktører

Ud over det daglige samarbejde på teamet omkring produktudvikling opstår der ofte behov for at arbejde tættere sammen med andre aktører udenfor teamet. Det kan både være nogle, som hjælper med en bedre forståelse af brugerbehov og adfærd. Det kan også være eksperter i forskellige former for test, eksterne leverandører og testere der understøtter den samlede leverance.

Indsigt - Samarbejde

Tættere samarbejde indebærer tillid, både i og udenfor teamet. Tilliden kommer som bekendt ikke på en dag, og organisatorisk ballast som mistillid mellem afdelinger, tidligere rivaler og erfaringer med kunder kan gør det sværere at få opbygget den mængde af tillid som reducerer behov for forhandling, kontrol og andre sikkerhedsforanstaltninger som følge deraf.

Vi bør som minimum være indstillet på, og have viljen til at investere i den gode samarbejde. Blame-game er nemt at falde i når man ikke ser sin andel i en verserende konflikt. Selv om mange af disse udfordringer ikke kan løses af enkelte personer alene, så er det lige som med MJ og Ghandi: start med sig selv og vær den forandring du gerne vil se hos andre.

Konflikter og dårligt samarbejde er uundgåeligt en af de større former for spild af tid, kræfter og ikke mindst ressourcer.

9. At minimere spild

Der findes flere måder at identificere og håndtere spild, lige fra Lean til Design Thinking og andre mainstream koncepter. Som en agil tester bliver man helt sikkert mærket af den større fokus på feedback og forretningsværdi i agile projekter, og det giver anledning til at kigge indad og revurdere de processer vi følger med kritiske øjne. F.eks. bruger vi for meget tid på de typer af test som ikke hænger sammen med risikoprofilen? Eller: Er niveauet for den dokumentation vi producerer den rette?

Dokumentation - Spild

Når vi ikke bruger vores tid rigtigt får vi mindre tid til andre ting og måder at støtte de opgaver som kunne været vigtigere at løse. Imens forretnings-impact er givet af backloggens prioritering, er det dog stadig op til vores analytiske evner og tidligere erfaringer at vurdere hvor er der størst sandsynlighed for at introducere defekter. Risikohåndtering i det hele taget er noget af den mest gennemgående aktivitet som man have berøring med som en agil tester.

10. Holde øje med risici på projektet

Klassisk risikoanalyse forud for, eller i projektets opstartsfase, er ikke tilstrækkelig på de agile projekter. I starten ved vi mindre om hvad vi ikke ved, og når vi bliver klogere dukker der som regel nye risici op som har betydning for mængden og typen af den kvalitetssikring som teamet kommer til at udføre.

Her er vi så tilbage til starten — QA som fælles ansvar. For selv om man som tester er klar over risici, er det da ikke sikkert man har mulighed for at få gjort noget ved dem alene, og man blot kan stå og se på korthuset vælte.

card-tower-fun-game

Kommunikation, samarbejde og fælles indsats, komplementeret af indsigt i produkt og projektrisici, giver teamet netop mulighed for at være agile – at kunne navigere i den komplekse virkelighed sammen og forsøge at gøre det mest rigtige på det rigtige tidspunkt.


Dette var de 10 udfordringer man kan møde som en tester på agile projekter. Har du kommentarer eller bidrag til ovenstående er du meget velkommen til at kontakte mig.

Reklamer

Jeg ville teste robotten, men den endte med at teste min tålmodighed 

Revolutionen kommer, og hellere være klar til den end at sove i timen med håret i postkassen. Robotterne har bare at gøre vores liv nemmere og forandringen syntes at rykke nærmere. Ikke kun i version2 artikler, linkedin-publikationer og lign men også vor eget hjem.

En lidt lørdag morgen ville gøre noget jeg har drømt om længe – at overlade støvsugningen til den selvvalgte julegave fra shoppen som firmaet valgte at samarbejde med i år (derfor var hverken mærket, modellen eller specifikationen mit valg – selve muligheden at få en robotstøvsuger resulterede i et eksperiment).

Dette er ikke et produkt anmeldelse, så mærket og modellen er ligegyldig. Rent funktionelt har apparatet en lille grænseflade og en række tilstande den kan være i afhængigt af omstændigheder: den kan køre i cirkler, zig-zagger og andre mønstre for at dække det valgte områder på den mest effektive måder. Dette kunne man udfordre fra test perspektivet! Tænk nu hvis man kunne påvise den ikke var effektiv… Men dette var ikke målet med testen.

Skulle det vise sig apparatet ikke var effektiv nok, ville det ikke gøre nogen forskel. Jeg ville ikke kunne bytte den, og så kunne vi nok også leve med det. Den første “udforskende” pilot test har dog vist en interessant tvist.

Som nævnt er der få triggers som kan kan interagere med.

  • Tænde/slukke
  • Sætte den til opladning
  • Sætte den i ugyldig tilstand (så den ikke kan køre), f.eks på hovedet.

Bagsiden afslører at man ydermere kan pille batteriet ud, men så er det lige som det. Manøvrering og køreegenskaber kan testes i uendeligt mange situationer (og jeg skulle hilse og sige det går ret hurtigt med at finde situationer hvor den går i stå). Men hvad nytter det, hvis der ikke er strøm nok?

Test fokus

Opladning. Naturligt nok kræver det nok strøm til at kunne arbejde effektivt i nogle timer. Efter at have støvsuget køkkenet og gangen på sin jomfru tur, tog den sig en velfortjent pause. Næste gang jeg sad klar med en bog og en kop hjemmebrygget latte, ville banditten ikke køre mere en et par sekunder! En fejl lyd og rød blinken indikeret der var tid til lidt power.. Jeg synes det var lidt tidligt, for den har jo næsten ikke kørt i en time!!

Manualen. Teksten som skulle forklare mig den korrekte fremgangsmåde (som dermed kunne testes) var formuleret mystisk. Specielt punkt nr.5

Altså, sådan som jeg forstår det så tager det sammenhængende 4 timer for at apparatet er opladet 100%. Dog, hvis strømmen afbrydes undervejs vil den “always timing from zero automatically” — altså timeren bliver nulstillet og det begynder at lyse blot senere end sluttidspunktet for opladning. Lad være med at afbryde strømmen undervejs, siger den mere eller mindre, for så ved du ikke hvornår du kan afkoble adapteren med mindre du bruger et stop ur. (Husk nu at strømforbrug er en del af effektiviteten).

Så der har vi et par test situationer mere!

  • Opladning fra 0 til 100%, uafbrudt
  • Opladning fra 0 til 100%, afbrudt undervejs x gange
  • Opladning fra x til 100%, uafbrudt
  • Opladning fra x til 100% afbrudt undervejs x gange

Ny artikel om QA strategi på agile teams

For noget tid siden skrev jeg en blog om, hvorvidt QA skal være en del af agile teams. De tanker var skrevet i kontekst af forberedelse til Certified Agile Tester kurset, og det er en sjov læsning for mig i dag.

Et par erfaringer klogere har jeg begået mig ud til at skrive en lille artikel, der tager emnet videre til et spørgsmål om strategi. Egentlig er det jo ikke et valg baseret på præferencer! Om teamet skal have en dedikeret tester/QA afhænger af QA strategi for projektet/produktet.

Man kan godt forestille sig projekter uden en QA strategi, og beslutningen om at få en dedikeret og erfaren QA person kunne være begrundet i et ønske om at få skabt sådan en strategi. Og endelig, en mangel på strategi kan også være en strategi i sig selv…

Ikke desto mindre, her er lidt læsning til alle interesserede: (PDF, 2 sider, på engelsk)

Strategy for agile development teams- with or without dedicated QA
Article screen Udgivet 02.12.2017

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

 

Test af søgeagenter

Denne blog handler om søgeagenter og nogle tanker omkring kvalitetssikring af disse. Hvis du ikke ved hvad søgeagenter er, så læs med videre – ellers hop til næste sektion hvor det handler mere om test 🙂

Har du nogensinde gået målrettet til værks for at finde gode tilbud? Ikke alle besidder den nødvendige mængde af tid, tålmodighed, struktur og planlægningsevner til ugentlig gennemgang af reklameaviser som far og mor gjorde det.

Det er heldigvis blevet nemmere at holde øje med tilbuddene, for tilbudsaviserne og diverse varekataloger er blevet digitale. Det er nemmere end aldrig at læse reklameaviser ved hjælp af diverse tilbuds apps. Og hvis det skal være rigtigt smart, så fortæller man app’en hvilket tilbud man gerne vil få besked om og så snart Cola er faldet under de 10 kr/ltr. så ligger der en mail eller en besked i app’en om det!

sogeagent-colaEn opsætning af søgeagenten i appen MineTilbud kan se sådan ud:

Jeg har valgt kategorien “Cola”, hvilket giver mig mulighed i app’en at vælge flere forskellige mærker af denne sodavand. Så har jeg valgt maks. pris på 20kr, samt volumen pris på 10kr hvilket forudsætter at jeg går efter 2L  flasker til maks 20kr stykket (+pant).

Som resultat, har jeg en søgeagent som vil holde mig underrettet når nye tilbud som matcher mine kriterier dukker op. Set ud fra QA perspektiv, er der lidt mere i det med hensyn til test.

Hvordan tester vi søgeagenter?

Man kunne starte med at definere en smoke test. En simpel test, som bekræfter at søgeagenten virker i det hele taget. Mit Cola eksempel fra det forrige afsnit kunne sagtens bruges men med en lille krølle på halen: det ville være rart hvis vores smoke test var automatiseret i et kontrolleret test miljø, så vi ikke skulle vente på det rette tilbud skulle komme for at kunne udføre den 🙂

Det næste kunne være at komme omkring søgeagentens funktioner på en mere struktureret måde. Der findes nærmest uendeligt mange måder at specificere søgninger og derfor giver det mening at starte med at finde ud af hvilke muligheder for søgeagent-søgning er der. De muligheder vi identificerer vil være vores test situationer:

  1. Fritekst søgning
  2. Søgning inden for en eller flere valgte kategorier
  3. Kombination af ovenstående to “principper”
  4. Kombination med flere mulige valg af filtre, f.eks Mærke, maks pris
  5. Kilder, hvor der skal søges. Det kan være en samlet database, eller data fordelt på de forhandlere som tilbyder varen.
  6. Hyppigheden af agent udsendelse af notifikationer til brugeren. Typisk, ugentlig, daglig eller straks. Det er dog ikke alle søgemaskiner som tilbyder dette valg direkte til brugeren. Dog kan det batch-job som udfører søgninger og sender mails være planlagt forskelligt alt efter scenariet, som kan give input til.

Hver en test situation kan testes med en eller flere test cases, afhængigt af den ønskede dækning. I denne blog vil jeg ikke gå i dybden med alle mulige typer af test man kunne opstille. I stedet vil jeg fokusere på en væsentlig teknik, nyttig til test af søgning generelt, og derfor også til søgeagenter som er baseret på dem.

Ækvivalensklasser

Mængden af mulige input til eksempelvis tekstinput kan være stor. For at kapere det, kan vi opdele de mulige tekstinput i nogle ækvivalensklasser efter deres virke. To simple klasser kunne være:

  • Søgninger der giver ny gyldige resultater (positiv case); forvent søgeagenten udsendes efter indstillet frekvens.
  • Søgninger der resulterer i 0 resultater (negativ case); forvent søgeagenten ikke bliver udsendt

Den første klasse rummer alle valide søgninger og kan være i klasse for sig selv, hvis søgning kan abstraheres i forhold til søgeagentens funktionalitet. Det kan ske hvis agenten bruger en eksisterende søgemotor, som er testet / kvalitetssikret på anden vis (typisk med automatiseret test) .

Det interessante ved at arbejde med den anden klasse er at der tit gemmer sig oversete scenarier, både i forhold til test men også produktdesign generelt.

Test af noget som ikke er der

For at komme ind på det som jeg gerne vil fortælle om, lad os tænke: hvad hvis jeg nu gerne vil have en agent med tilbud på noget som ikke er i reklameaviserne endnu men kommer med garanti. Et godt eksempel er Google Pixel telefon, som i skrivende stund er markedsført og reklameret på samtlige mobil og tech medier, men som endnu ikke er til salg i Danmark! Jeg vil da meget gerne kende den dag hvor telefonen bliver sat til salg?

Lad os lave en udforskende test med forskellige app’s og se hvordan de håndtere scenariet med at søge efter noget som endnu ikke er til salg.

MineTIlbud til Androidscreenshot_2016-10-26-16-08-19_fotor

Jeg har allerede været i gang med denne app i starten af denne blog. For at kunne lave en søgeagent, kræver det at jeg enten vælger eller fremsøger en kategori. Det er en produktbeslutning der på en måde er det ok, da det reducerer jo muligheder for at fortolke ord i kategorier som ikke er relevante for mig som bruger. Det giver en højere præcision, hvis jeg som bruger selv skal vælge en kategori der matcher bedst. Men desværre, betyder det at jeg ikke kan lave en søgeagent på Google Pixel!

Pricerunner

Produktet har funktionen prisalarm, som er ikke tilgængeligt via hverken iOS eller Android apps. Derfor kigger vi på websitet.

skaermbillede-2016-10-26-kl-14-43-23

Man skal have fremsøgt en vare før man kan benytte knappen, men desværre er der ingen pt. der sælger googles nye flagskib af en telefon: søgning på Google pixel giver nogle resultater i covers og tasker til produkter som er endnu ikke til salg. Man kan derfor ikke bruge prisalarm, da der ikke er nogen vare (endnu).

Jeg prøvede også at vælge Google som mærke i rubrikken mobiltelefoner, men denne gav mig kun oversigt over eksisterende Nexus mobiltelefoner og ingen mulighed for at abonnere på notifikation af nyoprettede produkter i kategorien.

DBA

På dba.dk kan man oprette en søgeagent ved at lave en søgning, og uanset om der er resultater eller ej kan jeg gemme søgningen.

Vi søger efter google pixel i mobiltelefoner:

http://www.dba.dk/mobil-og-telefoni/mobiltelefoner-og-tilbehoer/mobiltelefoner/maerke-google/?soeg=pixel&sort=listingdate-desc

Selv om der er ingen annoncer, kan tilmelde sig en annonceagent der enten sendes straks ved ny annonce (hvilket er at foretrække for mig) eller sendes opsummeret en gang dagligt.

skaermbillede-2016-10-27-kl-19-15-55

 

Dette giver mindst to test cases for søgning som ikke returnerer nogen resultater, og der forventes at der er oprettet en aktiv søgeagent i systemet med den e-mail adresse som er angivet.

Bilbasen

Men det kunne også være jeg gerne vil være den første til at vide når der indrykkes en bil af netop det mærke, årgang og i det prisinterval som jeg ønsker. På bilbasen.dk er der også en mulighed for en gemt søgning og mailnotifikationer ved nye søgeresultater.

Men hvis jeg f.eks ønsker mig en VW Polo fra 2016, som maksimalt har kørt 25.000 km og jeg er helst vente på en bil der bliver sat ned til under 150.000, så ser min søgning pt. ikke at kunne give nogen resultater.

skaermbillede-2016-10-27-kl-19-25-50

Der findes mange grunde til hvorfor forskellige tilbuds og shopping sites vælger at lave deres forretningsregler som de er. Som en professionel tester har man stadig mulighed for at opdage fejl og mangler i kravspecifikation, læst med brugerens briller på. Deraf kan man både i form af kvalitetsanbefaling og som et oplæg til en diskussion belyse de tilfælde som kan være væsentlige og nyttige for brugeren. Her er der selvfølgelig altid risiko for at de falder i kategorien “nice to have” 🙂