Den praktiska verkligheten möter den teoretiska modellen

1. 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 entusias m
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 testnin g 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 kurs er [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 tyd liga 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 el ler ett

2. 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

3. 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