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.

Reklamer

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