Come mai la verifica non include i test effettivi?

Poiché questa domanda ha creato qualche controversia, lasciatemi iniziare questa risposta con il mio background: oltre ad essere esposto a V & V nel lavoro di progetto quotidiano, ho lavorato per diversi anni nel reparto di ingegneria del software della mia alma mater e sono un docente di ingegneria del software. Mentre questo non garantisce che tutto ciò che dico sia corretto, spero che almeno mi dia il beneficio del dubbio che ci possa essere del vero in questa risposta.

Permettimi di assicurarti che non sei così confuso come potresti credere di essere. Ciò che hai affermato nella tua domanda è tanto vero quanto fuorviante. Permettetemi innanzitutto di sottolineare ciò che avete affermato correttamente:

• Verifica = crea il prodotto giusto vs validation = crea il prodotto giusto
• Le tecniche statiche sono parte della verifica, principalmente perché prendono il tuo programma e alcuni input formali derivati dai requisiti e li valutano l'uno contro l'altro.
• La verifica garantisce la corretta implementazione dei requisiti (ad esempio, l'hai creata nel modo giusto)

Ora lascia che ripulisca la confusione su testing . Innanzitutto, come già affermato in molti commenti, la verifica dinamica del codice tramite test automatici (unità, integrazione, ...) fa parte della verifica. Ciò che causa la maggior parte della confusione, tuttavia, è che le persone in convalida parleranno di test , ma significano qualcosa di diverso: in fase di validazione, il test di solito coinvolge una persona che utilizza l'applicazione per lo scopo previsto. Nel caso ottimale, questo è il cliente stesso.

Tuttavia, gli "errori" [1] rilevati dai test di verifica e di convalida differiscono sostanzialmente:

• errori di test di verifica: si tratta di errori che violano i tuoi requisiti in un modo o nell'altro.
• errori di test di convalida: si tratta di errori con il prodotto stesso che hai creato, non la sua funzionalità, quindi, rivelano errori nei requisiti.

Per la maggior parte delle persone, aiuta a guardare esempi concreti di diversi casi V & V. I seguenti sono esempi estremi di errori:

• Hai un requisito di basso livello che afferma "f (x) deve restituire x + 1" e l'implementazione di "f" restituisce sempre la costante 2. Potresti trovare questo errore con diversi approcci di verifica diversi, ma probabilmente il tuo cliente non lo troverà durante la convalida, perché stai costruendo un sito di e-shopping e non sa né si cura di "f".

• È richiesto un requisito "Il sistema dovrebbe essere in grado di gestire 1000 richieste al secondo con un carico massimo della CPU dell'80%". Ancora una volta, la validazione avrà un momento difficile, proprio come la maggior parte delle tecniche statiche. In effetti, il modo più semplice per verificare ciò è testare dinamicamente l'applicazione martellandola con le richieste e monitorando il carico della CPU durante quel periodo.

• Considera ancora una volta il requisito sopra per "f", questa volta con un'implementazione "corretta". Tutte le tue recensioni, analisi statiche e test dinamici riportano un successo, ma poi il tuo cliente verifica il tuo software e ti dice che gli manca l'icona del carrello sulla pagina web. Nessun numero di verifica sarà in grado di trovare questo errore, come è stato fatto durante la fase dei requisiti.

Come puoi vedere, "testing" - se non definito in modo più preciso - fa parte sia della verifica che della convalida, e infatti, "testing" deve essere eseguito per entrambi.

[1] "errore" è usato colloquialmente qui, in modo da evitare la distinzione tra errore, errore, errore, errore, ...

In effetti: la verifica dimostra che stai costruendo il prodotto giusto, mentre la convalida costruisci il prodotto giusto.

Quindi

• la verifica sta dimostrando il processo ... che hai seguito gli standard e le procedure richiesti, solitamente controllati dall'analisi statica e dalla revisione del codice.
• la convalida sta dimostrando il prodotto risultante ... che il codice fa ciò che è richiesto, di solito controllato da analisi e test dinamici, per mostrare che gli input specificati generano output specificati

Di solito non cita Wikipedia , ma in questo caso è utile ...

Una spiegazione più dettagliata dei due processi può essere trovata nei processi di ciclo di vita del software ISO 12207 (una delle altre risposte pubblica un collegamento a una copia non controllata):

7.2.4.3.2 Attività di verifica

• Verifica dei requisiti
• Verifica del progetto
• Verifica del codice
• Verifica dell'integrazione
• Verifica della documentazione

7.2.5.3.2 Task di convalida

• Prepara requisiti, casi e specifiche di prova
• Esegui i test

Ora, la domanda di apertura chiedeva perché la verifica non includesse il test. E nonostante alcune delle altre risposte, dai membri di alta reputazione di P.SE, ti ho detto che non è questo il punto dell'attività verifica , ma della validazione attività.

Alcune risposte suggeriscono di avere per testare per verificare il codice o l'integrazione. No - quell'attività è dimostrare la modularità e le interfacce, ecc., Non l'esecuzione.

In pratica, ciò che questa discussione mostra è che c'è molta confusione su cosa sia verifica e cosa sia validazione , e questo non è aiutato dal fatto che il confine sia un'area grigia e definita in modo leggermente diverso in standard diversi.

Ciò che è importante è che entrambe le parti del V & V debbano essere coperte, e finché questo è il caso allora semanticamente, non importa se sia V o V ... solo V e V.