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” 🙂

Reklamer

Softwaretesters take på Internet of Things

For nogle dage siden var jeg til et morgenmøde, hvor test af Internet Of Things (IoT) var temaet. IoT er et begreb som for tiden rører sig meget i medierne: smarte biler, smarte hjem, stadig flere smarte ting lige fra termostater, kaffemaskiner og kropsbårne enheder (wearables) som kan mere end vores forfædre turde at forestille sig.

Inden for de professionelle kredse af softwaretestere er der bestemt også interesse for muligheder og ikke mindst udfordringer med håndtering og test af sådanne systemer. Det er klart at revolutionen kommer, spørgsmålet er nu hvor godt vi er klædt på til den. Ikke kun som forbrugere men også som dem skal skal være med til at bygge systemer beståender af mange forskellige forbundne “dimser”; eller lad os kalde dem “Ting” for at holde i samme spor med alt andet læsestof som findes derude om emnet.

Ting – hvad for noget?

Hvad er “Ting” for noget, blev der givet et godt bud på af Anders fra virksomheden Sputnik5, som blev inviteret til at sætte scenen for snakken om test af IoT. Man skelner mellem:

  • Industriel IoT – med eksempler som transport og de tunge maskiner, smarte byer, automatisering, fabrikker og sundhedspleje
  • Forbruger IoT – med mobiltelefoner, TV, wearables, apparater, overvågning og automatisering af hjemmet (smart homes)

Ideen med “ting” er ikke helt ny, som en af deltagere gjorde opmærksom på. En ting er noget fysisk, som man kan kommunikere med. En ting kan nogle gange måle, sige noget eller udføre en opgave. Således, i stedet for at være en passiv måleenhed, være en udførende objekt. Embedded udvikling inden for målere, fjernstyrede enheder osv har eksisteret i noget tid og derfor burde vi kunne drage på de erfaringer som industrien har gjort sig med det. Det nye er de mange muligheder for at kombinere “ting” i systemer af forbundne enheder, som til ethvert tid kan fungere som et samlet system. Det er som med lego klodser, du kan bygge lige hvad du har brug for.

Et godt eksempel på lego klodser inden for IoT er tjenesten IFTTT. Denne leverer mekanismen til at forbinder “ting”, webtjenester, apps etc. sammen ved hjælp af opskrifter: hvis der sker en hændelse, f.eks hvis man ejer en FitBit fitness tracker så kan kaffemaskinen startes når denne registrerer man er ved at vågne. Eller at lyset (Philips Hue) slukkes automatisk, så snart ens telefon registrerer man forladt hjemmet.

img_1218
Eksempel på opskrifter i IFTTT som forbinder Ting og Apps sammen

Der er et utal af forskellige kombinationsmuligheder i programmet fordi resultat hændelsen kan være triggeren til det næste event! Kæder af events, domino-effekten og evige løkker popper straks oppe i testerens hoved.

Konsensus på mødet var at vi som professionelle testere ikke nødvendigvis kan bruge de erfaringer med traditionel test af programmel uforandret. Vores “værktøjsbælte” af metoder, teknikker og ekspertise skal opgraderes for at svare til de udfordringer som IoT introducerer.

Komme i gang med at teste

Hvad gør man så, når man skal i gang med at teste en opsætning af IoT?

Oplægget af Gitte Ottosen var med til at give nogle bud på løsninger til disse udfordringer. Første jeg syntes var en god start var: start med at teste isoleret. Der blev givet bud på isolering af de forskellige lag i IoT arkitektur.

Test i lag

Arkitekturen i en IoT opsætning kan være sat sammen forskelligt, men baseret på det vi har set indtil videre kan vi skelne mellem “Ting”, broer som forbinder dem med andre objekter, datalag som håndtere de tit enorme mængder af aggregeret data og ikke mindst Apps som kan nogle gange ses som interfaces til “Ting”. F.eks min nykøbte Trackr enhed som kan spore nøgler via min mobil er et mini eksempel på sådan en opsætning. Dette system har 4 lag: En app (både til iOS og Android), Bridge, enheden og så data laget hvor enhedens og app’ens data gemmes. App’en kommunikerer med enheden (“Tingen”) over bluetooth (Bridge) og ved hjælp af telefonens GPS kan måle afstanden til nøglerne og endda vise seneste kendte position (data fra datalaget). Det er en simpel opsætning, og når jeg har sat trackeren i nøgleringen, hentet app’en og parret de to da kan jeg komme i gang med at teste!

img_1226
En Trackr som sidder i nøgleringen
screenshot_2016-10-07-16-44-10
Opsætning af indstillingerne i Trackr app’en

