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 besrkiva en del av dessa här.

Detta är en av dem.

Katastrofal övertro på enhetstester

När jag först kom till teamet någon handfull år efter milennieskiftet och fick höra om upplägget blev jag förbluffad. Det var ett stort agilt team om 35 personer i samma team. Vi utvecklade ett nätplaneringsverktyg i telekomvärlden. Jag hade mest jobbat i små agila teams i DSDM eller SCRUM eller små team i olika avarter av RUP så detta team kändes enormt.

Det stora teamet var en utmaning för daily standups så dessa hölls bara tre gånger i veckan. Det innebar också stora synk-utmaningar.

Det jag blev mest överraskad av var dock att produkten vi utvecklade hade tio gånger mer kod i enhetstesterna än i själva produkten. TIO GÅNGER!

Min roll var som testande testledare och jag fick höra från stöddigt ifrågasättande utvecklare att de inte visste vad jag hade där att göra och att jag AAAAALLLLLDRRRRIIIIG skulle hitta några fel i systemtest eftersom det var så god täckning i enhetstesterna.

Jag får erkänna att jag själv vid något tillfälle började tveka och känna att jag kanske för en gångs skull var överflödig i min testargärning. Ganska snart började vi dock märka att det var ganska buggigt i systemet.

Till och med VÄLDIGT buggigt.

Anledningen till att vi ens testar på systemtest är att komplexiteten ökar enormt när vi sätter ihop komponeter i en mer komplex omvärld där så mycket kan gå fel även utanför de programmerade binärerna. I detta fallet var det en stor extra komplexitet med ny infrastruktur och nya databaser samt ett nytt multianvändarstöd.

Det uppdagades snart dessutom att det stora skälet till att det var så oproportionerligt stor andel kod i enhetstesterna jämfört med själva produktens kod var att produkten till största delen genererades upp från modeller med hjälp av produkten Rational Rose och en del tillägg till detta verktyg.

Modeller är ju till sin definition en förenkling av verkligheten så det behövdes lite kod här och där för att försöka överbrygga de grövsta förenklingarna. Det hjälpte dock inte. Det blev inte så bra.

Enhetstesterna fortsatte att visa grönt och fortsatte nog att fylla en viss funktion. Det är möjligt att det tog onödigt mycket utvecklingstid att underhålla dessa, det vet jag inte, men så kan det vara om man har så mycket enhetstester att de blir change notifiers snarare än tester. På en rak fråga från mig om hur stor andel av enhetstesterna som var taggade "@ignore" fick jag höra att det förmodligen rörde sig om ca. 30% av alla enhetstester.

Efter några månader hade vi tre testare i teamet registrerat 2.000 fel i systemtest. Tiden kröp ifrån att hinna rätta annat än de mest allvarliga felen och vi var så småningom tvungna att gå live med ca. 400 kända fel.

Något år senare var produkten nerlagd. Organisationen bakom vår produkt hade då köpt upp värsta konkurrentens produkt och favoriserat den istället. Det kom inte som någon överraskning för oss. Anledningen till att teamet tog in mig var att de var i en tidpunkt där de intensivt behövde komplettera sin produkt med nya features och pollera upp den eftersom de visste att uppköpet var förestående och de ville gå segrande ut ur det genom att kunna påvisa att vårt teams produkt var bättre än konkurrentens.

Lärdom

Att koden funkar perfekt behöver inte betyda att systemet fungera alls.

Den som gapar över mycket mister ofta hela stycket eller något sådant?