Esiste qualcosa come un'applicazione priva di bug? [duplicare]

Quanto più ti avvicini a un'applicazione senza bug, tanto più costosa. È come puntare al 100% di copertura del codice: passi la stessa quantità di tempo e denaro dallo 0% al 95%, dal 95% al 99% e dal 99% al 99,9%.

Ti serve questo extra 0,1% di copertura o qualità del codice? Probabilmente sì, se stai lavorando a un prodotto software che controlla il sistema di raffreddamento di un reattore nucleare. Probabilmente no se stai lavorando su una applicazione aziendale.

Inoltre, la realizzazione di software di alta qualità richiede un approccio molto diverso . Non puoi chiedere a un team di sviluppatori che hanno passato la vita a scrivere app di business per creare un'applicazione quasi priva di bug. Il software di alta qualità richiede tecniche diverse, ad esempio prova formale , qualcosa che certamente non fai " t voglio usare in un'app business, a causa del costo estremamente elevato che rappresenta.

Come ho spiegato in uno dei miei articoli :

• Le app aziendali non dovrebbero mirare alla qualità richiesta per il software vitale, perché se queste app di business falliscono di volta in volta, non importa. Ho visto bug e tempi di fermo nei siti Web di probabilmente ogni grande azienda, Amazon è l'unica eccezione. Questi tempi di inattività e questi bug sono fastidiosi e forse costano all'azienda alcune migliaia di dollari al mese, ma sistemarli sarebbe molto più costoso.

• Il costo dovrebbe essere l'obiettivo principale e dovrebbe essere studiato pragmaticamente. Immaginiamo un bug che interessa 5 000 clienti ed è così importante che quei clienti se ne andranno per sempre. È importante? Sì? Pensa di più. Che cosa succede se dico che ognuno di questi clienti paga $ 10 all'anno e che costerà quasi $ 100 000 per correggere l'errore? La correzione dei bug ora sembra molto meno interessante.

Ora rispondi in modo specifico alle tue domande:

why do bugs get reported even after going through so much testing? Is it our requirements issue? Our client doesn't seem happy for anything we provide? are we doing something incorrect?

Molte cose possono andare storte. Testando, intendi test automatici effettivi? In caso contrario, questo è un enorme problema su se stesso. I tester comprendono i requisiti? Comunica regolarmente con il cliente, almeno una volta per iterazione, nella migliore delle ipotesi il rappresentante del cliente è immediatamente raggiungibile sul posto da qualsiasi membro del tuo team ? Le tue iterazioni sono abbastanza brevi? Gli sviluppatori stanno testando il proprio codice?

Analogamente a Scrivono l'articolo giusto linkato sopra, prendi un bug report e studia perché questo bug è apparso in primo luogo e perché è stato perso da ogni tester . Questo potrebbe darti qualche idea sulle lacune nel processo del tuo team.

In un punto importante da considerare: il cliente paga per le correzioni dei bug? In caso contrario, potrebbe essere incoraggiato a considerare molte cose come un bug. Farlo pagare per il tempo che dedichi ai bug ridurrà considerevolmente il numero di segnalazioni di bug.

Has anyone developed any application that were totally bug free? What is the process? Why can't we deploy the application with minor bugs? Are we supposed to be perfectionist?

Me. Ho scritto un'app per me lo scorso fine settimana e finora non ho trovato alcun bug.

I bug sono solo bug quando vengono segnalati. Quindi, in teoria, avere un'applicazione senza bug è totalmente possibile: se non è usato da nessuno, non ci sarà nessuno a segnalare bug.

Ora, scrivere un'applicazione su larga scala che corrisponda perfettamente alle specifiche e che si è dimostrato corretto (vedere la prova formale sopra menzionata) è una storia diversa. Se questo è un progetto vitale, questo dovrebbe essere il tuo obiettivo (che non significa che la tua applicazione sarà priva di errori).

