Energiomvandling – en av testarens viktigaste egenskaper.

Ibland påträffar man mjukvara med överraskande dålig kvalité. Med mycket alvarliga defekter. Nyligen påträffade jag sådan mjukvara. För mig gav det mig en morot och energi att vilja testa och skriva några tänkvärda rader. Då bl.a. dessa rader.

Eftersom jag själv jobbat med testning mest inom större multinationella organisationer får jag väl ändå tillstå att mjukvaran, med några få undantag, haft någon form av rök- och/eller enhets-testning innan den blivit givits till testavdelningen.

Men nyligen blev jag mycket negativt överraskad av en 3e parts produkt, som jag själv inte var anställd att testa. Vare sig jag eller vårt företag har någon som helst relation till det andra företaget, annat än att vi använder deras produkt.

Det är en väl beprövad produkt, förmodligen marknadsledande i sitt område.

Inom denna produkt finns ett ganska stort funktionsområde jag behövde använda i testautomatisering. Vad jag blev varse om ganska fort var att det omöjligtvis kan ha testats ingående, än mindre haft någon som helst automatiserad regressionstestning.

Tyvärr fanns det defekter på alla nivåer av funktionaliteten, allt från bakomvarande server, backend, funktionalitet till användargränssnitt, GUI. Alan Page skrev i sin bok, ref[2],  att man som testare i varje fall borde kunna förvänta sig att “happy path” fungerar.  Dvs. att det enklaste, kortaste, positiva användare scenariot fungerar. I mitt fall funkade ingen “happy path”. Vare sig i GUI, som hängde sig, eller server, som inte tog emot de argument som man skickat in, t.ex.  via kommando prompten.

Ibland satt jag och skrattade för mig själv, så dåligt var funktionaliteten. Man fick en déjà-vu känsla av  en laborations inlämningarna man lämnade in på högskolans programmeringskurser som man visste inte var klar. Men man inte haft tid att slutföra. Man höll bara tummarna att labbassistenten inte skulle underkänna inlämningen. Med andra ord inte mjukvara på en kvalitetsnivå man kan sälja, annat än möjligtvis något land i tredje välden som styrs av en diktator.

Men som testare är det speciellt viktigt att kunna omvandla den negativa och smått apatiska känsla man får när man försöker slutföra ett projekt med en snäv tidsram och man är beroende av utvecklare i icke existerande kvalitetstänk. Dessutom som i mitt fall, i en produkt som man inte ens var anställd att testa.

Då gäller det att följa de råd som Dalai Lama beskriver i sin bok, ref[1]. Han har varit utsatt för betydligt svårare situationer än icke fungerande mjukvara och snäva tidsramar. Han rekommenderar  bl.a. att man ska se på varje problem utifrån den synvinkeln att man givits en unik möjlighet, av just det problemet eller personen, att lära sig något nyttigt och lärorikt från situationen som man kan ha nytta av i all framtid. Varje svår situation ger möjligheten att bli åtminstone en erfarenhet rikare.

Som han beskriver i sin bok gäller det att omvandla den negativa energin, eller hopplösa, i situationen till något konstruktivt. Det  är ett bra  synsätt och metod för all problemlösning i livet, inte bara arbetslivet.

Som testare är det viktigt att kunna använda sig av den metoden att omvandla energi. Den gör det möjligt att vara saklig och objektiv, när man kanske innerst inne, instinktivt, bara skulle vilja svära och gnälla, eller något ännu värre om man träffade på utvecklaren.

Så jag registrerade ett stort antal defekter samt föreslog ett antal nya funktioner.

Jag summerade därefter alla incidenter jag haft, så det externa företaget och dess ledning fick en möjlighet att se att det inte bara var isolerade incidenter utan en generellt problem med deras testning, på alla nivåer.

Dessutom gav listan med defekter en möjlighet att få en bättre överblick för alla involverade.

Inte minst för mina uppdragsgivare som jag måste förklara varför en arbetsuppgift att automatisera tester, som på pappret inte borde ta mer än ett par timmar att genomföra, tog mycket, mycket längre än så.

Det externa företaget svarade bra och resolut samt kom dessutom ut med snabba fixar på ett antal av de defekter jag påträffat.

Tyvärr visade sig dock att några av fixarna också hade medfört regressioner, vilket tydligt påvisade att de inte använder automatiserade regressionstester eller i varje fall inte i den utsträckning som behövdes.

Jag framförde även att vikten för det externa företaget av automatiserade regressionstester. Inom alla funktioner och typer av moduler. Som t.ex. bakomvarande av server-funktionalitet, men också av användargränssnitt.

Jag föreslog också för deras ledning, p.g.a. att jag hjälpte testa deras mjukvara (och inte vår egen än så länge tyvärr), att vi skulle bli krediterade licensavgiften. På så vis fick även personer högt upp ledningen upp ögonen på bristande kvalitet och att det kanske måste kosta lite att testa, vilket kanske inte blir resultatet om man “bara” nöjer sig att kontakta och gnälla på en supportavdelning.

Det externa företaget har blivit givna en utmärkt möjlighet, av mig,  att ändra deras testmetoder och testprocess. Lyckas de inte, får vi och många andra välja en annan leverantör.

Som leverantör av mjukvara bör man lyssna på en kund som orerar sitt missnöje. Tystnar kunden helt har man troligtvis nått en punkt då denne tröttnat, givit upp och tittar på andra leverantörer, som kan leverera kvalitet.

Kontentan av denna artikel är:

1. För dej som testare är det viktigt att kunna “energiomvandla” såsom Dalai Lama beskriver.

2. Inom varje större funktionsområden, försök åtminstone testa enkla positiva tester “happy path”, innan större versioner ska  lanseras.

3. Med utveckling i Scrum och Agila miljöer är det viktigare nu, än någonsin, att se till att ditt företag implementera automatisk regressions testning. Som testavdelning hinner man inte med annars.

4. Det är svårt att reparera en förtroendekris när den väl inträffat. Denna incident har kraftigt decimerat förtroende för vår leverantör och dess ledning.

Referenser

[1], Lycka! : en handbok i konsten att leva, Dalai Lama,  ISBN: 9789153433309

[2] How we test software at Microsoft, Alan Page, ISBN 9780735624252