Menu

Che cos'è il debito tecnico e perché i tester del QA dovrebbero preoccuparsene?

  • Principale
  • Test Agili
  • Che cos'è il debito tecnico e perché i tester del QA dovrebbero preoccuparsene?

what is technical debt

Prova Il Nostro Strumento Per Eliminare I Problemi

Debito tecnico è un'idea metaforica che sostiene che proprio come si può incorrere in problemi di indebitamento in finanza, le organizzazioni di software incontrano qualcosa di simile nell'accumulo di lavoro incompiuto durante i progetti passati e le versioni / sprint delle versioni.

Cos'è il debito tecnico?

Rappresenta lo sforzo necessario per risolvere i problemi / difetti che rimangono nel codice quando viene rilasciata un'applicazione. In parole semplici: è la differenza (in termini di bug) tra ciò che è previsto e ciò che viene consegnato.

Quando un team di sviluppo è impegnato a lavorare su un progetto e purtroppo a correggere i bug, compaiono molti nuovi bug. Fuori da questi, alcuni sono corretti e altri differiscono per il rilascio successivo. Quando questa differenza di problemi continua ad aumentare, a un certo punto diventa davvero difficile rilasciare il prodotto in tempo senza problemi. Questa è la peggiore conseguenza di Debito tecnico se non viene affrontato in tempo.

In questo articolo imparerai: cos'è il debito tecnico, perché il team di controllo qualità dovrebbe essere preoccupato e, soprattutto, come gestirlo.

cos

Immagine fonte

Ward Cunningham , il fondatore del software wiki, concepito questa idea negli anni '90, tracciando parallelismi con l'impatto dei crediti inesigibili sul settore finanziario, alludendo letteralmente alla sgradevole esperienza di dover pagare interessi eccessivi dopo essere inadempienti sui prestiti.

come restituire un array da un metodo in java

La sfida di aumentare il debito tecnologico per sprint può essere visualizzata nella Fig.1.

Va menzionato qui, tuttavia, che c'è una leggera differenza nel significato di debito tecnico (noto anche come debito di codice o debito di progettazione) dalla sua corrispondente analogia nel mondo della finanza: il primo è più simile a un idea astratta , senza equazioni matematiche per visualizzare come si accumula realmente l'interesse.

aumento del debito tecnico

Fig. 1: Visualizzazione dell'aumento scalabile del debito tecnologico negli sprint

Cosa imparerai:

Perché i team QA soffrono di più a causa del debito tecnico

Durante un tipico ciclo di progettazione e sviluppo del software, ci sono diverse cose che possono portare a un ' debito tecnico 'Come situazione– documentazione impropria , test inadeguati e correzione di bug, mancanza di coordinamento tra le squadre, eredità codice e refactoring ritardato , assenza di integrazione continua e altri fattori fuori controllo.

Per esempio, è stato osservato che gli sforzi di duplicazione del codice possono portare a qualsiasi cosa tra 25 per 35% lavoro extra.

lista doppiamente concatenata classe c ++

Tuttavia, da nessuna parte sono i file sfide dovute al debito tecnico più evidenti rispetto ai test QA dove i team di test devono rispettare scadenze impreviste e tutto può essere messo fuori servizio.

Quante volte i tuoi tester hanno dovuto affrontare dei dilemmi all'ultimo momento quando, inaspettatamente, il responsabile delle consegne è arrivato e ha detto loro: 'Squadra! Dobbiamo lanciare il nostro prodotto tra una settimana, ci dispiace non essere in grado di comunicarlo in tempo. Termina urgentemente tutte le attività di test in modo che possiamo essere pronti con la demo. '

Fondamentalmente, qualsiasi test mancato o approccio 'risolvilo in seguito' può portare a un problema simile al debito tecnologico. Mancanza di copertura del test , user story di grandi dimensioni, brevi sprint e altri esempi di 'scorciatoie' a causa della pressione di consegna svolgono un ruolo enorme dietro l'accumulo di debito tecnico nella pratica del controllo qualità.

Un esempio del mondo reale

Un rivenditore online con sede negli Stati Uniti con una presenza significativa su più siti Web e app mobili si è trovato di fronte a una vera e propria sfida per il 'debito tecnico' quando la complessità della rete di test ha iniziato ad aggravarsi con ogni nuovo sprint .

Ciò è accaduto a causa dell'improvviso aumento del numero di dispositivi mobili da testare, di più lingue da supportare e di più di mezza dozzina di siti di social networking da sfruttare.

Con una copertura dell'automazione inferiore al 40%, la sfida del debito tecnologico si presenterebbe nei seguenti modi:

  • Consumo di tempo eccessivo nei test di rilascio - Con il numero di browser, dispositivi e script che cresce con ogni sprint di test, il ciclo di rilascio continua a subire ritardi con conseguente perdita di time-to-market.
  • Il costo crescente di assunzione - Il numero di tester necessari per supportare il progetto è quasi raddoppiato, il che si è tradotto in $ 500.000 costi aggiuntivi
  • Complessità nel progetto - Con la crescente complessità del progetto, tenere traccia dei casi di test e dei bug stava diventando una sfida
  • Troppo tempo sprecato nell'inseguire falsi positivi - Ancora una volta, una ricaduta delle crescenti complessità del progetto.
  • Aumento dello sforzo di sviluppo dei test fino al 60% - Va con il territorio

