Dev, tester e utenti aziendali dovrebbero avere uno script di test unificato?

In fase di sviluppo, normalmente avrei i miei script di test che documenterebbero i dati, gli scenari e le fasi di esecuzione che intendo testare; questo è il mio piano di test di sviluppo. Quando la funzionalità è stata distribuita su Test, i tester lo testano usando il proprio script di test che hanno scritto. In UAT, l'utente aziendale verifica quindi utilizzando il proprio piano di test.

In retrospettiva, sembra che ciò fornisca una migliore copertura, con i test di sviluppo che hanno un mix di test in bianco e nero, mentre i tester e gli utenti aziendali si concentrano sui test in black box. D'altra parte, ciò porta alla luce distinti casi di test che vengono eseguiti solo per fase (ad esempio alcuni casi a cui i tester pensavano di essere eseguiti solo sulla fase di test) e vorrebbe che lo sviluppatore lo mancasse, il che lo rende una scoperta / bug .

Vale la pena consolidare gli script di test dall'inizio? Quindi, usando uno script di test unificato, o è abbastanza difficile farlo in anticipo?

Innanzitutto il QA non è Test. Se il reparto QA non è coinvolto nell'intero processo di sviluppo, è Test, non QA. Il QA quando fa il suo lavoro, fornisce la garanzia di qualità, nella migliore delle ipotesi Test mostra la mancanza di qualità, ma non può dimostrare che la qualità esiste - vale a dire che il Test mostra che il QA è fallito, ma non può dimostrare che ci sono riusciti, quindi Test e QA non dovrebbero essere lo stesso reparto.

Credo che il modo migliore sia far gestire a ciascun gruppo i propri test, in quanto fornisce una migliore copertura. Tuttavia, ogni squadra dovrebbe iniziare i test il prima possibile. Ciò significa che UAT inizia non appena c'è qualcosa che gli utenti potrebbero essere in grado di utilizzare, Test inizia non appena una parte per cui hanno un test è pronta, ecc. Ciò impedisce la ricerca tardiva di casi di test distinti. Ciò può significare un certo rigonfiamento dei modelli di lavoro, poiché spesso UAT e Test prevedono di lavorare su un prodotto completo e necessitano di formazione per testare risultati parzialmente completi. Può essere più costoso a meno che il flusso di lavoro non sia disciplinato e uno sviluppatore "Completo" significhi Completo.

Il QA dovrebbe supervisionare questo, insieme ad altre misure di qualità, per garantire che il processo non fornisca solo la qualità desiderata, ma anche a un livello di efficacia appropriato.

Modifica: il riferimento alla domanda originale sul QA è stato rimosso, quindi questa risposta ora appare OT.

Usiamo UAT sin dall'inizio.

Funziona come riferimento universale e penso che funzioni bene. Mentre potrebbero esserci degli script di test che vengono utilizzati solo dagli sviluppatori o dai tester per componenti più piccoli, la direzione del test è sempre puntata verso un obiettivo unificato. Alla fine della giornata, l'UAT è l'unico che conta, quindi potresti anche metterlo al centro dell'attenzione.

Fare UAT sin dall'inizio ha anche un ulteriore vantaggio. Risolve davvero ogni ambiguità tra le aspettative del cliente e le tue.

Non hanno bisogno di uno script di test unificato poiché le cose che testano e il modo in cui eseguono i test sono spesso differenti, ciò di cui hanno bisogno è un requisito unificato dal quale tutte le parti stanno lavorando. Se UAT e QA stanno testando cose che lo sviluppatore non ha mai pensato, allora è tempo di esaminare i requisiti.

Concordo sul fatto che avere uno script di test unificato per sviluppatori, tester e utenti aziendali sarebbe bello avere, ma credo che non sia possibile senza un grande sforzo in cui il costo supera il vantaggio.

Il motivo della difficoltà è che il contenuto del database in ogni sistema è diverso e i test di solito dipendono fortemente dal contenuto del database. il nostro approccio ai "test unificati" era che ogni sistema riceve anche un database di test aggiuntivo e ci sono script per creare quel db da zero. gli script di test vengono eseguiti sul testdb in cui il contenuto è standardizzato.

In un mondo perfetto, gli sviluppatori devono avere unit test (xUnit), tester - test di integrazione automatizzati (Selenium) e utenti aziendali - test di accettazione (FIT). Possono avere accesso agli altri test.

Dipende molto dal progetto. In alcuni casi, un team unificato di Test, QA e UAT che si incontra per discutere dei risultati può essere di grande beneficio. Risparmia la duplicazione delle attività di test e garantisce a tutte le parti una comprensione più chiara delle esigenze aziendali tramite script UAT. D'altra parte, a seconda della complessità del progetto, potrebbe essere più sensato disporre di un QA completo degli input e degli output prima di testare esempi di business. Per lo sviluppo di sistemi domestici, il QA iniziale sarebbe un must prima dell'accettazione da parte dell'utente. Per implementazioni pronte all'uso, un team di test unificato avrebbe più senso.