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