Il QA dovrebbe far parte del reparto sviluppo?

Sì e no :)

Sia gli sviluppatori che gli addetti al controllo qualità dovrebbero avere lo stesso obiettivo (e le loro prestazioni misurate rispetto a questo): consegnare un prodotto di qualità nel tempo e nel budget. Devi definire "prodotto di qualità", ma deve essere lo stesso per entrambi i gruppi. Perché? Perché se non è lo stesso, otterrete due gruppi con programmi diversi e che possono deteriorarsi rapidamente in una situazione che è a discapito del prodotto / azienda.

Il QA dovrebbe funzionare (molto) strettamente insieme agli sviluppatori e viceversa, ma entrambi dovrebbero essere totalmente indipendenti dall'altro nel loro processo decisionale. Dopotutto, sono responsabili di aspetti completamente diversi dello sviluppo del prodotto

Il modo in cui lo abbiamo impostato è che "Product Development" è un dipartimento "virtuale" realizzato da due dipartimenti concreti: QA e Sviluppo. Entrambi riportano allo stesso membro del team di gestione: il CTO. Questo assicura che ci sia una sola persona responsabile del prodotto (il nostro CTO) e che sia il QA sia lo sviluppo siano indipendenti l'uno dall'altro.

Dipende davvero da quanto seriamente la tua azienda riguarda il controllo qualità. Ad esempio, farai uno sviluppo basato su test?

Hai menzionato un "gruppo di prova", questo suggerirebbe più persone. Se è in realtà un gruppo di più persone, probabilmente dovrebbe essere un dipartimento separato. Ciò che mi lascia perplesso è che al momento hai almeno una persona dedicata al controllo qualità? In caso contrario, hai in programma di alzare rapidamente un intero nuovo gruppo? In tal caso, si tratterà di una sostanziale trasformazione organizzativa e potrebbe causare forti attriti con i tuoi attuali sviluppatori che hanno bisogno di cambiare il loro modo di lavorare.

Se quello che state pianificando sta assumendo una singola persona di controllo qualità ora e forse sta lentamente aumentando la funzione di controllo qualità, probabilmente sarebbe meglio che quella persona riferisse direttamente al direttore dello sviluppo del prodotto. La parte più difficile del suo lavoro, e più importante, sarà trasformare la tua cultura organizzativa per integrare il QA in tutte le fasi del processo piuttosto che qualcosa che viene fatto dopo il fatto.

What we haven't had, however, is a QA...

Ci sono stato fatto - le mie sincere condoglianze. Bene detto sopra direi che ottenere tester sarà molto meglio di quello che hai ora, non importa in quale dipartimento atterreranno.

Oltre a questo, mi sento sicuro di raccomandare un dipartimento separato per il controllo qualità.

Ho partecipato a due rilasci dal punto di vista del controllo qualità: una volta come tester, un altro come sviluppatore. In entrambi i casi, ritengo che avere un dipartimento QA separato sia stato molto utile.

Per quanto posso dire quando i tester si trovano in un reparto separato, diventa più difficile nascondere i problemi di qualità del prodotto dietro un falso "allineamento del team" . Questo ha aiutato tutti a capire chiaramente cosa stiamo rilasciando e perché. Ciò a sua volta ha aiutato a gestire le aspettative dei clienti e a pianificare un ulteriore sviluppo.

In quasi tutti i casi, il controllo qualità deve essere separato dallo sviluppo. Mentre l'obiettivo tra i due dipartimenti è lo stesso (rilasciando prodotti / soluzioni di qualità), il QA deve ritenere di avere l'autorizzazione per correggere e dare suggerimenti sui prodotti con sviluppo e su un piano di parità. Se il capo della QA riporta direttamente al responsabile dello sviluppo, ciò può portare a fare del QA un passo indietro ed essere in balia dello sviluppo (e di conseguenza il codice / i prodotti sloppier vengono spinti alla produzione).

Dipende dalla metodologia di sviluppo che stai utilizzando: se stai facendo agile / lean allora Agile Test potrebbe essere la strada da percorrere e come tale dovrebbe essere vicino agli sviluppatori.

Da quello che stai dicendo, hai una piccola azienda. Ha senso per me trarre vantaggio da quella dimensione e capacità di comunicare finché puoi, prima che tu diventi più grande. Ciò implica tenerli con lo sviluppo.

In una società più grande, quando disponi di team di Dev e QA di dimensioni decenti, potrebbe avere senso dividerli e far sì che mantengano i loro obiettivi di squadra separati, ecc.

Ora, sarei sicuro di avere le prime posizioni di QA come posizioni SDET ... cioè. tester con braciole di codifica. Rendi la tua automazione sempre operativa, stabile e stabile sin dall'inizio.