Neem je eigen hulpmiddelen mee… maar denk eerst twee keer na
Softwareteams hebben meer vrijheid dan ooit. Ze hebben toegang tot een grote verscheidenheid aan hulpmiddelen, en veel daarvan zijn gratis. Er is een overvloed aan open-sourcebouwstenen beschikbaar voor het maken van applicaties. En het beste van alles is dat veel werkgevers teams aanmoedigen om hun eigen ontwikkelsystemen en methodologieën op te zetten en teamleden hun eigen hulpmiddelen mee te laten brengen.
De vrijheid om de hulpmiddelen, methoden en technologieën te gebruiken die je het prettigst vindt en het beste kent, zal waarschijnlijk positief bijdragen aan de productiviteit van je team—tot het moment waarop je tegen de grenzen van de zelfstandigheid van het team aanloopt.
Vermijd een testknelpunt
Mijn vriend Jan leidde een zeer bekwaam softwareteam bij een bedrijf voor softwareontwikkeling op maat. Ze begrepen echt hoe ze agile moesten werken. En ze hadden een kwaliteitsprobleem. Ze hadden hun releasecyclus zo goed versneld dat testen een knelpunt was geworden.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
En ze losten het knelpunt op door testen over te slaan. Jan begreep natuurlijk wat er moest gebeuren. Hij downloadde Robot Framework, gebruikte het om een aangepast testautomatiseringsraamwerk voor het team te bouwen en koppelde het aan hun pijplijn voor continue integratie. Geleidelijk voegde hij steeds meer tests toe en breidde hij het raamwerk uit met een groot aantal trefwoorden op hoog niveau om het schrijven van testscripts eenvoudig te maken.
Ondertussen ondervonden de andere teams—en daar waren er veel van—vergelijkbare problemen en losten ze die op hun eigen manier op, met Selenium of een hulpmiddel naar keuze.
Teams hebben één automatiseringsraamwerk voor iedereen nodig
Pessimisten zeggen dat elke oplossing het zaad van een nieuw probleem in zich draagt. Jan kwam er al snel achter dat hij een fulltime-engineer voor testautomatisering was geworden. Zeker, zijn bibliotheken waren gemakkelijk te gebruiken—voor hem, en zijn testarchitectuur was gemakkelijk te begrijpen—voor hem. In elk ander team bevond zich een collega in dezelfde situatie. Een van hen veranderde van baan. De ontwikkelaar die het werk overnam, besloot alles te herschrijven omdat ze de manier waarop de automatisering was gebouwd niet prettig vond en het moeilijk te begrijpen vond. Toen steeds meer teams deze problemen bij hun managers begonnen te melden, rees de voor de hand liggende vraag: waarom is er geen consistentie tussen de teams?
Er moest iets gebeuren. De oplossing lag voor de hand: laten we een gecentraliseerd team voor testautomatisering oprichten dat de ontwikkelingsteams ondersteunt door één automatiseringsraamwerk voor iedereen te bieden. In de praktijk bestond het team uit Jan en nog een ontwikkelaar. Toen begon de echte strijd pas.
Deel methodologie, niet alleen hulpmiddelen
Tests faalden vaak. Het raamwerk ook. De ontwikkelingsteams hadden moeite om hun werkwijzen aan te passen aan de hulpmiddelen, en het hulpmiddelenteam had moeite om aan al die verschillende behoeften tegemoet te komen. De complexiteit van het raamwerk bleef groeien. Het testknelpunt was veranderd in een knelpunt bij de hulpmiddelen voor testautomatisering.
Gedeelde interne hulpmiddelen zijn een prachtig idee, maar het is moeilijk om ze goed te laten werken. Om succesvol te zijn, moet het hulpmiddel worden beheerd als een echt product en moet het goed worden getest. Paradoxaal genoeg bevatten interne raamwerken voor testautomatisering vaak fouten. Maar er is een nog grotere uitdaging. Om op grote schaal voordeel te halen uit gedeelde hulpmiddelen, heb je ook een gedeelde methodologie nodig.
Het verhaal van Jan is een typisch verhaal—en het is nog niet afgelopen. Ze overwegen nu hun volgende stap: terugkeren naar autonome teams en de kosten accepteren, meer investeren in de gedeelde hulpmiddelen en een consistente methodologie opzetten, of een commercieel hulpmiddel selecteren en zich alleen op de methodologie richten. Geen van deze keuzes is verkeerd, maar elk ervan zal andere gevolgen hebben.
