Mi stavo chiedendo quanto grandi aziende di sviluppatori software controllino i bug nei loro programmi.
Lo testano solo su diversi computer?
Ecco alcune delle tecniche utilizzate da Google.
Le ho classificate in ciò che sospetto sia in ordine decrescente di efficacia nella cattura dei bug.
Le aziende più grandi di solito hanno interi reparti Q / A che sono responsabili per il test del codice e per assicurarsi che funzioni come dovrebbe. Solitamente, come hai descritto tu, un gruppo di persone sta testando molte macchine. A volte i test sono automatizzati, a volte no. Vedi Garanzia della qualità - Wikipedia
Molte volte, gli sviluppatori stessi troveranno bug durante il processo di sviluppo. Inoltre, i clienti sono spesso i primi a trovare un bug.
Le aziende più piccole, come quella per cui lavoro attualmente, utilizzano la pratica di test agile
Direi che è circa la maturità di un'azienda e non le dimensioni :) Ci sono grandi aziende che hanno pratiche di sviluppo carenti e piccole aziende che stanno sanguinando bordo.
In generale un team di sviluppo maturo si impegnerà nelle seguenti attività a 1; minimizzare l'introduzione di nuovi bug nel sistema e 2; trova bug nel sistema esistente.
Test delle unità: sono "mini driver" per i singoli metodi per garantire che un metodo esegua ciò che dice. Questi sono sempre test automatici.
Test di integrazione: questi test mirano a verificare che un'unità più grande di funzionalità funzioni all'interno del sistema. Ciò potrebbe comportare il test dell'integrazione del database o dell'integrazione con le librerie di terze parti. Questi sono anche test automatizzati.
Test di accettazione: vengono scritti test di accettazione per testare i requisiti dell'utente. Questi di solito testano solo il "percorso felice". Nel mio team, questi test sono progettati per dimostrare che se l'utente utilizza la funzionalità così come è stata progettata per essere utilizzata, non avrà problemi. Può essere manuale o automatico.
Test funzionali: questi test sono simili ai test di accettazione, ma testano anche il "percorso infelice". Questi test significano testare gli scenari non così ovvi. Può essere manuale o automatico.
Test di regressione: usiamo questo termine per eseguire un "test completo" del sistema prima che venga rilasciato ai clienti. Manuale o automatico.
Test dei gorilla: (solo manuale). Questo è il tipo di test quando gli esseri umani molto intelligenti cercano intenzionalmente di rompere l'applicazione.
Test delle prestazioni mira a garantire che le prestazioni siano accettabili e non si degradino nel tempo. Di solito automatizzato.
Test di stabilità: questi test sono progettati per garantire che il sistema rimanga stabile nel tempo. Automatizzata.
Integrazione continua: si tratta di un sistema che esegue automaticamente il checkout del codice, lo compila e esegue i test automatici. I test più veloci (unità, integrazione) verranno eseguiti ogni volta che un dev esegue il commit del codice. Alcuni altri funzionano di notte (accettazione, funzionale) o settimanali (prestazioni, stabilità).
Rapporti sulla copertura del codice: mostra quanto del tuo codice è stato testato. Il codice che non ha copertura di prova è più probabile che si rompa.
Diversi strumenti che analizzano il codice: di solito mostrano dove il codice deve essere rielaborato per renderlo meno incline a potenziali bug.
Abbinamento della programmazione: due sviluppatori che lavorano insieme per offrire funzionalità. "Una coppia coesiva è migliore della somma delle sue parti."
Il più importante da portare via è: automazione e integrazione continua .
Dipende dall'azienda e dai prodotti che sviluppa.
Innanzitutto, molte aziende applicano procedure di codifica come revisioni del codice e linting obbligatorio (strumenti di rilevamento automatico dei bug) per ridurre la quantità di errori che si verificano nel repository. Molte aziende hanno anche adottato test unitari. Questo è il caso in cui lavoro (Google). Quando il codice è archiviato, i test vengono eseguiti su tutto, per assicurarsi che non vengano introdotti nuovi errori.
In secondo luogo, molte aziende hanno dipartimenti di controllo qualità responsabili della convalida del comportamento. Questo è particolarmente comune nella finanza (dove gli errori possono essere costosi e le regole di convalida sono complesse), ma esiste anche nelle aziende che vendono prodotti agli utenti in cui i richiami possono essere costosi (ad es. Intel, Microsoft, ecc.).
Terzo, quando possibile le aziende fanno Dogfooding (i loro utenti usano il prodotto internamente) e poi rilasceranno beta limitati. Molti errori vengono catturati in questa fase. Ad esempio, la gente che lavora in Microsoft usa versioni interne più recenti di Office e Windows e DevStudio di quelle che hai all'esterno. Quindi gruppi limitati di utenti o aziende contrattate possono campionarlo. Allo stesso modo, su Google utilizziamo versioni interne di GMail e Documenti prima del rilascio. Le società di gioco organizzano beta aperte per testare i loro prodotti e il carico sui server, ecc.
Ovviamente la risposta è "It dpends", ma darò un campione dal mio più grande progetto fino ad ora, che ha coinvolto al massimo 50 sviluppatori coinvolti.
L'impostazione di base: un software di back-end per l'elaborazione di grandi quantità di dati con BizTalk.
La prima linea di difesa sono i test unitari. Nel nostro caso questi sono stati eseguiti giornalmente per tutto ciò che è stato controllato nel controllo del codice sorgente e solitamente alcuni di questi sono stati eseguiti manualmente dallo sviluppatore prima del check-in. I test unitari sono stati scritti principalmente dagli sviluppatori ma a volte modificati con test aggiuntivi da parte dei tester.
Il passaggio successivo era una build settimanale di Virtual PC, in cui i tester eseguivano una serie di test end-to-end principalmente automatizzati sul flusso di dati in base ai documenti delle specifiche per ciascun componente.
Dopo che lo stesso Virtual PC è stato arricchito con alcuni dati aziendali abbastanza vicini alla realtà e testati di nuovo con alcuni casi d'uso specifici.
Quindi il Virtual PC è stato assemblato con altri componenti di sistema (anche per lo più virtuali) da altri reparti a un ciclo di test di integrazione basato su test end-to-end da parte dell'utente che immette i dati alla fine del flusso di dati.
Su un'altra traccia i pacchetti di installazione sono stati testati dal fornitore di sistemi per verificare se sono stati installati correttamente in un ambiente simile alla produzione e se potevano essere ripristinati in caso di problemi.
Dopo l'installazione sull'ambiente di produzione abbiamo eseguito test di carico e stress per testare la stabilità generale (non qualcosa da prendere alla leggera quando si esegue su 10 server BizTalk, 8 server SQL e un mucchio di altri hardware specializzati come un acceleratore XML e un archivio dedicato - tutto ovviamente in cluster).
Quando siamo rimasti soddisfatti di tutti i test, il codice è stato messo in produzione. Si ottiene una latenza abbastanza grande per correggere i bug nel codice (come 4-6 settimane per l'intero ciclo di test), ed è costoso fare tutti questi test, ma la stabilità complessiva è stata abbastanza buona. In effetti il meglio che ho visto finora. Ancora una volta è abbastanza importante su un sistema che elabora diversi milioni di dollari ogni giorno. Le tue esigenze possono variare, ma è così che l'abbiamo fatto e ha funzionato.
La domanda originale sembra più concettualmente generica della maggior parte delle risposte altamente dettagliate fornite.
Guardiamo da un livello superiore (meno dettagliato). Il software è sviluppato per soddisfare le esigenze specifiche di qualcuno (persona, azienda, qualunque cosa).
Queste esigenze devono essere mappate nelle singole storie / requisiti che sarebbero stati ultimamente (in una fase di costruzione) essere implementati nel codice sorgente.
Avere i racconti / requisiti ben definiti è essenziale per il team di Quality Assurance (QA) (i veri tester del software) per convalidare il codice finale, quando eseguito, si attiene alle richieste di tali storie e requisiti. Quindi, per tale scopo, il team addetto al controllo della qualità crea "testicoli" per effettuare tale convalida.
Il codice, una volta rilasciato al team di controllo qualità, verrà quindi testato e verranno identificati i bug. Bug di tipi diversi e gravità. Questi bug vengono tracciati e gli sviluppatori li assegnano per risolverli definitivamente.
L'utilizzo di macchine virtuali, al giorno d'oggi, consente a un tester di eseguire ambienti diversi in uno stesso hardware reale. Ma a volte finisci per aver bisogno di alcuni computer dedicati alla fase QA.
Spero che questo ti aiuti a capire (approssimativamente) il processo complessivo.
Beh, odio essere cinico, ma con il numero di bug aperti in un determinato sistema operativo "dispositivo" sembra che più grande e ricca è la compagnia, più bug sono capaci di creare e consegnare all'utente finale . Se il software funziona e sembra interessante, lo rilasciano comunque. Se i dirigenti pensano che sia pronto, allora è pronto. In quel momento iniziano a spuntare gli insetti davvero sgradevoli e gli utenti finali diventano delle cavie. Una decina di anni più tardi, la maggior parte degli errori saranno stati risolti (e alcuni aggiunti per buona misura) e la società sarà pronta per passare alla prossima grande idea.