Is the current scenario the correct process of development and testing? If not what is an efficient way where developers,testers and client gets the maximum benefit together?

1. Per capirsi, devono comunicare. Questo non è quello che succede nella maggior parte delle aziende che ho visto. Nella maggior parte delle aziende, il project manager è l'unico che parla con il cliente (a volte con un rappresentante). Quindi condivide (a volte in parte) la sua comprensione dei requisiti con sviluppatori, designer di interazione, architetti, amministratori di database e tester.

   Questo è il motivo per cui è essenziale che il cliente (o il rappresentante del cliente) sia raggiungibile da chiunque nel team (approccio Agile) o che disponga di mezzi di comunicazione formale che autorizzano una persona a comunicare solo con poche altre persone su un squadra e farlo in modo che le informazioni possano essere condivise con tutto il team, assicurando che tutti abbiano le stesse informazioni.

2. Esistono molti processi per lo sviluppo e il test. Senza conoscere precisamente l'azienda e il team, non è possibile stabilire quale debba essere applicato nel tuo caso. Prendi in considerazione l'assunzione di un consulente o l'assunzione di un project manager abbastanza abile.

Non tutti i bug sono stati creati uguali, quindi devi separare il grano dalla pula.

Le aspettative

Molti bug vengono generati semplicemente a causa di una carenza di ciò che il software fa e di ciò che l'utente finale si aspetta. Questa aspettativa viene da molte aree: utilizzo di altri software, documentazione errata, personale di vendita eccessivamente zelante, come funziona il software ecc.

Scope creep

Inutile dire che più consegni, maggiore è il potenziale di bug. Molti bug vengono semplicemente generati sul retro di nuove funzionalità. Offri X & Sì, ma il cliente dice che ora dovrebbe fare anche Z.

Comprendi il dominio problematico

Molti bug si verificano per la semplice ragione che il dominio del problema è stato capito male. Ogni cliente ha le proprie regole di business, gergo e modi di fare le cose. Molto di questo non sarà documentato da nessuna parte, sarà solo nelle teste delle persone. Con la migliore volontà del mondo, non puoi sperare di catturare tutto questo in un solo passaggio.

Quindi ... cosa fare al riguardo.

Test unitari automatizzati

Molti bug vengono introdotti come un effetto collaterale inaspettato di alcuni cambiamenti di codice o altro. Se disponi di test unitari automatizzati, puoi risolvere molti di questi problemi e produrre un codice migliore fin dall'inizio.

I test valgono solo quanto i dati forniti, quindi assicurati di comprendere completamente il dominio del problema.

Copertura del codice

Questo va di pari passo con i test automatici delle unità. Dovresti assicurarti che tutto il codice sia testato come è pratico.

Impara le lezioni

Madness sta facendo la stessa cosa ancora e ancora e ancora e in attesa di risultati diversi

Capisci le cause dell'ultimo errore? Fai? Veramente? Potresti aver fermato il problema ma quale era la vera fonte di root? Cattivi dati? Errore utente? La corruzione del disco? Interruzione di rete?

Niente infastidisce i clienti più che incontrare gli stessi problemi ancora e ancora senza progressi verso una qualche forma di risoluzione.

I difetti sono esistiti dall'inizio dello sviluppo del software. È difficile dire dalla domanda in che misura e in quale gravità i difetti influiscono sull'usabilità o sulla funzionalità.

Esistono programmi privi di difetti, ma qualsiasi sistema non banale avrà difetti.

Dovrai decidere un qualche tipo di prioritizzazione e probabilmente dovrai studiare la causa dei difetti - dove sono stati introdotti. C'è molto da discutere su queste cose in un semplice Q & post.

Sono stati scritti interi libri sull'analisi causale e sui processi di risoluzione per un'organizzazione che ha problemi di qualità.

Quindi la mia raccomandazione è di: (in nessun ordine particolare)

