Porta i Tuoi Strumenti…Ma Prima, Pensa Due Volte
I team di sviluppo software hanno oggi più libertà che mai. Hanno accesso a una vasta gamma di strumenti, molti dei quali gratuiti. C’è un’abbondanza di componenti open-source disponibili per creare applicazioni. E, cosa ancora migliore, molti datori di lavoro incoraggiano i team ad allestire propri sistemi di sviluppo, adottare metodologie personalizzate e permettono ai membri di portare i propri strumenti.
La libertà di utilizzare gli strumenti, i metodi e le tecnologie che preferisci e conosci meglio probabilmente contribuisce positivamente alla produttività del tuo team—fino al momento in cui raggiungi i limiti dell’autonomia del team.
Evita un Collo di Bottiglia nei Test
Il mio amico, Jan, guidava un team di sviluppo software molto competente presso una società di sviluppo software personalizzato. Sapevano davvero come essere agili. Ma avevano un problema di qualità. Avevano accelerato così tanto il proprio ciclo di rilascio che i test erano diventati il collo di bottiglia.
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
E risolsero il collo di bottiglia saltando i test. Jan, ovviamente, aveva capito cosa andava fatto. Scaricò Robot Framework, lo utilizzò per costruire un framework di automazione dei test personalizzato per il team e lo integrò nella loro pipeline di integrazione continua. Gradualmente, aggiunse sempre più test ed estese il framework con un ampio numero di keyword di alto livello per semplificare la scrittura degli script di test.
Nel frattempo, anche gli altri team—e ce n’erano molti—stavano affrontando sfide simili e le risolvevano a modo loro, con Selenium o un altro strumento a loro scelta.
I Team Hanno Bisogno di un Framework di Automazione per Tutti
I pessimisti dicono che ogni soluzione contiene il seme di un nuovo problema. Jan scoprì presto di essere diventato un ingegnere di automazione dei test a tempo pieno. Certo, le sue librerie erano facili da usare—per lui, e la sua architettura di test era facile da capire—per lui. In ogni altro team, c’era un collega nella stessa situazione. Uno di loro cambiò lavoro. Lo sviluppatore che prese il suo posto decise di riscrivere tutto, poiché non gradiva il modo in cui era stata costruita l’automazione e la trovava difficile da comprendere. Quando molti team iniziarono a riportare queste difficoltà ai loro responsabili, emerse la domanda ovvia: perché non c’è coerenza tra i team?
Qualcosa doveva essere fatto. La soluzione era ovvia: costituire un team centralizzato di automazione dei test che servisse i team di sviluppo fornendo un unico framework di automazione per tutti. In pratica, il team era composto da Jan e un altro sviluppatore. Ed è qui che è iniziata davvero la difficoltà.
Condividi la Metodologia, non Solo gli Strumenti
I test si rompevano spesso. Così come il framework. I team di sviluppo facevano fatica ad adattare le loro pratiche agli strumenti e il team degli strumenti faticava a soddisfare tutte quelle diverse necessità. La complessità del framework cresceva costantemente. Il collo di bottiglia dei test si era trasformato in un collo di bottiglia degli strumenti di automazione dei test.
La condivisione interna degli strumenti è un’idea bellissima, ma non è semplice da realizzare. Per riuscirci, lo strumento deve essere gestito come un vero prodotto e deve essere ben testato. Paradossalmente, i framework di automazione dei test interni sono spesso pieni di bug. Ma c’è una sfida ancora più grande. Per beneficiare della condivisione degli strumenti su larga scala, serve anche una metodologia condivisa.
La storia di Jan è tipica—e non è ancora finita. Ora stanno valutando la prossima mossa: tornare ai team autonomi e accettarne il costo, investire di più negli strumenti condivisi e instaurare una metodologia coerente, oppure scegliere uno strumento commerciale e concentrarsi solo sulla metodologia. Nessuna di queste scelte è sbagliata, ma ciascuna porterà a conseguenze differenti.
