È un team di QA separato, ridondante nel ciclo di vita dello sviluppo?

Direi che dipende dal sistema sviluppato e testato.

Lo sviluppatore potrebbe avere la migliore comprensione del codice , ma ciò non significa che comprenda appieno tutti i casi aziendali per cui il codice è usato.

Ad esempio, prendi in considerazione un'applicazione web utilizzata dai broker assicurativi per gestire ed elaborare politiche e reclami. Ci sono molte molte regole e casi aziendali che entrano in tale sistema. È altamente improbabile che uno qualsiasi sviluppatore possa conoscerne tutti in modo approfondito. Diamine, la maggior parte degli utenti business probabilmente non conoscerà l'intero sistema (anche se avranno una migliore comprensione a livello aziendale di più di esso rispetto agli sviluppatori).

In questo caso, un team di controllo qualità separato avrà ricevuto una formazione specifica sui flussi aziendali all'interno dell'applicazione. Le probabilità sono, potrebbero non essere nemmeno sviluppatori, potrebbero essere analisti aziendali che sono passati al QA a causa della loro vasta esperienza. Oppure potrebbero essere sviluppatori che sono più interessati alle facce del sistema non correlate al codice. Non capiranno tutti i dettagli tecnici e non ne avranno bisogno. Eseguiranno casi aziendali che probabilmente vanno al di là di ciò che gli sviluppatori sanno o hanno bisogno di sapere. I test degli sviluppatori (solitamente eseguiti dagli sviluppatori localmente sulla propria workstation, per garantire che il loro codice funzioni a più di un semplice livello di base) e il test del QA (svolto dai team di controllo qualità per garantire serie più ampie di casi aziendali) sono due fasi distinte con diversi tipi di test e aspettative.

Quale valore aggiunge? Hai collaudati esperti del controllo qualità che hanno un'ottima conoscenza di alto livello del sistema nel suo insieme. Conoscono come per testare il sistema per garantire che tutte le parti siano adeguatamente coperte, in base alle modifiche apportate dallo sviluppatore. E libera il tempo dello sviluppatore da qualcosa che è davvero un lavoro a tempo pieno e richiede una formazione aziendale approfondita. Tutto ciò può portare a un numero inferiore di bug che lo rendono alla produzione e una qualità superiore a tutti i clienti più soddisfatti (e questo è l'intero punto, non è vero?)

Nella mia esperienza, più grande / complesso è il progetto, maggiore è il valore aggiunto dall'avere un team di controllo qualità completo. Sui sistemi più piccoli con un singolo (o una manciata di) sviluppatori e casi d'uso più semplici, il valore aggiunto non è così grande, e in alcuni casi, avere un team QA separato potrebbe essere ridondante (e costoso) se il test è abbastanza semplice da consentire agli sviluppatori di gestirli da soli.

FrustratedWithFormsDesigner richiama un caso dove è utile un QA separato - un sistema complesso.

C'è un altro caso in cui il QA separato può non solo essere utile, ma obbligatorio - ambienti regolamentati. Esiste una nozione di verifica e convalida indipendenti. Indipendente significa che è fatto da una persona o da un gruppo di persone che non ha scritto il codice di produzione. In alcuni ambienti (ho esperienza nel settore aerospaziale e dell'assistenza sanitaria) ea determinate condizioni, è stato stabilito che esiste un livello di verifica e / o convalida indipendente. In tutte le mie esperienze, il team di sviluppo è responsabile di un certo livello di test per garantire che la spazzatura non venga consegnata ai tester indipendenti del controllo qualità. Inoltre, i test indipendenti possono essere test manuali, test automatizzati o una combinazione di entrambi.

C'è anche la domanda su cosa significhi "un QA separato". Significa incorporare lo staff di QA in ogni team di sviluppo o significa avere un passaggio da un team di sviluppo a un team di QA. L'indipendenza può essere raggiunta in entrambi i modelli.

Mi piacciono decisamente i punti discussi da @FrustratedWithFormsDesigner, ma penso che sia utile considerare l'universo più ampio di tipi di test quando si tratta di un sistema software completo. Sono sicuro che ci saranno divergenze di opinioni su chi dovrebbe fare cosa - e accolgo con favore la discussione :-) - ma la figura sottostante è uno schizzo rapido che rappresenta l'esperienza e le opinioni di my .

Come osserverai, ci sono molte coincidenze su chi dovrebbe testare cosa. Gli sviluppatori dovrebbero essere responsabili di fornire al QA un prodotto (o una funzionalità) completo e corretto, non solo mediante test unitari, ma una certa misura delle altre categorie di test annotate. Quelli che ho contrassegnato come "secondari" dovrebbero essere considerati dagli sviluppatori, ma non come loro principale responsabilità. Ecco perché hai bisogno di persone dedicate al controllo qualità, persone con esperienza in quelle aree.

Gli stakeholder aziendali aggiungono un altro livello di convalida e, sebbene la loro partecipazione ai test varierà ampiamente da azienda a società, sono, dopo tutto, coloro che forniscono un prodotto accettabile o inaccettabile al cliente.

Una coppia chiave da asporto dal mio grafico:

• Il test delle unità è l'unico dominio degli sviluppatori. QA persone con esperienza nella codifica potrebbero voler dare un'occhiata ad alcuni degli interni, ma per aiutarli nello sviluppo di test funzionali e di altro tipo, non per i test unitari.

• Il controllo qualità è responsabile dell'intera sinergia di sistema, già discussa da @FrustratedWithFormsDesigner.

• La sicurezza è un'attività di tutti!

Ovviamente ti sei accuratamente testato prima di passare al QA. Ma il fatto stesso che lo sviluppatore sia il più familiare con l'applicazione è il miglior motivo per cui qualcuno lo prova.

Lo sviluppatore sa che cosa il software è supposto da fare, il modo in cui è supposto da utilizzare, ecc., e sarà eccezionale se lui o lei tenta di usarlo nel modo in cui un utente ingenuo potrebbe, rompendolo in modi imprevisti. Non sarà mai una scatola nera per quella con la visione a raggi X. Troppo spesso lo sviluppatore è il più rimosso dall'uso del mondo reale di tutte le persone coinvolte nel progetto.