Ved at følge test isoleret princippet kunne jeg starte med app’en, lege lidt med bluetooth forbindelsen over forskellige afstande for at konstatere murværk og metal har en betydning, og til sidst kunne jeg prøve at teste dimsen fysisk: jeg kunne have den i lommen sammen med noget andet skrammel for at teste robustheden, jeg kunne udsætte den for lidt vand, lægge den ved siden af WiFi routeren eller trykker på den eneste knap denne har i rigtigt rigtigt lang tid… Tjo, jeg må indrømme jeg har ellers svært ved at finde på andre gode scenarier til test af dimsen, fordi den er ny for mig og de ting jeg ved om dennes kunnen stammer fra den lille manual som fulgte med. Mere dybdegående test kræver mere domæneviden, eller ekspertise. Andre mere komplicerede “Ting” vil sikkert underbygge pointen endnu bedre. F.eks test af Google Home som indebærer kommunikation med kunstig intelligens!

For mig har isolering af lag også en parallel til Contract Based Testing. Jeg sætter ikke lighedstegnet i mellem disse men hvis vi antog at både apps og “Ting” var enige om formatet for de kald som forbinder dem, så kunne man da teste “Ting” / apps hver for sig op imod den etablerede standard. Det er som med protokoller, og det rent funktionelt betinget. Men da ting kan have andre kvalitets karakteristikker, såsom sikkerhed, pålidelighed, brugbarhed (usability) og man kan vælge de rette kvalitets-attributter som passer til hver lag og dermed også definere hvilken ekspertise er der behov for i den pågældende test.

Test som helhed

Men vi skal ikke glemme teste det hele som helhed. For når man har sat en række “Ting” sammen, kan der opstå problemer med samtidighed, kommunikationsfejl, domino-effekten osv. Og så er det selvfølgelig sikkerheden, data flow og integriteten af hele kæden. Derfor tænker jeg at der er mange grunde til at udføre en end-to-end test oven på testen af de enkelte IoT arkitekturlag.

Man kunne starte med at opstille et solskins-scenarie ved at vælge en typisk sammensætning. Jeg har allerede udført en typisk testcase i tilfælde med Trackr: jeg kunne finde enheden vha telefonen, og enheden kunne hjælpe med at spore min Android-baseret mobil. Jeg kunne har testet de samme scenarier for iOS platformen. I situationer hvor antallet af platforme er større, er valget af konfigurationer ret afgørende, og burde repræsentere typiske eller ønskede sammensætning.

Eksempelvis kan man teste Galaxy Gear S Smartwatch med en hel række understøttede mobile devices. Men måske skulle man starte med Samsungs egne Galaxy telefoner, som (måske) vil være det oplagte valg for en bruger som har købt sig en smartwatch fra Samsung. Brugsstatistikker kunne med garanti give det bedste bud, og skabe grundlag for risiko-baseret tilgang til valg af flere typiske konfigurationer: vælg dem som er forretningskritisk at understøtte. Er der stadig for mange, fordi vi vil understøtte alt, start fra toppen af de mest brugte konfigurationer.

De næste skridt

Indtil videre kiggede vi på simple scenarier under opdeling i arkitekturlag og samlet solskinstest. Skal testen være mere dybdegående, er der en række spørgsmål man må tage stilling til:

  • Hvordan skaber vi et test miljø der er med til at replikere nødvendige i testens forløb situationer? Skal vi købe alle tilgængelige dimser og forbinder dem på kryds og tværs? Kan vi simulere noget?
  • Givet vi har fået et test miljø der giver os mulighed for at konstruere forbindelserne mellem de forskellige komponenter: hvordan sikrer vi at alle kombinationer i et system med et antal forskellige “Ting” er dækket? Derudover kommer kombinationer af funktionskald, data- og tilstandsvariationer som danner grundlag for de test cases vi vælger at udføre.
  • Givet dækningsgraden er identificeret, hvordan sikrer vi en stabil, pålidelig og kontinuerlig eksekvering af test af hardware, funktionalitet og brugsmønstre der er under konstant forandring? Kunne automatisering klare en del af test byrden?

Disse var nogle få spørgsmål jeg stillede mig selv undervejs i oplægget og efterfølgende, og der virker til at være meget mere i det – og samtidigt meget spændende hvad denne udvikling kan betyde for feltet af softwaretest. Jeg håber derfor at kunne skrive lidt mere om emnet.

Testing Tuesday morgenmødet var inspirationen for dette indlæg, som dog ikke har til formål at gengive det sagte. Jeg vil gerne sige tak til Gitte Ottosen fra Capgemini Sogeti for et spændende arrangement og oplæg samt til Anders Sahl Hansen for en spændende introduktion til verden af IoT 🙂