Gli sviluppatori dovrebbero essere coinvolti nelle fasi di test?

Guarda la tua domanda letteralmente ("coinvolto in") La mia unica risposta è un assoluto inequivocabile

YES

Gli sviluppatori non dovrebbero mai avere l'ultima parola sul proprio codice proprio .

Ma Devs dovrebbe essere coinvolto nel testare il lavoro di altri sviluppatori. Fa due cose:

1. Porta l'intuizione di uno sviluppatore ai test. Questo è sia dal caso generale di sapere quali API sono probabilmente utilizzate in un determinato punto, quali sono le eccezioni che possono derivare da tali API e come dovrebbero essere gestite. Aiuta anche su un progetto specifico perché gli sviluppatori ottengono molta più esposizione alle varie discussioni sul perché viene fatto qualcosa rispetto al QA in genere, il che significa che potrebbero individuare casi limite che il controllo di qualità non farebbe. Anche i bug individuati da un dev sono probabilmente meno costosi da sistemare perché uno sviluppatore di solito fornisce più informazioni e molte più informazioni su come risolverlo immediatamente.
2. Fornisce l'esposizione dev a parti dell'applicazione che altrimenti non potrebbero ottenere esposizione. Ciò renderà loro migliori sviluppatori per quella app a lungo termine. Quando so come viene consumata la mia API, sono molto più bravo ad anticipare la prossima cosa che dovrei fare se non stavo guidando da una specifica. Soprattutto, posso dire quando la specifica è sbagliata prima di iniziare la codifica se conosco l'applicazione e il suo utilizzo.

Infine, perché non dovresti usare più occhi possibili? Raramente si può permettersi di passare attraverso il processo di assunzione e di imbarco per portare a bordo altre persone del controllo qualità per crunch. Allora, dove trovi gli occhi extra di cui hai bisogno? O provi a passare il tempo crunch con lo stesso numero di QA che hai sempre avuto? Anche se gli sviluppatori spendono  Il 20% del tempo di test e l'80% di risoluzione di bug, è ancora più l'attenzione sull'app rispetto a prima. Il test automatizzato ti dà solo un certo livello di sicurezza e non sarà mai al 100%.

link

Per qualsiasi cosa tranne Test unitario, assolutamente no. Gli sviluppatori sanno solo troppo sull'app e su come "suppone" lavorare per diventare tester oggettivi.

La differenza fondamentale nel testare le filosofie tra sviluppatori e Q è questa: il programmatore di solito testa il suo programma per dimostrare che il suo codice funziona (test "positivo"). Il QA può farlo e lo fa, ma ha anche un ulteriore focus su scoprire cosa non funziona cercando di rompere il software (usando test "negativi").

Nella misura in cui il personale addetto al controllo qualità potrebbe essere potenzialmente corrotto dai test dei programmatori che "dimostrano" che il software funziona, dovrebbe esserci isolamento tra il test dello sviluppatore e il test del QA. Lo sviluppatore può certamente aiutare i test di QA dimostrando cosa funziona, ma spetta a QA indipendentemente verificare che il software non break.

La cosa migliore che il programmatore può fare per aiutare lo sforzo di test è fornire una suite di test unitaria completa, di alta qualità e verificabile, contenente test che si allineano ai requisiti individuali nel documento dei requisiti.

Bene in termini di test, ci sono 3 tipi.

Scatola nera, scatola grigia e scatola bianca.

La scatola nera si riferisce agli utenti che testano il prodotto, senza alcuna conoscenza di come il prodotto funzioni internamente.

La casella grigia si riferisce agli utenti esperti che hanno conoscenze sulla programmazione del computer, ma che non fanno parte del team di sviluppo. Queste persone testeranno se il prodotto presenta perdite di memoria, problemi con i requisiti di sistema e così via.

Ecco la parte principale: la casella bianca si riferisce agli sviluppatori che eseguono test sul prodotto a livello di codice. Ciò significa che eseguono test unitari, debugging, ecc.

Pertanto, è positivo che gli utenti e il team di sviluppo siano tutti coinvolti nella fase di test, ma ciascuno dei test richiede un livello di impegno adeguato da parte degli utenti e del team di sviluppo, a seconda di ciò che viene testato.

UNIT TESTING è un must per tutti gli sviluppatori

Per informazioni su come questo potrebbe essere usato a tuo vantaggio, leggi i seguenti link se sei interessato allo sviluppo di C ++:

• Una rapida introduzione al framework di test di Google C ++
• Strumenti di test delle unità C / C ++ open source, Parte 1: Scopri il framework di test dell'unità Boost
• Strumenti di test delle unità C / C ++ open source, Parte 3: Scopri come CppTest

NON C'È POSSIBILE CHE UNA PERSONA DEL QA PU CAN FARE QUESTI TEST. NO WAY.

Supponendo che il progetto abbia un numero significativo di sviluppatori, quindi con tutti i mezzi gli sviluppatori che lavorano al testing. Un avvertimento è che gli sviluppatori non lavorano sui test (questo non include il test delle unità) per il loro codice.

Preferirei che lo staff amministrativo (oi potenziali utenti effettivi) esegua il test del controllo qualità piuttosto che gli sviluppatori. Qualcuno che non sa come il prodotto è stato progettato per funzionare, deve cercare di usarlo. Gli sviluppatori tendono ad essere molto limitati nel modo in cui si avvicinano ai test e, francamente, sono troppo costosi all'ora da utilizzare anche per i test di controllo qualità.

Scrivi:

The issue is that, due to resources issues (*), test phases are too long and are often shortened due to time constraints That's because developers are not doing them. One of the biggest Internet companies delivering the best most stable products do not use testers at all. They only use automatic testing, all done by the developers themselves. Results are x10 better products than when the developer leaves testing to "testers".

È come avere degli operai edili per costruire la tua casa, ma avere una squadra diversa per accertarsi che l'edificio sia effettivamente in piedi, le porte aperte e chiuse, l'aria condizionata funzioni ecc ... Probabilmente occorrerà x10 per costruire edifici, e la maggior parte finirà per essere inaffidabile.