Gestione del debito tecnologico nelle pratiche di QA

La maggior parte dei responsabili del controllo qualità vede impulsivamente il debito tecnologico come la ragionevole conseguenza di concentrare tutte le proprie energie solo sullo sprint corrente, il che porta a raggiungere la copertura del test in qualche modo attraverso mezzi manuali e ignorare completamente l'automazione.

Questo è noto come approccio veloce e sporco che è stato trattato in un blog da Martin Fowler, l'autore del quadrante debito tecnico .

I principi agili impongono di visualizzare il problema del debito tecnologico come un'incapacità di sostenere e soddisfare Benchmark QA .

Infatti, basato su un sondaggio dal National Institute of Standards and Technology (NIST), strumenti e metodi di test insufficienti costano ogni anno all'economia degli Stati Uniti $ 22,2 e 59,5 miliardi di dollari , con circa la metà di questo denaro speso per test aggiuntivi da parte degli sviluppatori di software e circa la metà da parte degli utenti di software per evitare errori.

Invece di reagire ai guasti come e quando si verifica l'incidente, un approccio proattivo sarebbe identificare i difetti dopo ogni attività o compito che può essere misurato. Puoi fare tutto manualmente, ma date le migliaia di scenari di test case per un progetto medio, il controllo automatizzato dei test è una necessità.

Chiaramente, test efficaci può aiutarti a guadagnare terreno nella guerra al debito tecnico. Quindi, cosa significa fondamentalmente? Significa quanto è ben attrezzato il tuo sistema per identificare i difetti nell'applicazione complessiva.

testare l

Come mostra l'equazione sopra, l'efficacia del test case può teoricamente avvicinarsi anche al 100% se il numero di difetti riscontrati dal cliente (cioè i difetti di post-produzione) fosse stato mappato precisamente al numero di difetti riscontrati in ciascuna fase della copertura del test.

Per avere un banco di prova ben progettato in grado di misurare con precisione i difetti non appena si insinuano, l'automazione è un prerequisito.

Testare l'automazione consente di ridurre al minimo il numero di script in esecuzione riportando i risultati e confrontandoli con le precedenti esecuzioni di test. Il metodo o il processo utilizzato per eseguire l'automazione è chiamato test automazione struttura .

Esempi tipici potrebbero essere strumenti commerciali o gratuiti come Selenium, MonkeyTalk, robot , Borland SilkCentral, HP Quality Center e IBM Rational Rose .

In passato, il controllo qualità / test era spesso visto dalle organizzazioni e dai loro team software come un'attività di supporto per i risultati aziendali più importanti e non come una pratica disciplinata a sé stante che richiedeva un focus centrale e dedicato. In effetti, un approccio non fondamentale al QA / test è esattamente ciò che ha portato alla sfida continua del debito tecnico in primo luogo.

Considerando il rapido ritmo di evoluzione delle capacità di controllo qualità / verifica che si è verificato nell'ultimo decennio, le organizzazioni stanno avendo davvero difficoltà a migliorare le proprie capacità e competenze ai livelli minimi desiderati secondo gli attuali benchmark di settore.

In effetti, c'è una crescente tendenza del settore ad accontentarsi di niente di meno che i professionisti più esperti nell'automazione dei test - un po 'come i commando d'élite di test / QA; sono conosciuti come ingegneri del software in test ( Da ) e sviluppatori di software in prova ( SDiT ). Questi professionisti sono molto richiesti a causa della loro vasta esperienza in un verticale scelto (es. E-commerce) o in una particolare categoria professionale.

La maggior parte delle società di sviluppo di software e prodotti, mentre parliamo ora, stanno lottando per trovare le risorse tecniche desiderate e qualificate a fronte di tempi di consegna più brevi. La soluzione a questa sfida è collaborare con un operatore di automazione QA offshore in grado di affrontare la carenza di competenze con il giusto pool di risorse SDiT / SEiT.

Altri attributi desiderati di un attore in outsourcing in QA / Testing che si dimostrano utili includono un approccio agile e disciplinato all'esecuzione del progetto, esperienza nel settore sufficiente, compreso l'accesso pratico a framework di automazione e casi di test riutilizzabili e, ultimo ma non meno importante, un chiaro intento e capacità di affrontare le sfide del team remoto e gli scontri culturali in modo che il cliente non sia gravato da un lavoro extra nella gestione degli appaltatori.

crea un nuovo progetto java in eclipse

Conclusione

Come ogni altro debito, il debito tecnico può rivelarsi la rovina delle imprese e la causa principale del suo accumulo è la mancata implementazione di una pratica di QA proattiva che rimuove tutti gli arretrati nell'automazione.

Sull'autore: Questo è un guest post del team eInfochips. Hanno escogitato un approccio unico chiamato Debito tecnologico zero che è uno dei modi più strutturati ed efficienti per eliminare gradualmente il debito tecnico nelle attività di QA / automazione. Per saperne di più sul debito tecnologico, guarda questo video su un approccio per ridurre il reparto tecnologico.

Spero che tu abbia un'idea chiara di cosa sia il debito tecnico. Facci sapere se hai domande ad esso relative o come gestirlo in pratica.

Lettura consigliata

^