Det var en gång...

Flera decennier inom QA ger en del dråpliga och insiktsgivande berättelser att förmedla. För min egen skull har jag börjat beskriva en del av dessa här.

Detta är en av dem.

Bandbreddskrävande tester av tidiga Play-tjänster

År 2003, två år innan YouTube grundades och tre år innan Spotify grundades, hade Telia redan förstått att de borde bygga en serverpark och tjänster för strömmande media till SVT, Sveriges Radio och liknande.

En initial lösning var nu på plats, men man hade inte någon riktig koll på vad den förmådde så de tog in hjälp och jag kom dit för att prova hur mycket lösningen kunde leverera.

Telias lösning var i sin linda men de hade redan en mängd TV-operatörer, video-uthyrar-tjänster och radiostationer som stod på kö för att vilja sända via dessa tjänster. Själva tekniken bestod av en lösning av 300 servrar för video-on-demand, broadcastad video, audio-on-demand, broadcastad audio och multi-castad dito och Telia ägde ju redan nätverken ut till de flesta på operatörsnivå.

Det fanns tyvärr inte några verktyg för att testa strömmande media så jag fick bygga egna lösningar för detta (för Real Media fanns det faktiskt verktyg, men de klarade inte denna mängd data så det blev till att bygga egen lösning även där).

Tester av broadcastad media gick ganska bra. Routingen var det som krävde resurser, men det var helt klart hanterbart tack vare den för tiden massiva hårdvaran och de slimmade överföringsprotokollen.
Även multi-castat (vissa mottagande noder i samma nät) gick bra.
Så fort vi började testa med on-demand-media blev det värre. Redan vid några dussin samtidigt streamade olika video-strömmar tog dåtidens nätverk stopp och vi började få en massa packet-loss vilket ledde till pixeliserade bilder och avbrott för buffrande.

Det är inte varje dag man tänker på det, men Moores lag har funkat ganska bra i flera decennier kring minne och CPU-prestanda, men när det kommer till nätverkskapacitet har utvecklingen gått mycket, mycket fortare.
I dessa tester var det helt enkelt bandbredden som tog slut fort när flera videoströmmar skulle gå samtidigt i samma linor.

Fler parallella linor skaffades, men det hjälpte bara lite. Istället prissattes tjänsterna så att ingen av leverantörerna som tillhandahöll on-demand-video skulle få särskilt många konsumerande kunder de första åren (men ändå kunna visa upp och skryta om tjänsterna).

Hela ServerNet (som projektet kallades) var ändå ett spännande uppdrag på många sätt tack vare att jag fick klura fram egna lösningar och fick nytta av mycket av mina gamla nätverkskunskaper från tiden som nätverkstekniker.

Egentligen har jag bara behövt bygga helt egna testverktyg några få gånger i min karriär, jag kommer bara på några ytterligare gånger jag har behövt skapa egna lösningar och det är:

• Kommandoscripts- och AutoIT-baserad lösning för att gratis prestandatesta Citrix-lösningar robust och stabilt
• Lösning för att testautomatisera i WM-ware
• Implementation av Tuxedo/Jolt-protokoll inför prestandatest hos myndighet
• Vårt eget testautomatiseringsramverk TAF (för webb, REST, SOAP, Java, WPF o.s.v.)
• Ett verktyg för informationshantering vid session based testing
• Verktyg för utvecklarnära prestandatester i byggpipelines genom parallellisering av enhetstester (för Java och C#)
• En hel del hjälpverktyg för att få nytta av Seleinum (bibliotek för systemtestsverifieringar, loggninsgbibliotek, bra drag-n-drop XPath-skapare o.s.v.)
• En massa tjänster för testdatagenerering (säkra personnummer för test där man kan ange olika constrainsts, säkra telefonnummer för testbruk, säkra bilregistreringsnummer för testbruk, organisationsnummer för testbruk o.s.v.)
• Lättanvänd generisk pytteliten stub-server för testare (med möjlighet både till inspelning och inläsning/inskrivning)
• Verktyg för att remote-styra låsta datorer genom att tillhandahålla en commandoradspromt för att kunna exekvera vad som helst remote till dem
• Verktyg för att testa responsiv webb (genom att steglöst skala om skärmen i höjd- och sidled och se vilka element som dyker upp eller försvinner vid olika upplösning och sedan jämföra det mot baseline)
• Verktyg för att exportera data från ReQtest till andra verktyg
• Verktyg för att få styrsel på licensanvändning för OpenTexts testverktyg

Ojdå. Det blev ändå en liten lista, och då tog jag bara de jag kom på nu i stunden.
Oavsett så är det ganska kul att bygga testverktyg. :)

Lärdom

• Med modern teknik kan man lösa mycket, men när inte tekniken ännu finns kan den istället utgöra en absolut barriär för att realisera visionerna.
• Det finns mängder av sätt att begränsa användning till acceptabla nivåer, t.ex. genom prissättning.
• Det är kul att bygga egna testverktygslösningar.