I test software vengono effettivamente eseguiti su progetti professionali?

Sono stato coinvolto in molti progetti in diverse aziende perché sono uno sviluppatore da molto tempo e sono un appaltatore.

Stimo che meno del 20% dei progetti viene testato metodicamente. Con metodicamente testato intendo qualsiasi test oltre al test ad hoc senza piano.

Stimo anche che meno del 10% dei progetti viene accuratamente testato metodicamente laddove hanno tester dedicati come parte del team, documento del piano di test, in cui gli sviluppatori scrivono test automatici e quindi tengono traccia della copertura dei test e misurano i risultati.

Due domande

1. Quali sono le tue stime percentuali su questo problema?
2. Qual è la tua esperienza professionale in merito ai test del software?

Nota aggiuntiva

Poiché la domanda di test metodici può ottenere risposte piuttosto distorte (alla gente piace vantarsi di essere superiore agli altri), incoraggio anche altri sviluppatori (quelli che non sono esposti a test metodici) a fornire la loro risposta, perché altrimenti sembrerà che i test siano fatto ovunque ... tranne che nella tua azienda.

Lo schema che ho visto con i test durante la mia carriera mostra una forte corrispondenza con il rischio di fallimento in un progetto. I progetti di grandi dimensioni hanno maggiori probabilità di essere testati rispetto a quelli di piccole dimensioni, le applicazioni mission-critical hanno maggiori probabilità di essere testate rispetto ai siti web di marketing, nei sistemi interni hanno meno probabilità di essere testate rispetto a quelle rivolte al pubblico.

Detto questo, ci sono ancora progetti che sono stati testati eccessivamente e quelli che non sono stati testati abbastanza, ma questi sono la minoranza.

Tutto ciò che produciamo viene completamente testato. Se il nostro team interno di QA è sovraccarico, abbiamo un team offshore che verifica i progetti. Non sono buoni come il nostro team interno, ma questo è un argomento diverso.

Le tre società per cui ho lavorato negli ultimi 15 anni hanno avuto tutti test unitari che sono stati eseguiti automaticamente.

In due di quelle aziende ho spinto per presentarle.

Negli ultimi 9 anni, ho sostanzialmente incontrato solo test di accettazione / regressione. Ci sono stati solo alcuni test unitari.

Sì.

La quantità di test è proporzionale all'affidabilità richiesta dall'app, nonché alla maturità della cultura del programmatore.

I siti web sono abbastanza spesso a piedi buche (i collegamenti interrotti sono un difetto).

I videogiochi sono spesso buggy.

Windows (finalmente) è abbastanza affidabile.

I router sono molto affidabili

I monitor dell'ospedale "non si rompono"

Si noti che anche il costo fiscale del fallimento è correlato all'affidabilità.

In 10 anni non ho mai lavorato a un progetto con test del codice formale.

Nel mio attuale lavoro abbiamo solo test funzionali.

Il problema è che nessuno nella direzione è a conoscenza del test del codice. Il reparto test non conosce nemmeno i test del codice, segue semplicemente le specifiche di alto livello e verifica se rispettiamo dal punto di vista comportamentale / funzionale.

Non abbiamo un leader software qualificato che ci costringe a programmare bene. Il risultato è un codice spaghetti, molte regressioni, orari persi e così via ...

Siamo una società offshore di medie dimensioni nell'Asia meridionale. Tuttavia, facciamo sempre progetti con sede negli Stati Uniti e lavoriamo direttamente con i requisiti inviati dalla società USA.

Applichiamo test metodici su ogni applicazione che costruiamo. Forse la qualità dei test non è all'altezza degli standard, ma li impieghiamo.

Per quanto il purista in me non voglia accettare che ci debba essere un po 'di gestione del rischio integrata nella decisione su quanto test rigorosamente o se si eseguono test formalizzati. Per le app interne, che sospetto siano una grande percentuale di progetti di programmazione, il costo di rilascio di un bug e di patching rapido dopo che è stato notato a volte può essere compensato dal costo di un team di test completo. Ovviamente dipende dall'app e dal costo potenziale dei guasti.

Detto questo, non credo che la pianificazione della gestione del rischio sia la ragione della mancanza di test formalizzati. Penso che sia più il risultato di manager non tecnici che non comprendono il valore che fornisce e vedono solo il costo.

Il mio campione è molto piccolo da cui dedurre le percentuali, ma qui va comunque.

Uno era una società di chip + firmware favolosa, che ha fatto test fanatici. Prove automatizzate 24 ore su 24, 7 giorni su 7, su decine di installazioni, ciascuna in parallelo su decine di unità. Team di software dedicati allo sviluppo di software di test. Team hardware dedicati alla costruzione di banchi prova. Test di compatibilità contro decine di concorrenti. Diamine, hanno persino acquistato un'installazione da molti milioni di tester per chip per sviluppare ed eseguire il debug di alcuni dei test eseguiti dai fab quando i chip lasciano la fonderia.

