In che modo la consegna continua può funzionare nella pratica?

Question

La consegna continua suona bene, ma i miei anni di esperienza di sviluppo del software suggeriscono che in pratica non può funzionare.

(Modifica: per chiarire, ho sempre molti test in esecuzione automaticamente. La mia domanda è su come ottenere la sicurezza di consegnare su ogni controllo, che capisco è la forma completa di CD. L'alternativa non è cicli di un anno . Sono iterazioni ogni settimana (che alcuni potrebbero considerare ancora CD se eseguiti correttamente), due settimane o mese; incluso un QA vecchio stile alla fine di ciascuno, integrando i test automatizzati.)

• La copertura del test completa è impossibile. Devi dedicare molto tempo - e il tempo è denaro - per ogni piccola cosa. Questo è prezioso, ma il tempo potrebbe essere dedicato a contribuire alla qualità in altri modi.
• Alcune cose sono difficili da testare automaticamente. Es. GUI. Anche selenio non ti dirà se la tua GUI è traballante. L'accesso al database è difficile da testare senza apparecchi ingombranti e anche ciò non coprirà strani casi d'angolo nella tua memoria dei dati. Allo stesso modo la sicurezza e molte altre cose. Solo il codice a livello di business è effettivamente istruibile.
• Anche nel livello aziendale, la maggior parte dei codifica non ci sono semplici funzioni i cui argomenti e valori di restituzione possono essere facilmente isolati a fini di test. Puoi passare molto tempo a costruire oggetti finti, che potrebbero non corrispondere alle reali implementazioni.
• Test di integrazione/Test funzionali Supplement Test dell'unità, ma questi richiedono molto tempo per essere eseguiti perché di solito comportano la reinizializzazione dell'intero sistema per ogni test. (Se non reinitializza, l'ambiente di test è incoerente.)
• Refactoring o qualsiasi altra modifica interrompe molti test. Passi molto tempo a ripararli. Se si tratta di convalidare le specifiche significative, va bene, ma spesso mette alla prova la rottura a causa di dettagli di implementazione di basso livello insignificanti, non cose che forniscono davvero informazioni importanti. Spesso la modifica si concentra sulla rielaborazione degli interni del test, non sul controllo davvero della funzionalità che viene testata.
• I rapporti sul campo sui bug non possono essere facilmente abbinati alla precisa micro-versione del codice.