In che modo le grandi aziende di sviluppatori software verificano la presenza di bug nei loro programmi?

Mi chiedevo come le grandi aziende di sviluppatori di software controllano la presenza di bug nei loro programmi.

Lo testano solo su più computer?

Ecco alcune delle tecniche utilizzate da Google.

1. Assumi buoni sviluppatori che potrebbero produrre codice affidabile.
2. Test unitario pesantemente.
3. Usa la revisione del codice .
4. Imposta una build continua per rilevare problemi di integrazione.
5. Hanno dipartimenti di controllo qualità dedicati. Significa sia test per le persone, sia programmi automatici (ad esempio utilizzando Selenium) che simulano gli utenti finali.
6. Monitorare la produzione per rilevare prove di comportamenti scorretti.

Li ho classificati in quello 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 del test del codice e si assicurano che funzioni come dovrebbe. Di solito è proprio come hai descritto-- un gruppo di persone che testano molte macchine. A volte i test sono automatizzati, a volte no. Vedi garanzia di 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 sto attualmente lavorando, usano la pratica Agile Testing

Direi che riguarda la maturità di un'azienda e non le dimensioni :) Ci sono grandi aziende che hanno cattive pratiche di sviluppo e piccole aziende che sono all'avanguardia.

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 unitari: si tratta di "mini driver" per singoli metodi per garantire che un metodo faccia quello che dice di fare. Questi sono sempre test automatizzati.

Test di integrazione: questi test mirano a verificare che un'unità più ampia di funzionalità funzioni all'interno del sistema. Ciò potrebbe comportare il test dell'integrazione del database o l'integrazione con librerie di terze parti. Anche questi sono test automatici.

Test di accettazione: i test di accettazione sono scritti 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 automatizzato.

Test funzionali: questi test sono simili ai test di accettazione, ma testano anche il "percorso infelice". Questi test significano testare scenari non così ovvi. Può essere manuale o automatizzato.

Test di regressione: usiamo questo termine per eseguire un "test completo" del sistema prima che venga rilasciato ai clienti. Manuale o automatizzato.

Test di gorilla: (solo manuale). Questo è il tipo di test quando gli umani molto intelligenti cercano intenzionalmente di rompere l'applicazione.

Test delle prestazioni Ha lo scopo di assicurarsi che le prestazioni siano accettabili e non si riducano 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 verifica automaticamente il codice, lo compila ed esegue i test automatizzati. I tuoi test più veloci (unità, integrazione) verranno eseguiti ogni volta che uno sviluppatore impegna il codice. Alcuni altri funzionano di notte (accettazione, funzionale) o settimanale (prestazioni, stabilità).

Rapporti sulla copertura del codice: mostra la quantità di codice testata. Il codice che non ha copertura di test ha maggiori probabilità di rompersi.

Diversi strumenti che analizzano il codice: di solito mostrano dove è necessario ricodificare il codice per renderlo meno soggetto a potenziali bug.

Accoppia la programmazione: due sviluppatori 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 pratiche 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 viene archiviato, i test vengono eseguiti su tutto, per assicurarsi che non vengano introdotti nuovi errori.

In secondo luogo, molte aziende hanno reparti di controllo qualità responsabili della convalida del comportamento. Ciò è particolarmente comune in Finance (dove gli errori possono essere costosi e le regole di convalida sono complesse), ma esiste anche in aziende che vendono prodotti agli utenti in cui i richiami possono essere costosi (ad es. Intel, Microsoft, ecc.).

In terzo luogo, quando possibile le aziende eseguono Dogfooding (i loro utenti utilizzano il prodotto internamente) e quindi rilasciano beta limitati. Molti errori vengono colti in questa fase. Ad esempio, le persone che lavorano in Microsoft utilizzano versioni interne più recenti di Office e Windows e DevStudio rispetto a quelle che possiedi all'esterno. Quindi gruppi limitati di utenti o società a contratto possono provarlo. Allo stesso modo, in Google utilizziamo le versioni interne di GMail e Docs prima del rilascio. Le società di gioco organizzano beta aperti per testare i loro prodotti e il carico sui server, ecc.

Ovviamente la risposta è "Spende", ma fornirò un campione del mio più grande progetto finora, che ha coinvolto all'ora di punta circa 50 sviluppatori coinvolti.

La configurazione di base: un software di backend 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 quotidianamente per tutto ciò che è stato verificato nel controllo del codice sorgente e di solito alcuni di essi sono stati eseguiti manualmente dallo sviluppatore prima del check-in. I test unitari sono stati scritti principalmente dagli sviluppatori, ma talvolta modificati con test aggiuntivi da parte dei tester.

Il passo successivo è stato un build settimanale di Virtual PC, in cui i tester hanno eseguito una serie di test end-to-end principalmente automatici sul flusso di dati in base ai documenti delle specifiche per ciascun componente.

Successivamente lo stesso Virtual PC è stato arricchito con alcuni dati aziendali piuttosto vicini alla realtà e testato nuovamente con alcuni casi d'uso specifici.

Quindi il Virtual PC è stato messo insieme ad altri componenti di sistema (anche per lo più virtuali) di altri reparti in un ciclo di test di integrazione basato su test end-to-end da parte dell'utente che immetteva i dati fino alla fine del flusso di dati.

Su un'altra traccia i pacchetti di installazione sono stati testati dal provider di sistemi per vedere se si installavano correttamente in un ambiente simile alla produzione e se potevano essere ripristinati se qualcosa non funzionava.

Dopo l'installazione in un ambiente simile alla produzione, abbiamo eseguito test di carico e stress lì per testare la stabilità generale (non qualcosa da prendere alla leggera quando si esegue su 10 server BizTalk, 8 server SQL e un sacco di altro hardware specializzato come un acceleratore XML e un archivio dedicato, ovviamente tutti raggruppati).

Quando siamo rimasti soddisfatti di tutti i test, il codice è stato messo in produzione. Hai 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 ​​migliore che abbia mai visto finora. Ancora una volta, questo è abbastanza importante in 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 concettualmente più generica, rispetto alla maggior parte delle risposte altamente dettagliate fornite.

Vediamolo 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 recentemente (in una fase di costruzione) implementati nel codice sorgente.

Avere le storie / i requisiti ben definiti è essenziale per il team Quality Assurance (QA) (i veri tester del software) per convalidare il codice finale, quando eseguito, risponde alle richieste di tali storie e requisiti. Pertanto, per tale scopo, il team addetto al controllo qualità crea "prove" per eseguire tale convalida.

Il codice, una volta rilasciato al team QA, verrà quindi testato e verranno identificati i bug. Bug di tipi e gravità diversi. Questi bug vengono tracciati e gli sviluppatori li assegnano per risolverli.

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 di controllo qualità.

Spero che ciò ti aiuti a comprendere (approssimativamente) il processo generale.

Beh, odio essere cinico, ma con il numero di bug aperti in un determinato sistema operativo 'dispositivo' sembra che più grande e ricca è l'azienda, più bug sono in grado di creare e distribuire all'utente finale. Se il software funziona e sembra bello, lo rilasciano comunque. Se i gestori pensano che sia pronto, allora è pronto. Questo è quando i bug davvero cattivi iniziano a uscire dal legno e gli utenti finali diventano cavie. Dieci anni dopo, la maggior parte dei bug sarà stata risolta (e alcuni aggiunti per una buona misura) e la società sarà pronta per passare alla prossima grande idea.