I test del software sono effettivamente eseguiti su progetti professionali?

Lo schema che ho visto con i test sulla mia carriera mostra una strong corrispondenza con il rischio di fallimento in un progetto. I progetti più grandi hanno maggiori probabilità di essere testati rispetto a quelli piccoli, le applicazioni mission-critical hanno più probabilità di essere testate rispetto a un sito web di marketing off, nei sistemi di casa è meno probabile che siano testati rispetto a quelli pubblici.

Detto questo ci sono ancora progetti che sono stati testati in modo eccessivo 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 controllo qualità è sovraccarico, abbiamo una squadra offshore che testa i progetti. Non sono buoni come il nostro team interno, ma questo è un argomento diverso.

Le tre società per le quali ho lavorato negli ultimi 15 anni hanno tutte eseguito test unitari eseguiti automaticamente.

In due di quelle aziende ho spinto per introdurle.

Negli ultimi 9 anni, ho praticamente superato solo i test di accettazione / regressione. C'erano 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 spesso camminano per i bug-hole (i collegamenti interrotti sono un difetto).

I videogiochi sono spesso buggy.

Windows (finalmente) è abbastanza affidabile.

I router sono molto affidabili

I monitor ospedalieri "non si rompono"

Si noti che il costo fiscale dell'errore è anche correlato all'affidabilità.

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

Nel mio attuale lavoro abbiamo solo test funzionali.

Il problema è che nessuno nella gestione nemmeno conosce il test del codice. Il reparto prove non sa nemmeno del test del codice, semplicemente segue le specifiche di alto livello e verifica se siamo conformi da un punto di vista comportamentale / funzionale.

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

Siamo una società offshore di medie dimensioni in Asia meridionale. Tuttavia, facciamo sempre progetti basati negli Stati Uniti e lavoriamo direttamente con i requisiti inviati dalla compagnia statunitense.

Applichiamo test metodologici 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 una gestione del rischio incorporata nella decisione per quanto rigorosamente si prova o se si eseguono test formalizzati. Per le app interne, che sospetto siano una grande percentuale di progetti di programmazione, il costo di rilasciare un bug e di applicarlo rapidamente dopo che è stato notato può a volte essere superato dal costo di un team di test completo. Ovviamente dipende dall'app e dal costo potenziale dei guasti.

Detto questo, non penso che la pianificazione della gestione del rischio sia la ragione della mancanza di test formalizzati. Penso che sia più un risultato di manager non tecnici che non capiscono 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 un produttore di chip + firmware favoloso, che effettuava test fanatici. Test automatici 24 ore su 24, su decine di installazioni, testando ciascuna decine di unità in parallelo. Team di software dedicati allo sviluppo di software di test. Team di hardware dedicati alla costruzione di banchi di prova. Test di compatibilità contro decine di concorrenti. Diamine, hanno persino comprato un'installazione multimetro multimetro per sviluppare e mettere a punto alcuni dei test che i fabs funzionano 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 in-house per continuare a funzionare continuamente. Questi ragazzi hanno testato il cr * p di ogni singolo cambiamento che hanno fatto. Hanno avuto una separazione molto rigida tra ambienti DEV / QA / PROD, test di regressione automatizzati, test QA obbligatori firmati dagli utenti finali prima di essere rilasciati in produzione, ecc.

Quindi sì, le persone fanno test metodici. Ma come puoi capire, non ho mai lavorato in un posto in cui è presente il tipico software della GUI per il tipico utente di computer.

Quasi tutte le società che ho fatto hanno fatto test metodologici. La mia attuale compagnia ha alcuni test di stile unitari di base 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 varrà la pena. Le applicazioni che non funzionano non vengono utilizzate. Questo vale sia per il lato interno che per quello esterno.

Negli ultimi venti anni della mia carriera in otto o più società, non ho mai lavorato a un progetto che non fare test. La quantità di test è stata diversa per ogni azienda, ma ogni progetto di sviluppo professionale su cui abbia mai lavorato ha effettuato test formali. Ciò vale sia per le piccole e medie imprese (dove "piccolo" significa meno di 10 dipendenti, e "medio" significa un paio di migliaia di dipendenti 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 di contratto ci sono probabilmente test di accettazione. In casa di solito è uno schiaffo con pochi test. Le cose per i consumatori sono solitamente coperte da 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à corrobora la tua seconda stima. È difficile dare percentuali significative in quanto la quantità e il tipo di test dipendono dal tipo di applicazione in fase di sviluppo, dai tempi disponibili e dalle competenze degli sviluppatori e dal modo in cui viene eseguito il progetto. In pratica, l'ostacolo più importante per gli sviluppatori sarebbe il test di accettazione dal momento che è un traguardo importante ai fini della fatturazione. Ma è anche il momento in cui può accadere l'imprevisto (più requisiti) e gli sviluppatori possono essere costretti a fornire e ottenere con qualsiasi test ad hoc che sia possibile e tempestivo (in questa fase), il tempo necessario per la risoluzione dei problemi e il superamento l'inaspettato.

2. Ho partecipato a una serie di progetti con diverse combinazioni di fattori menzionate sopra:

   • nessun test unitario formale, solo test di integrazione e soprattutto test ad hoc

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

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