Ta med dina egna verktyg … men tänk efter en extra gång
Programvaruteam har större frihet än någonsin. De har tillgång till ett stort utbud av verktyg, och många av dem är gratis. Det finns ett överflöd av byggblock med öppen källkod som kan användas för att skapa applikationer. Och bäst av allt är att många arbetsgivare uppmuntrar team att själva sätta upp sina utvecklingssystem och metoder samt låta teammedlemmarna ta med sina egna verktyg.
Friheten att använda de verktyg, metoder och tekniker som du gillar bäst och kan bäst bidrar sannolikt positivt till teamets produktivitet – fram till den punkt där du når gränserna för teamets självständighet.
Undvik en flaskhals i testningen
Min vän Jan ledde ett mycket kompetent programvaruteam på ett företag för skräddarsydd programvaruutveckling. De förstod verkligen hur man arbetar agilt. Och de hade ett kvalitetsproblem. De effektiviserade sin releasecykel så väl att testningen hade blivit en flaskhals.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Och de löste flaskhalsen genom att hoppa över testningen. Jan förstod naturligtvis vad som behövde göras. Han laddade ner Robot Framework, använde det för att bygga ett anpassat ramverk för testautomatisering åt teamet och kopplade in det i deras pipeline för kontinuerlig integration. Gradvis lade han till fler och fler tester och utökade ramverket med ett stort antal nyckelord på hög nivå för att göra det enkelt att skriva testskript.
Samtidigt upplevde de andra teamen – och det fanns många av dem – liknande utmaningar och löste dem på sina egna sätt, med Selenium eller något annat verktyg efter eget val.
Team behöver ett gemensamt ramverk för testautomatisering
Pessimister säger att varje lösning innehåller fröet till ett nytt problem. Jan upptäckte snart att han hade blivit testautomatiseringsingenjör på heltid. Visst, hans bibliotek var enkla att använda – för honom – och hans testarkitektur var enkel att förstå – för honom. I alla andra team fanns det en kollega i samma situation. En av dem bytte jobb. Utvecklaren som tog över bestämde sig för att skriva om allt eftersom hon inte tyckte om hur automatiseringen hade byggts och hade svårt att förstå den. När allt fler team började rapportera dessa utmaningar till sina chefer uppstod den uppenbara frågan: varför finns det ingen enhetlighet mellan teamen?
Något behövde göras. Lösningen var uppenbar: låt oss etablera ett centraliserat team för testautomatisering som betjänar utvecklingsteamen genom att tillhandahålla ett gemensamt ramverk för testautomatisering. I praktiken bestod teamet av Jan och en annan utvecklare. Det var då kampen verkligen började.
Dela metodik, inte bara verktyg
Tester gick sönder ofta. Det gjorde även ramverket. Utvecklingsteamen hade svårt att ändra sina arbetssätt så att de överensstämde med verktygen, och verktygsteamet hade svårt att tillgodose alla dessa olika behov. Ramverkets komplexitet fortsatte att öka. Flaskhalsen i testningen hade förvandlats till en flaskhals i verktygen för testautomatisering.
Gemensamma interna verktyg är en vacker idé, men det är svårt att få dem att fungera. För att lyckas måste verktyget hanteras som en riktig produkt, och det måste testas ordentligt. Paradoxalt nog är interna ramverk för testautomatisering ofta behäftade med fel. Men det finns en ännu större utmaning. För att dra nytta av gemensamma verktyg i stor skala behöver man också en gemensam metodik.
Jans berättelse är typisk – och den är inte över än. De överväger nu sitt nästa steg: att återgå till självständiga team och acceptera kostnaden, investera mer i de gemensamma verktygen och etablera en enhetlig metodik, eller välja ett kommersiellt verktyg och endast fokusera på metodiken. Inget av dessa val är fel, men vart och ett kommer att få olika konsekvenser.