Un altro era una banca. Questo è un ambiente completamente diverso: nessun rilascio di prodotti, ma un sacco di software interno per continuare a funzionare continuamente. Questi ragazzi hanno testato il cr * p su ogni singola modifica apportata. Avevano una separazione molto rigorosa di ambienti DEV / QA / PROD, test di regressione automatizzati, test di QA obbligatori approvati dagli utenti finali prima di essere rilasciati in produzione, ecc.

Quindi sì, le persone fanno test metodici. Ma come puoi dire, non ho mai lavorato in un posto che spedisca il tuo tipico software GUI per l'utente tipico del computer.

Attualmente scrivo firmware incorporato per una piccola società di avvio che produce dispositivi medici wireless. Ci viene richiesto di eseguire test rigorosi e di avere un reparto qualità completamente separato guidato da qualcuno che riporta direttamente al CEO. Non ho mai avuto il mio codice così accuratamente testato prima da tester separati (l'unica volta che si confronta, è quando stavo lavorando su sistemi di TV satellitare circa 15 anni fa.)

I risultati dei nostri test vengono inviati alla FDA (finora abbiamo ottenuto due autorizzazioni FDA - ogni presentazione era lunga circa 500 pagine). Entrambe le nostre metodologie di sviluppo e test sono entrambe soggette a controlli periodici.

Quindi non sono solo le grandi aziende a fare molti test formali.

Nota: durante i miei oltre 25 anni di programmazione / consulenza contrattuale, ho anche lavorato per molte aziende che praticamente non hanno eseguito test formali. Molti di loro non sono più in giro.

Quasi tutte le aziende in cui sono stato sottoposto a test metodici. La mia attuale azienda ha alcuni test di base sullo stile delle unità e questo non è sufficiente. Abbiamo avuto alcuni problemi di qualità a causa di questo. Consiglio vivamente test approfonditi indipendenti su qualsiasi progetto che verrà utilizzato da chiunque oltre a te stesso. I soldi spesi ne varranno la pena. Le applicazioni che non funzionano non vengono utilizzate. Questo vale sia per il rivestimento interno che per quello esterno.

Negli ultimi venti anni circa della mia carriera in circa otto aziende, non ho mai lavorato a un progetto che non ha effettuato test. La quantità di test differiva in ogni azienda, ma ogni progetto di sviluppo professionale su cui io abbia mai lavorato faceva test formali. Ciò vale sia per le piccole che per le medie imprese (dove "piccola" significa meno di 10 dipendenti e "media" significa un paio di migliaia o meno).

Alcune aziende non avevano molti test automatici, alcuni non avevano molti test manuali, ma ne avevano almeno uno o l'altro.

Dipende dalle esigenze del cliente. In una situazione contrattuale ci sono probabilmente test di accettazione. In-house è di solito uno schiaffo con pochi test. Le cose di consumo sono di solito altamente coperte con funzionalità frequenti ma ruvide ai bordi.

Risposta breve: Sì

Risposta lunga:

1. Non ho una buona stima per la prima categoria (è probabilmente una certa distanza da zero, ma quanto?), Ma la mia esperienza in realtà conferma la tua seconda stima. È difficile fornire percentuali significative poiché la quantità e il tipo di test dipendono dal tipo di applicazione sviluppata, dai tempi disponibili e dal set di competenze degli sviluppatori e da come viene eseguito il progetto. In pratica, l'ostacolo più importante per gli sviluppatori sarebbe il test di accettazione poiché si tratta di una pietra miliare importante ai fini della fatturazione. Ma è anche il momento in cui possono verificarsi imprevisti (più requisiti) e gli sviluppatori possono essere spinti a consegnare e cavarsela con qualsiasi test ad hoc possibile e tempestivo (in questa fase), oltre al tempo necessario per la risoluzione dei problemi e il superamento l'inaspettato.

2. Ho partecipato a una varietà di progetti con una diversa combinazione di fattori sopra menzionati:

   • nessun test unitario formale, solo test di integrazione e per lo più test ad hoc

   • molto formale che va dai test unitari ai piani di test dettagliati che coinvolgono risorse di controllo qualità dedicate, test automatizzati (condotti dai tester con il proprio set di strumenti) e rapporti sulla copertura del codice. Ma questi non sono sempre significativi per gli sviluppatori tanto quanto per i gestori

A livello individuale cerco di mantenere una comprensione delle mie opzioni quando si tratta di scrivere test adeguati adeguati alla tecnologia con cui ho a che fare e di esercitarli a mia discrezione. Fondamentalmente le cose che sono in realtà significative e benefiche per il mio lavoro, e non così tanto da far uscire i numeri.