Quando dovrebbe cessare lo sviluppo e iniziare il QA?

Scriviamo una specifica funzionale completa per il nostro team di sviluppo di due. Non disponiamo di tester professionisti, tuttavia abbiamo collaborato con l'aiuto del nostro personale di helpdesk disponibile per eseguire i "test di qualità".

In passato abbiamo avuto problemi in cui pezzi di funzionalità completi non funzionano o il codice viene consegnato semplicemente non conforme alle specifiche.

Le mie domande sono: a che punto gli sviluppatori dovrebbero smettere di programmare il codice del team di controllo qualità? È troppo chiedere agli sviluppatori di rivedere il loro codice rispetto alle specifiche prima di passare al team QA?

Non dovrebbe!

È molto difficile eseguire tutto il lavoro, interrompere e quindi risolvere 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 a un processo di blocco, prova a renderlo più ciclico. Codificare alcune funzionalità e testarlo. Codifica ancora un po 'e testalo (e le cose vecchie funzionano ancora). Questo processo più fluido allevia la dura nave che prova a caricare tutto in anticipo. Puoi ancora avere il concetto di un blocco del codice (correggi solo 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 cercare di aggiungere una sorta di test di unità / integrazione al tuo processo. Non abusare dei tuoi addetti al QA facendoli scoprire che non hai superato l'unità o il test di integrazione del tuo codice.

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

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

Direi che almeno 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 messi in discussione.

Sono anche deluso se uno sviluppatore non ha testato gli ovvi 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, dovrebbero essere poste di nuovo domande .

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 - è leggermente più comprensibile . A meno che non facciano lo stesso errore di volta in volta.

Il team QA dovrebbe raccogliere i casi limite estremi. Preferisco che il QA sia un tester di scimmie: sto solo entrando nella spazzatura casuale, vedendo se possono rompere l'app in quel modo.

Nello sviluppo web, il QA dovrebbe provare diversi browser e cercare plug-in che potrebbero influenzare il codice. Dovrebbero spegnere Javascript e CSS e vedere cosa possono cavarsela. Quel genere di cose. Se ti aspetti che gli sviluppatori lo facciano, ci stai spendendo troppi soldi.

Se viene fornita funzionalità che non funziona, il problema non è tra sviluppo e QA, ma tra sviluppo e proprietari del prodotto.

I proprietari dei prodotti e gli sviluppatori dovrebbero far parte dello stesso team e dovrebbero lavorare insieme per definire ciò che deve funzionare per considerare una funzione "eseguita" e per assicurarsi che il codice soddisfi tale esigenza.

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

(Se disponi di 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 procedura dettagliata / demo del loro codice prima che arrivi al QA. Includiamo non solo i tester di QA, ma i proprietari di attività del codice, servizio clienti e marketing / design. Ciò tende a concentrarsi sugli sviluppatori almeno sui casi di facile utilizzo e, a volte, la discussione risultante tra i vari team comporta modifiche alle specifiche e un ritardo nell'ingresso nel QA. Quando possiamo, coinvolgiamo il QA molto prima nel processo, il che aiuta a correggere i bug mentre il codice è ancora caldo, ma facciamo ancora la procedura prima che inizi il QA "ufficiale".

Qualche volta ho detto che il codice non dovrebbe essere inviato al QA se saresti arrabbiato se per errore andasse in produzione invece del QA. Il codice con disfunzionalità maggiore non appartiene al QA (tranne in circostanze specifiche)