Det är inte alltid lätt att lära sig av sina misstag. Men vissa missar gör man inte gärna om, som till exempel att trycka tungan mot en iskall lyktstolpe. En annan viktig sak som jag genom misstag lärt mig är att det är nödvändigt att ha stenkoll på versioner och leveranser. Om man inte vet vilken version man testat på så är testresultatet oftast inte mycket värt.
Jag var testledare i ett systemutvecklingsprojekt och med en nyfrälst scrumfantast till arkitekt försökte vi arbeta så lättrörligt som möjligt. Beställaren fanns nära tillhands och dagliga möten gjorde att vi hade bra koll på varandra och vad som hände i gruppen. Vi hade kortat ner iterationerna till treveckorssprintar och istället för att ha en integrationsperiod innan utvecklarna levererade till testteamet så arbetade utvecklarna med kontinuerlig integration och kontinuerliga byggen. Det innebar att varje gång utvecklarna checkade in sin kod så skapades ett nytt bygge och automatiserade enhetstester kördes. För flera av projektdeltagarna var det en ny erfarenhet att arbeta på detta scrumliknande sätt och det kändes spännande och inspirerande.
Det här med kontinuerliga byggen var bra på många sätt, bland annat därför att vi testare snabbt kunde få tillgång till nya funktioner och felrättningar. Tidigt i projektet frågade jag arkitekten hur det skulle fungera med releaser och brancher. Han svarade med stor entusiasm och övertygelse att det inte behövdes några releaser eftersom de automatiserade enhetstesterna hela tiden skulle verifiera att det som byggdes fungerade.
Mot bättre vetande rycktes jag ändå med i det här ”snabba ryck-tänket” med ständigt nya byggen och dåligt genomtänkt (obefintlig) releaseplanering. Så närmade sig dagen då det var dags för demonstration och den här gången var det inte bara för de närmast sörjande utan för en fullsatt hörsal. Dagen innan demonstrationen fungerade i stort sätt ingenting, automattesterna var tydligen inte så effektiva som vi hade trott. Med stigande panik började jag leta efter äldre, fungerande byggen. Det visade sig att vi på grund av utrymmesskäl bara sparade de tio senaste byggena. Eftersom det blev ett nytt bygge varje gång utvecklarna checkade in så fanns det bara byggen för ett par dagar bakåt i tiden att välja på. När jag testade dessa så hittade jag ingen version där alla funktioner fungerade och vid närmare eftertanke så hade jag nog inte testat igenom allt på samma version tidigare. Jag bannade mig själv för att jag så lättvinligt låtit mig bländas av arkitektens entusiasm och därför struntat i en av mina viktigare erfarenheter som testledare.
Jag lyckades i alla fall genomföra en hyfsad demonstration, fick fejka några delar och låta bli att visa andra. I efterhand kändes det ändå bra att det bara var en demonstration som inte blev helt lyckad, det hade varit värre att missa en viktig leverans.
Med en omvärld som förändras allt snabbare och knappast blir mindre komplex är det nödvändigt att våga prova nya idéer och att inte jämt göra som man alltid har gjort. Men samtidigt får man inte glömma bort tidigare erfarenheter, man måste inse att många gamla sanningar fortfarande gäller. För oavsett omvärldens förändringstakt så är det smart att ha en releaseplanering, det är ett måste att ha kontroll över vad man testar på och det gör fortfarande ont att slicka på frostig stolpe…
Men blev releasen bra?
En knackig demo kan man ju leva med.
Utrymme är ett skäl för färre sparade byggen, överblicken ett annat.
Jag har goda erfarenheter av att alltid ha ett bra bygge kopierat i mappen “LastKnownGood”.
Apropå att lära sig av misstag så kom jag att tänka på skidskytten Björn Ferry som sagt nåt i stil med:
“jag lär mig bäst genom att lyckas.”
Det tror jag är bättre, och svårare.
Härliga bilder!
Det är lätt att bara slänga det man har istället för att förbättra det som man har. Men, man måste vara “open-minded” för att se vad som händer. Världen rullar på och det enda vi kan vara säkra på är förändring. Hela tiden, alltid!