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
Reklamer

Min årskavalkade 2017

Mens året nærmer sig sin afslutning, vil jeg bruge lidt tid på at kigge tilbage.bestof2017sofar

Denne blog begyndte jeg at skrive for lidt over halvandet år siden og det er blevet til flere indlæg der både handlede om at være tester i en agil verden og så lidt mere til. Mange af mine læringer og erfaringer lander her og bliver til refleksioner, ideer og koncepter. Nogle af dem bliver til virkelighed og resulterer i større eller mindre forandringer. Blandt dem jeg vil fremhæve:

  • Jeg har kastet mig for alvor over BDD og lavede et oplæg til Sogeti Capgeminis Testing Tuesday i starten af 2017.
  • Året blev også slutningen på min karriere som agil tester hos eBay, da jeg har fået jobbet som Agil coach og underviser hos Testhuset. Her fortsatte jeg min fokus på BDD og i fællesskabet med andre dygtige og erfarne undervisere udviklede vi et decideret BDD kursus og fik gode tilbagemeldinger på det efter at have afholdt det flere steder.
  • Jeg gik også dybere ind i teorien med agil test. ISTQBs agile extension gav en klassisk teoretisk oplevelse, på samme måde som det var med Foundation. Senere tog jeg også CAT og er nu den 6 person i Danmark som kan og må undervise i det 😉

CAT

http://www.agile-teaming.org/trainer-of-cat-certified-agile-tester.html

  • 2017 blev også året hvor jeg har sat fokus på agilitet og dennes anvendelse i software udvikling. I min rolle som agil coach har jeg arbejdet med kunder og deres cases og har fået nogle spændende erfaringer: lige fra valg af test management tool til QA strategi på agile teams — emnet var interessant nok til at blive til en kort artikel skrevet som en opsummering af erfaringer og overvejelser omkring det.
  • Motivation og kontinuerlig udvikling har også fyldt mine tanker og blogs en del: jeg skrev om at finde sin vej og veje til success, inspireret af tanker fra Simon Sinek og Toyota Kata. Disse tanker fandt også anvendelse i mit arbejde som agil coach, hvor jeg har kigget på måder at skabe motivation hos agile teams. Motivationsteorien og ikke mindst praksis står øverst på todo-listen i 2018.
  • I flere måneder har jeg været en del af flere agile teams og fået lidt jord under neglene med både praktisk test, test automatisering med webdriver.io og test management. Disse erfaringer gav uundværlig empirisk baggrund for at kunne summe og fundere over det med at arbejde med QA i agile projekter. Erfaringer viser at tekniske kompetencer har en større efterspørgsel end manuel test, hvorfor jeg tror at vi kommer til at se færre dedikerede manuelle testere på agile projekter, hvor QA og test fungerer i praksis som et fælles ansvar.
  • I løbet af året talte jeg med flere som fungerer i det daglige som agile testere.  Jeg gravede dybere i at forstå hvad agilitet egentlig for en størrelse da test og QA eksisterer jo altid i en kontekst. Det gav mig bedre indsigt i hvilke kompetencer og evner bidrager bedst til den agile kontekst samt har ført mig til at fokusere mindre på værktøjer og metoder som Scrum og mere på det agile mindset.
  • Sidst på året lavede et oplæg om hvad agil tester er for en størrelse, set i kontekst af ovenstående. Det fortsætter jeg nok med at kigge på og blogge om i 2018 🙂

Poul-Sørensen

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!

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

 

 

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.

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 🙂