Den praktiska verkligheten möter den teoretiska modellen

Alan Page har nyligen gett ut en sammanställning av alla hans blogginlägg som handlat om testautomatisering, testability, och vad som är bra automatisering[1]. Jag gillar hans tankar kring ämnet och hans blogg är ofta den första jag besöker när jag går igenom veckans nya testartiklar och inlägg.

Men situation han beskriver är kanske inte den situation som alla testare möter dagligen. Att vara en integrerad och likvärdig del av utvecklingsteamet, att tidigt få vara med och utforma testability, att kunna angripa testproblem och fritt välja om ett visst område ska automatiseras eller köras manuellt, och hur det ska automatiseras eller köras. Vissa testare kanske bara får en mjukvara och en bristande kravbild i ett sent skede av projektet, med krav på hur resultatet ska rapporteras, och får göra det bästa av situationen.

Vad händer då när en ny testare läser hans bok, och full av entusiasm kommer till en ny arbetsplats för att utföra stordåd med automatiseringsverktyg? Jag skulle gissa på att testaren i de flesta fall blir besviken. Den kunskap han inhämtat från boken är kanske inte bara oanvändbar utan i värsta fall kontraproduktiv. Detta begränsar sig så klart inte till kunskap om automatisering.

Hur angriper man problemet att olika organisationer, i olika kontexter, med olika mognadsgrad, kräver olika angreppssätt? En erfaren testare kanske är flexibel nog att använda utforskande testning när det är möjligt, att automatisera när rätt miljö och omständigheter tillåter det, och att exekvera skriptade testfall när det är vad som krävs. Kan man förbereda en ny testare för detta?

Cem Kaners Black Box Software Testing kurser [2], som de flesta känner till, är definitivt en bra start. Speciellt om de lägger till en kurs om automatisering och testability också, vilket jag tror kanske läggs till i framtiden [3]. Finns det något mer att göra?

Kanske kan vi när vi skriver artiklar och böcker vara tydliga med för vilken kontext det vi beskriver passar in i? Vilken typ av företag, vilken typ av mognadsgrad, vilken typ av förutsättningar som behövs för att någonting ska fungera. Problemet är väl att det är svårt att beskriva kontexten man jobbar i utan att avslöja företagshemligheter.

Eller så kanske man bara ska vara tydlig på testutbildningar, i läroböcker, och i olika publikationer att de processer, metoder och verktyg som används på olika företag skiljer sig avsevärt från varandra, och att en metod eller ett tillvägagångssätt som är optimalt i teorin, eller i en viss kontext, kanske inte är genomförbart i praktiken på företag med vissa förutsättningar. Att man ibland måste acceptera att man kanske inte kan använda de metoder och teorier man vill på grund av den praktiska verkligheten.

Men den praktiska verkligheten ska förståss inte hindra oss från att drömma om, och sträva efter, någonting bättre. På ett företag som är negativt inställda till automatisering kanske man kan skapa en prototyp för att visa värdet av ett automatiseringsramverk. Om ett företag anser att utforskande testning är för ostrukturerat kan man ordna en workshop och visa några av de många möjligheterna som finns för att göra det så strukturerat som det behövs.

Men det krävs nog att man är ödmjuk inför den praktiska verklighet man lever i, trots att man i teorin kanske precis vet vad man vill åstadkomma.

Är någonting av det jag beskrivit här nytt eller revolutionerande? Nej, detta är bara mina reflektioner efter att ha läst, och uppskattat, Alan Pages nya bok.

/Johan Hoberg

Referenser

[1] The ”A” Word

https://leanpub.com/TheAWord

[2] Black Box Software Testing Course

http://www.testingeducation.org/BBST/

[3] An Overview of High Volume Automation

http://kaner.com/?p=278