In che modo il QA può prevenire i difetti?

Mi sembra che ciò che è mancato in tutte le risposte sia l'idea principale del processo di sviluppo stesso. Di cosa tratta un processo di sviluppo? Un processo di sviluppo riguarda principalmente la maturità, la qualità. E la garanzia della qualità non è altro che assicurarsi che il processo sia seguito correttamente. Pertanto, i suoi benefici sono strettamente correlati ad avere un processo di sviluppo.

Immagina i seguenti scenari:

• Un edificio viene creato in una modalità ad hoc.
• Un edificio viene creato seguendo un processo.

Quale edificio presenta (probabilmente) una qualità migliore? Quale (probabilmente) presenta più difetti?

Non è diverso per lo sviluppo del software. Il processo di sviluppo (e la garanzia della qualità) hanno a che fare con i difetti, poiché definisce come devono essere fatte le cose . E questo è fondamentale quando collaboratori con competenze diverse (e umore quotidiano) lavorano insieme. Immagina di nuovo gli scenari sopra citati. Eppure questa volta ci sono diversi ingegneri junior e internisti coinvolti. Quali sarebbero le implicazioni di questo nel caso in cui non sia coinvolto alcun processo?

Fin dall'inizio, il processo di sviluppo (e la garanzia della qualità) assicura che le regole vengano seguite. E quelle regole evitano le circostanze che potrebbero portare a difetti.

Penso che la tua domanda si riduce alla semantica. La frase "prevenzione dei difetti" in realtà non significa nulla. "La prevenzione dei difetti nel prodotto" non è molto più precisa.

La mia ipotesi (ed è proprio quello che è) è che quando gli autori dicono "prevenzione dei difetti nel prodotto" sono non parlando di prevenire la creazione di difetti in qualsiasi codice di sempre. Stanno parlando di impedire che quei difetti si trasformino in un prodotto rilasciato.

Il QA può sicuramente mirare a prevenire i difetti rendendolo un prodotto rilasciato. Non penso che potrebbe impedire a uno sviluppatore di creare un difetto in una build interim interna.

QA previene idealmente i difetti effettuando una analisi delle cause principali sui difetti che sono stati scoperti e identifica e rimuove la radice comune provoca.

Nel contesto dello sviluppo del software, questo sarebbe come sostituire le tecnologie più inclini all'errore con quelle più mature, avere nuovi sviluppatori sistematicamente addestrati, assicurandosi che ci siano test unitari per il codice (ad esempio, tramite la copertura del codice di tracciamento), conducendo revisione del codice o esecuzione di strumenti di analisi del codice statico per identificare aree di codice che potrebbero richiedere miglioramenti e garantire che gli sviluppatori abbiano tempo sufficiente per scrivere test di unità e codice errato di refactoring.

Aneddoto: ho lavorato a un'applicazione per il flusso di lavoro che supportava questo tipo di controllo qualità in un grande produttore automobilistico. Un rapporto era "Le unità vendute in India hanno spesso una rottura del clacson". L'analisi della causa principale ha detto che "Il clacson è progettato per 50.000 cicli di funzionamento, ma a causa dell'uso più intenso in India, questo non è sufficiente". Non so se hanno iniziato a costruire corni più robusti in macchine vendute in India:)

Il QA (Quality Assurance) ei corrispondenti QE (Quality Engineers) dovrebbero rilevare i difetti che sono stati introdotti nel prodotto prima che il prodotto venga rilasciato in produzione. In definitiva, il ruolo del controllo qualità consiste nel rendere il team di sviluppo consapevole dei difetti e il team di sviluppo li risolve. In questo senso, il QA non previene i difetti ma li scopre.

In un altro senso, il QA previene i difetti futuri che sarebbero il prodotto del difetto iniziale se non viene scoperto.

Revisionare le specifiche o qualsiasi altro materiale di ricerca presente prima che il prodotto inizi il suo ciclo di sviluppo può anche aiutare il QA a scoprire difetti che potrebbero essere causati da un'architettura generale del prodotto erroneamente realizzata.

es. Stiamo sviluppando prodotto A perché abbiamo bisogno di rilasciare la funzione X ai clienti. Tuttavia nei cicli futuri dovremmo certamente sviluppare una funzione Y . Pertanto, dobbiamo adeguare l'architettura non solo per supportare la funzione X che stiamo sviluppando, ma anche le future funzionalità Y e Z .

Il controllo qualità verifica se vengono seguite procedure predefinite durante il processo di sviluppo del software. Specifica anche un framework in cui definire queste procedure: ISO-9000, CMMi ...

Quindi il QA garantisce la qualità del processo, non la qualità del prodotto. Si presume che la qualità del prodotto sia coperta seguendo le procedure definite.

In pratica, il QA porta altre coppie di occhi al progetto con un diverso punto di vista, e in realtà rivela difetti del prodotto che potrebbero rimanere nascosti altrimenti.