Perchè tutti considerano UAT un'attività di validazione? È in contraddizione con l'idea originale

1

Praticamente qualsiasi libro che tratti di test del software menziona che il test di accettazione degli utenti (UAT) è un'attività di validazione finale, spesso citando la definizione informale di Boehms: "Convalida: stai costruendo il prodotto giusto?"

Ma come mai lo stesso Boehm considera la UAT una verifica?

LINEE GUIDA PER VERIFICARE E CONVALIDARE REQUISITI DI SOFTWARE E SPECIFICHE DI PROGETTAZIONE. B.Boehm:

From the V-chart, it is clear that the key artifact idstinguishes verification activities from validation activities is the software requirements baseline. This refers to the requirements specification which is developed and validated during the Plans and Requirements Phase, accepted by the customer and developer at the Plans and Requirements Review as the basis for the software development contract, and formally change-controlled thereafter.

By definition,verification involves the comparison between the requirements baseline and the successive refinements descending from it — the product design, detailed design, code, data base, and documentation — in order to keep these refinements consistent with the requirements baseline. Thus, verification activities begins in the Product Design Phase and conclude with the Acceptance Test. They do not lead changes in the requirements baseline; only to changes in refinements descending from it.

On the other hand, validation identifies problems which must be resolved by a change of the requirements specification. Thus, there are validation activities which occur throughout the software life-cycle, including the development phase. For example, a simulation of the product design may establish not only that the design cannot meet the baseline performance requirements (verification), but also that the performance requirements are too stringent for any cost-effective product designs, and therefore need to be changed (validations).

L'unica spiegazione che posso pensare sarebbe che Boehm non ha considerato il test di accettazione come un test di accettazione USER, ma come una sorta di controllo finale rispetto alle specifiche.

Inoltre, credo che questo articolo originale a cui ogni libro fa riferimento sia molto più chiaro di quelle definizioni artificiali di V & V (che sono, inoltre, errate da questo punto di vista). Secondo Boehm, quando controllo i prodotti rispetto ai requisiti, è una verifica. Quando provo il prodotto per il suo utilizzo, lo convalido perché potrei trovare qualcosa che porti a cambiamenti nei requisiti.

Naturalmente l'idea originale di Boehm contraddice alcuni standard, come ISO 12207, in cui la convalida è quella di confermare che i requisiti per uno specifico uso previsto del prodotto di lavoro del software sono soddisfatti. la specifica.

La maggior parte dei libri afferma che la verifica è solo statica e che il codice non viene eseguito. Credo che secondo Boehm, non è vero. Es .:

Software Engineering And Quality Assurance, A.A.Puntambekar: The verification activities fall into the category of static testing.

Effective Methods for Software Testing: Includes Complete Guidelines,William E. Perr: Verification testing - testing in a static mode - ..... Validation testing (e.g. unit, integration ...)

Concluderei che, nonostante le opinioni di molti autori, ritengo che VERIFICATION includa test che vengono eseguiti per verificare la corrispondenza tra le specifiche e il programma. La validazione include anche il test, ma non si baserebbe sulle specifiche.

    
posta user144171 11.12.2014 - 11:55
fonte

2 risposte

5

Nelle sezioni di apertura del foglio che citi , Boehm afferma:

There is very little agreement in the software field on the definitions of the terms "verification" and "validation."

Boehm definisce i termini verifica e convalida come intende utilizzarli nel resto del documento, in modo da poter presentare chiaramente il resto della scrittura senza ambiguità:

Verification - to establish the truth of the correspondence between a software product and its specification. (Note: This definition is derived from the Latin word for "truth," veritas. Note also that data bases and documentation are fit subjects for verification, as well as programs.)

Validation - to establish the fitness or worth of a software product for its operational mission. (Note: This definition is derived from the Latin word for "to be worthy," valere.)

Penso che la Guida al Body of Knowledge dell'ingegneria del software possa fornire alcune informazioni su questo:

Classical treatments suggest that “verification” deals with static evaluation methods and that “testing” deals with dynamic evaluation methods. Recent treatments, including ISO/IEC draft 29119, are blurring this distinction, though, so testing standards are mentioned here.

