Uno sviluppatore dovrebbe creare casi di test e quindi eseguire test case? [duplicare]

Non vedo un grosso problema di per sé nel processo che descrivi. È vero che i tester dedicati hanno tradizionalmente più esperienza nella progettazione di tali casi di test, ma poi, di nuovo, se i tuoi sviluppatori lo fanno regolarmente questo non avrà importanza.

Tuttavia, c'è qualcosa da dire sull'essere ciechi rispetto ai propri difetti. Testare le tue cose significa che hai già una mentalità consolidata su qualunque cosa tu stia testando, semplicemente perché l'hai sviluppata. Un tester separato aggiungerà una nuova prospettiva ed è molto più probabile che trovi problemi per esempio. nell'area di usabilità.

L'unico inconveniente principale che non è stato menzionato prima è che potresti non essere autorizzato a farlo in alcuni progetti, a seconda degli standard a cui devi aderire. Diversi standard di sviluppo SW vietano esplicitamente di testare le proprie cose (non nel senso TDD, ma in termini di test di validazione / accettazione). In questi casi, testare il tuo lavoro molto probabilmente è una violazione del contratto del progetto.

Quello che stai descrivendo è un piano di test o un caso di test. Idealmente avresti uno specialista indipendente di QA che creerebbe e possibilmente eseguirà questi casi di test.

Tuttavia, date le piccole dimensioni della vostra azienda / squadra, avere lo sviluppatore di creare un piano di test dai requisiti prima di creare il codice è la cosa migliore.

Creando il caso di test a questo punto del processo, hai meno conoscenza della soluzione e scriverebbe idealmente un caso di test migliore.

Tuttavia non sono un grande fan di questo metodo. Se la società / organizzazione non desidera essere promossa per un QA dedicato, un possibile miglioramento del processo sarebbe quello di avere una peer write ed eseguire il test case.

Certo. Uno sviluppatore dovrebbe creare casi di test e quindi eseguire i test case.

Before the development community was convinced of the benefits, some people thought that unit tests were a waste of time. Some developers thought that their job was to write production code, so spending time on unit tests, which aren't production code, wasn't what they were being paid for.

These days, most professional developers know that unit tests are an important part of writing production code. It means you deliver better quality code and it makes jobs like refactoring or adding new features easier.

The research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams - via Phil Haack.

If your code isn't covered by unit tests, it is legacy code.

Da link

Modifica

Should a developer be that tester?

Sì, lo sviluppatore può testare la parte Unit Test.

Ma per altri test, ad esempio, test di accettazione, test di regressione, dovresti avere un tester professionale e dedicato.

Lavoro anche in un'azienda in cui la maggior parte delle squadre non ha una funzione di test / controllo qualità dedicata. Preferiamo descriverlo come la qualità è responsabilità di tutti : assicurarti che il codice che scrivi faccia ciò che è destinato a fare non sia mai il problema di qualcun altro. La scrittura e l'esecuzione di piani di test manuali non è richiesta come soluzione, ma è previsto un software di qualità e i team devono trovare un modo per raggiungerlo.

L'effetto previsto di questo stile organizzativo nella mia organizzazione era di far agire tutti in modo responsabile a breve termine e di incoraggiare approcci innovativi alla qualità a lungo termine. Molti team hanno iniziato dedicando una giornata di sprint a test manuali. Dopo un po ', altri team hanno iniziato a eseguire una revisione del codice e una revisione del design più approfonditi, e alcuni team hanno automatizzato tutti o parte dei loro test antecedenti per ridurre il tempo speso per testare e ridurre il rischio di errore.

Hai ragione che dedicare tempo ingegneristico e architetto a test manuali ripetitivi è un approccio piuttosto costoso, ma ha l'effetto di far sentire chi produce il codice l'impatto dei propri errori e, dato il giusto tipo di squadra, può incoraggiare una più profonda comprensione del percorso completo di un passaggio dal cervello alla produzione, piuttosto che un atteggiamento di "lancio di un codice oltre il muro" per il QA e i team operativi da affrontare.

Non c'è "dovrebbe". L'obiettivo è creare software utile e privo di difetti. Dovresti fare tutto il necessario per raggiungere questo obiettivo. Per alcune organizzazioni ciò significa che lo sviluppatore scrive anche i test finali di accettazione. In altre organizzazioni ci sono legioni di tester per fare il test finale.

Certamente, in un mondo perfetto avresti addestrato i professionisti dei test di accettazione, proprio come avresti ingegneri di costruzione, esperti di usabilità, tester di prestazioni, ecc. Le piccole aziende a volte devono unire i ruoli.

Alla fine della giornata, questo è il tuo software. Vuoi che venga rilasciato in natura con bug?

Sono un grande fan dell'indipendenza nella fase di test:

• Un architetto ha interesse a mostrare le sue specifiche è corretto
• Uno sviluppatore ha interesse a trovare tutte le non conformità

Ma

• Uno sviluppatore ha interesse a far sì che il suo codice superi il test
• Un tester ha un interesse acquisito nel trovare tutte le non conformità

Sì, un singolo individuo può fare tutti i ruoli - e questo è comune, specialmente in piccoli team e piccole aziende. Ma non puoi sconfiggere l'indipendenza.

Ma se devi svolgere più ruoli, ti preghiamo di indossare il cappello per il lavoro, non con qualsiasi altro cappello:)

Ci sono ragioni per cui lo sviluppatore non dovrebbe mai testare il proprio codice (pregiudizio a test positivi, influenza della conoscenza della scatola bianca e supposizioni come "questo non può mai accadere perché il componente è così ...", creativo invece del pensiero distruttivo), tuttavia penso che non sia un grosso problema, se non stiamo parlando di software mission-critical. Trovo molto strano anche per le piccole aziende non avere personale di controllo della qualità. Non è proprio una buona idea quando la persona dovrebbe trovare problemi nel proprio lavoro, in generale.