På avdelningen för oväntade features hittade jag idag något nytt och spännande – nämligen hur självincheckningsautomaterna på Bromma flygplats verkar hantera identifierare om en skannar sitt pass för att hämta ut sina biljetter. Det var också ett underhållande sätt att vakna till på inför resan utomlands. 🙂
Att reproducera var enkelt, det var bara att skanna mitt pass och kontrollera att mina bokningar dök upp på skärmen – tyvärr var det inte mina bokningar som dök upp!
Mjukvaran som körs på självincheckningsautomaterna är garanterat testad och dokumenterad av en människa innan den installerades på automaten, och helt enligt de bestämmelser som gäller inom flygbranchen, men ändå råkar jag ut för en avvikelse av denna magnitud? Hur gick det till? Här är min teori.
Då de flesta som testar mjukvara gör det i en klassisk blackbox-anda (inklusive undertecknad) där vi inte bryr oss om implementationsdetaljer så kan jag tänka mig hur testningen här gick till.
- Testaren får tillgång till senaste mjukvaran installerad på en typisk hårdvara (motsvarande en självincheckningsautomat på plats, hoppas jag) och har en lapp om att testa att det går att skanna ens pass för att få upp sina bokningar. Mjukvaran levereras i regel en aning sent i projektet/sprinten och det är givetvis rätt bråttom
- Testaren förbereder sin verifiering och får tag på en samling testpass, sätter upp ett antal flygningar och bokningar till dessa i sin testmiljö
- Testaren verifierar funktionaliteten utan problem, och i bästa fall gör det med ett antal edge cases, typ diplomatpass, skyddade identiteter etc
- Testaren skriver någon typ av rapport enligt sin arbetsmetod (testrapport, testsessionsanteckningar etc)
Allt bra såhär långt, förutom att implementationen tycks vara helt knasig då den tycks använda resenärens namn som nyckel för att plocka fram bokningar!
När en inte bryr sig om implementationsdetaljer kan det bli såhär tokigt om beställaren inte själv tänker till eller vet vad hen egentligen behöver, kravställaren bara översätter kundens beställning till krav eller uppgifter för utvecklarna, utvecklarna tänker snett och/eller implementerar enligt kravställarens leverabler, ingen fångar problemet vid kodgranskning och testaren inte har tid eller intresse att gräva ner sig tillräckligt för att notera detta.
Frågan är också vad som hade varit en bättre lösning – för jag misstänker att det här med personliga identifierare är ett klurigare problem än en lätt tror.
- I Sverige har vi våra personnummer vilket är väldigt praktiskt och ovanligt, och så av vad jag vet finns inte detta system på så många fler platser i världen.
- Det är rimligt att anta att det första namnet i ett pass även är det namn som passinnehavaren använder sig av till vardags…förutom i Sverige där det inte alls behöver vara så (som för mig)
- Pass ska ha ett passnummer, men hur kopplar du det till en fysisk person om du t.ex. inte är i ditt hemmaland? Att tillåta vilka datorer som helst att komma åt ett API för att hämta ut persondata baserat på en nyckel som är så pass enkel att gissa som ett passnummer låter nämligen direkt farligt.
- Hur skapar du ens en identifierare för pass som är globalt unik, svår att gissa men lätt för en människa att kontrollera och som alla kan enas kring? UUID uppfyller första kravet men inte andra, och att uppfylla det tredje kravet kan vi bara drömma om. 🙂
Det här med data är svårare än vad en tror.
Själv är jag givetvis felfri. Strax efter att jag upptäckt ovan noterade jag att jag tagit på mig byxorna med synliga genanta hål – och att jag inte packade några andra byxor då jag ändå bara skulle vara borta en natt…