Gli sviluppatori, i tester e gli utenti aziendali dovrebbero avere uno script di test unificato?

In primo luogo, il QA non è un test. Se il tuo reparto di QA non è coinvolto nell'intero processo di sviluppo, sono Test, non QA. QA quando si fa il lavoro, fornisce la garanzia della qualità, nel migliore dei casi il Test mostra la mancanza di qualità, ma non può dimostrare la qualità - cioè il Test mostra che il QA ha fallito, ma non può mostrare che sono riusciti, quindi Test e QA non dovrebbero essere lo stesso dipartimento.

Credo che il modo migliore sia che ogni gruppo gestisca i propri test, in quanto fornisce una copertura migliore. Tuttavia, ogni team dovrebbe iniziare a testare il prima possibile. Ciò significa che l'UAT si avvia non appena c'è qualcosa che gli utenti potrebbero essere in grado di utilizzare, il test inizia non appena una parte per cui è disponibile un test è pronta ecc. Ciò impedisce la ricerca tardiva di casi di test distinti. Ciò potrebbe significare alcuni di rigetto dei tuoi modelli di lavoro, poiché spesso UAT e Test si aspettano di lavorare su un prodotto completo e hanno bisogno di una formazione per testare risultati parzialmente completi. Può essere più costoso a meno che il flusso di lavoro non sia disciplinato e gli sviluppatori "Completa" significhi Completato.

Il controllo qualità dovrebbe supervisionare questo, insieme ad altre misure di qualità, per garantire che il processo non solo fornisca l'output di qualità desiderato, ma anche a un livello di efficienza appropriato.

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

Utilizziamo gli UAT fin dall'inizio.

Funziona come riferimento universale e penso che funzioni bene. Mentre potrebbero esserci script di test che vengono utilizzati solo dai Devs o dai Testers per componenti più piccoli, la direzione del test è sempre rivolta verso un target unificato. Alla fine della giornata, l'UAT è l'unico che conta, quindi potresti anche metterlo a fuoco all'inizio.

Anche fare UAT sin dall'inizio ha un ulteriore vantaggio. Rende davvero ogni ambiguità tra le aspettative del cliente e le tue.

Non hanno bisogno di uno script di test unificato come le cose che testano e il modo in cui eseguono i test spesso si suppone siano diversi, ciò di cui hanno bisogno è un requisito unificato a cui tutte le parti stanno lavorando. Se UAT e QA stanno testando cose a cui lo sviluppatore non ha mai pensato, allora è il momento di esaminare i requisiti.

Sono d'accordo, che avere uno script di test unificato per sviluppatori, tester e utenti aziendali sarebbe bello avere ma credo non è possibile senza un grande sforzo dove il costo supera il vantaggio.

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

In perfect world devono disporre di test unitari (xUnit), tester - test di integrazione automatizzati (Selenium) e utenti aziendali - test di accettazione (FIT). Possono avere accesso agli altri test.

Dipende davvero dal progetto. In alcuni casi un gruppo unificato di test, controllo qualità e UAT che si incontra per discutere i risultati può essere estremamente utile. Salva la duplicazione degli sforzi di test e garantisce che tutte le parti abbiano una comprensione più chiara delle esigenze aziendali tramite gli script UAT. D'altra parte, a seconda della complessità del progetto, potrebbe essere più sensato avere QA accuratamente gli input e gli output prima di testare esempi di business. Per lo sviluppo di sistemi interni, il QA iniziale sarebbe indispensabile prima dell'accettazione da parte dell'utente. Per implementazioni out-of-the-box, un team di test unificato sarebbe più sensato.