• Implementa un sistema di tracciamento dei difetti se non ne hai già trovato uno
• Determina un modo per classificare la gravità dei difetti
• Scopri perché non soddisfi le aspettative dei clienti (sono gli sviluppatori, il controllo qualità, il cliente, ecc.)
• Scopri alcuni esercizi come i "Cinque perché" e fai un'indagine simile su alcune delle cause dei tuoi difetti.

Dipende da ciò che chiami un'applicazione.

Se intendi, un programma interattivo in cui devi essere certo che il comportamento in tempo reale sia esattamente tale e tale in qualsiasi circostanza, allora è praticamente impossibile dimostrare che non ci siano bug in esso. Suppongo che sarebbe possibile se potessi risolvere il problema di interruzione , ma non puoi.

Tuttavia, se ti limiti a una dichiarazione di "tale e tale input finirà per produrre un tale stato finale", allora le tue probabilità di una "prova senza bug" sono migliori, perché puoi usare gli invarianti . Questo, e solo quello, consente di correggere una prova di correttezza in sottoproblemi, ognuno dei quali può essere relativamente facile funzionare correttamente in tutte circostanze del programma rimanente (anche se generalmente non è possibile molto preciso su quanto tempo e memoria potrebbe richiedere).

Tali tecniche sono fondamentalmente possibili in qualsiasi linguaggio di programmazione (sebbene alcuni elementi esoterici come Malbolge provino a smentire che !), ma in tutti i linguaggi imperativi diventa molto caotico, perché devi meticolosamente tenere traccia di molti stati impliciti del programma. Nelle lingue funzionali ¹ , le dimostrazioni tendono ad apparire molto più belle ( lingue pure , o semplicemente -insieme funzionale di una lingua). Tuttavia, in particolare con i tipi dinamici, è necessario scrivere molti requisiti su quali input sono consentiti. Questo è ovviamente uno dei principali vantaggi dei sistemi di tipo statico strong: i requisiti sono proprio lì nel codice!
Beh, idealmente, questo è. In pratica, i programmi O'Caml o anche Haskell tendono a contenere funzioni non totali , ovvero funzioni che si bloccano / si bloccano / generano per determinati input, nonostante il tipo corretto ² . Perché anche se questi linguaggi hanno sistemi di tipi molto flessibili, a volte non è ancora fattibile usarlo per limitare completamente qualcosa.

Inserisci lingue tipizzate in modo dipendente ! Questi possono "calcolare" i tipi esattamente come necessario, quindi tutto ciò che definisci può avere esattamente il tipo di firma che ti dà tutto ciò di cui hai bisogno. E in effetti, le lingue tipizzate in modo dipendente vengono principalmente insegnate come ambienti di prova . Sfortunatamente, penso che nessuno di loro stia davvero scrivendo software di produzione. Per le applicazioni pratiche, penso che il più vicino possibile a completamente a prova di bug stia scrivendo in Haskell con tutte le funzioni più complete possibili. Questo ti rende carino vicino a a prova di errore - anche se, ancora una volta, solo per quanto riguarda la descrizione funzionale. Il modo unico di Haskell di gestire l'IO con le monadi fornisce anche alcune prove molto utili, ma generalmente non ti dice nulla su quanto tempo ci vorrà per finire qualcosa. Molto probabilmente, qualcosa potrebbe richiedere del tempo esponenziale in particolari circostanze - dal POV dell'utente, che sarebbe probabilmente un bug grave come se il programma si bloccasse completamente.

¹ _{O più in generale, lingue descrittive . Non ho molta esperienza con i linguaggi logici, ma suppongo che possano essere ugualmente belli per quanto riguarda le prove.}

² _{Se non è del tipo corretto, il compilatore mai non lo consentirà in quelle lingue; che già elimina un sacco di bug. (E, grazie all'inferenza di tipo Hindley-Milner, rende anche i programmi più concisi!)}