Ciò che tutto questo dice è che, all'epoca in cui Boehm scrisse il suo articolo, non esisteva una definizione singolarmente accettata per ciò che è "verifica" e che cosa è "convalida". Anche oggi, è ancora vero.

Ora che sappiamo che c'è qualche ambiguità nei termini "verifica" e "convalida" (e in che modo "test" si inserisce in questi), possiamo guardare il diagramma presentato da Boehm.

Qualcosa che Boehm non ha discusso, ma ho visto in più fonti (inclusa ISO / IEC 12207), la convalida richiede specificamente che le attività di convalida si verifichino nell'ambiente operativo e possano raggiungere gli scopi previsti, dal punto di vista dell'utente . Questo può essere implicito nelle definizioni di Boehm, ma non è chiaramente indicato.

Anche Boehm usava il termine "test di accettazione". Stai interpretando questo come "test di accettazione degli utenti". Esistono altri tipi di test di accettazione, come i test di accettazione di fabbrica (FAT). Nella mia esperienza, un FAT viene eseguito dall'organizzazione in via di sviluppo presso il sito dell'organizzazione in via di sviluppo, con le procedure esaminate e accettate dal cliente. Si tratta di un controllo per garantire che il sistema completo (tutto il software e l'hardware) funzioni pienamente, soddisfi le specifiche e un'ispezione finale prima della consegna alla struttura del cliente. Sulla base delle definizioni di Boehm, questa può essere un'attività di verifica che l'organizzazione in fase di sviluppo non può esercitare pienamente nel contesto operativo.

Quello che stai considerando "test di accettazione utente" è probabilmente "OT & E" - Test e valutazione operativa. Si tratta in effetti di un'attività di convalida poiché il cliente e l'utente sono in grado di vedere il prodotto all'interno del contesto operativo e dire se soddisfa o meno le proprie esigenze.

    
risposta data 11.12.2014 - 16:00
fonte
1

Potrebbe essere utile esaminare gli artefatti di test richiesti da ISO 12207 in Verifica e convalida:

Verifica

7.2.4.3.2.3 Code verification.

The code shall be verified considering the criteria listed below:

a) The code is traceable to design and requirements, testable, correct, and compliant with requirements and coding standards.

b) The code implements proper event sequence, consistent interfaces, correct data and control flow, completeness, appropriate allocation timing and sizing budgets, and error definition, isolation, and recovery.

Questo descrive Test unitario e analisi statica, tra le altre cose. I test unitari e l'analisi statica sono al di sotto della linea di base dei requisiti rossa; sono attività verifica .

7.2.4.3.2.4 Integration verification.

The integration shall be verified considering the criteria listed below:

a) The software components and units of each software item have been completely and correctly integrated into the software item.

b) The hardware items, software items, and manual operations of the system have been completely and correctly integrated into the system.

Questo è Test di integrazione, fa ancora parte del processo di verifica.

Validation

7.2.5.3.2.3 [Testing Includes]:

a) Testing with stress, boundary, and singular inputs;

b) Testing the software product for its ability to isolate and minimize the effect of errors; that is, graceful degradation upon failure, request for operator assistance upon stress, boundary, and singular conditions;

c) Testing that representative users can successfully achieve their intended tasks using the software product.

Test di questo tipo sono raramente incorporati nella specifica dei requisiti originali. Normalmente nasce come risultato di test e feedback degli utenti, tra le altre cose. Giustamente appartiene sopra la linea di base dei requisiti e fa parte del processo convalida .

ISO 12207 non sembra fare una distinzione tra test "statici" e "dinamici".

Per quanto riguarda i test di accettazione, il mio punto di vista è che se un requisito è un requisito valido, è testabile. Il test di accettazione è, quindi, il processo di verifica dei requisiti tramite test e appartiene al di sotto della linea di base dei requisiti come parte del processo Verifica .

Di conseguenza, le modifiche ai requisiti software derivanti dagli studi sugli utenti appartengono al di sopra della linea, come parte del processo Validazione .

    
risposta data 11.12.2014 - 18:28
fonte