Non sono sicuro di dove leggi che il v-model ha introdotto il QA nello sviluppo del software. Questa affermazione non ha nemmeno senso. Ciò che fa il modello v è esplicitamente correlato ad alcune delle diverse attività di qualità, come test di accettazione, test di sistema, test di integrazione e test delle unità alle attività a monte a cui sono connessi. Piuttosto che "testare" in seguito a sviluppo e integrazione, le attività di qualità sono esplicitamente collegate alle attività iniziali del ciclo di vita. Tuttavia, non dice nulla su una serie di altre attività di qualità: recensioni e ispezioni, misurazioni e metriche, auditing e rapporti.
La garanzia della qualità del software è un insieme di attività volte a garantire che il prodotto in costruzione mantenga il livello di qualità desiderato sia monitorando il prodotto sia i processi utilizzati per produrre quel prodotto. Al fine di monitorare la qualità, è necessario fare ciò che si riferisce a come attività di "controllo qualità" - test di verifica e validazione - al fine di ottenere sia misure quantitative che qualitative di processo e qualità del prodotto.
La parte di garanzia arriva quando questi dati vengono utilizzati per prevenire i problemi adottando azioni correttive contro i problemi, identificando i problemi in anticipo o modificando i processi per evitare che si verifichino problemi. Ciò include sia il prodotto che il processo. Ad esempio, eseguire revisioni dei requisiti è un'attività V & V, ma integrando un'attività di qualità in primo piano, si è proattivi nell'impedire che un difetto entri nel prodotto in costruzione. Un robusto sforzo di controllo della qualità esaminerà anche il motivo per cui i difetti stanno accadendo e tentano di correggerli, utilizzando strumenti di qualità come il diagramma di Pareto per identificare le principali cause di difetti nei prodotti di lavoro e 5 Why Analysis per determinarne le cause alla radice applica un'azione correttiva. Oltre a considerare i problemi, la garanzia della qualità del software affronta anche le cose che vengono fatte correttamente, oi difetti che stanno effettivamente trovando ed eliminando i difetti nei prodotti di lavoro o nel sistema in fase di sviluppo.
Un altro possibile punto di confusione potrebbe essere quello in cui le organizzazioni considerano il ruolo di un team di garanzia della qualità del software. Nelle mie esperienze, la garanzia della qualità del software tende a concentrarsi maggiormente sulla qualità del prodotto rispetto alla qualità del processo. Al massimo, potrebbero essere responsabili della raccolta di metriche che possono essere utilizzate per la qualità del processo, ma la loro responsabilità principale non è quella di sviluppare il software, ma rispondere alle domande di V & V è stata la cosa giusta ed è stata la cosa giusta costruito a destra.