Quando lo sviluppo dovrebbe cessare e il controllo qualità deve iniziare?

Non dovrebbe!

È molto difficile fare tutto il lavoro, fermarsi e quindi correggere tutti i problemi. Quando vai a risolvere un problema che riscontri durante il processo di QA, potresti imparare che sarebbe meglio fare qualcosa di diverso.

Invece di pensare a tutto come processo a blocco, cerca di renderlo più ciclico. Codifica alcune funzionalità e testala. Codice ancora un po 'e testarlo (e le cose vecchie funzionano ancora). Questo processo più fluido allevia la difficoltà di provare a caricare tutto in anticipo. Puoi ancora avere il concetto di blocco del codice (basta correggere i bug) quando ti avvicini alla scadenza, ma il punto è testare presto e spesso.

Bene, se intere sezioni di codice vengono consegnate al QA in uno stato non funzionante, forse dovresti esaminare l'aggiunta di qualche tipo di test di unità / integrazione al tuo processo. Non abusare delle persone del tuo QA facendole scoprire che non hai eseguito il test di integrazione o test di integrazione del tuo codice.

È una linea sottile, perché se il codice viene consegnato in base alle specifiche, allora per me significa che non ci sono bug (e non c'è bisogno di QA!). Il fatto che il codice non venga regolarmente fornito alle specifiche è il motivo per cui facciamo il QA in primo luogo.

Ma in realtà non penso che sia di questo che stai parlando. Quello che intendi è che il team di sviluppo sembra un po 'troppo pigro con la loro programmazione, e ci sono grandi cose ovvie che non sembrano funzionare. Disporre in anticipo che i test unitari devono essere presenti per ciascuna delle caratteristiche A, B e C (nelle specifiche) e quindi avere il codice e i test esaminati in modo indipendente (da un team lean o manager) dovrebbe aiutare ad alleviare questo tipo di problema .

Direi che, per lo meno, gli sviluppatori avrebbero dovuto testare il "percorso felice". Che se inseriscono i dati previsti, fa quello che le specifiche dicono che dovrebbe fare. Gli sviluppatori che non fanno così tanto dovrebbero essere interrogati.

Sono anche deluso dal fatto che uno sviluppatore non abbia testato gli ovvii casi limite: una stringa troppo lunga per il database, ovviamente testo non valido, se inserisci lettere dove dovrebbe essere un numero, ecc. Se ciò accade spesso, ripeti le domande dovrebbe essere chiesto.

Tuttavia, supponendo che non sia specificamente menzionato nelle specifiche, se uno sviluppatore limita un nome solo a lettere maiuscole e minuscole, ma dimentica che alcuni nomi hanno apostrofi, o consente una data del 29 febbraio 2011 - questo è leggermente più comprensibile. A meno che non stiano facendo lo stesso errore di volta in volta.

Il team addetto al controllo qualità dovrebbe cogliere i casi estremi. Preferisco che il QA diventi uno strumento per testare le scimmie: basta inserire spazzatura casuale, vedendo se possono rompere l'app in questo modo.

Nello sviluppo web, QA dovrebbe provare diversi browser e cercare di trovare plug-in che potrebbero influenzare il codice. Devono disattivare Javascript e CSS e vedere cosa possono farcela poi. Quel genere di cose. Se ti aspetti che gli sviluppatori lo facciano, stai spendendo troppi soldi su di esso.

Se viene fornita una funzionalità che non funziona, il problema non è tra lo sviluppo e il controllo qualità, ma tra lo sviluppo e i proprietari del prodotto.

I proprietari e gli sviluppatori dei prodotti dovrebbero far parte dello stesso team e dovrebbero collaborare per definire ciò che deve funzionare per considerare una funzionalità "completata" e per assicurarsi che il codice soddisfi tale esigenza.

Quando il codice viene consegnato, il test dovrebbe essere una pura formalità, perché i proprietari del prodotto avrebbero dovuto collaborare con gli sviluppatori lungo il percorso per assicurarsi che tutti i casi d'uso fossero coperti.

(Se hai dei tester professionisti, dovrebbero far parte del team e dovrebbero essere coinvolti in ogni fase.)

Abbiamo un processo di screening per i progetti in cui chiediamo agli sviluppatori di fornire una demo / demo del loro codice prima che entri in QA. Includiamo non solo i collaudatori del controllo qualità, ma anche il (i) titolare (i) commerciale (i) del codice, il servizio clienti e il marketing / design. Questo tende a concentrarsi sugli sviluppatori almeno nei casi di facile utilizzo, e a volte la discussione che ne risulta tra i vari team si traduce in modifiche alle specifiche e un ritardo nell'entrata in QA. Quando possiamo, coinvolgiamo il QA molto prima del processo, il che aiuta a correggere i bug mentre il codice è ancora caldo, ma facciamo ancora la procedura prima che il QA "ufficiale" inizi.

A volte ho detto che il codice non dovrebbe essere sottoposto al controllo di qualità se si fosse turbati se per errore fosse andato alla produzione invece che al QA. Il codice con grave disfunzionalità non appartiene al QA (tranne in circostanze specifiche)