Inserito da Campi
La maggior parte delle squadre sono di alto livello test in quello che chiamano test funzionali, test di integrazione end-to-end test, test del fumo, test utente, o qualcosa di simile. Questi test sono progettati per esercitare il maggior numero di applicazioni possibile.
Io sono un fan di alto livello, test, tuttavia, già nel 2009 ho deciso su quello che ho considerato come un dolce-spot per l'alto livello di test: una dozzina o meno. La cosa di alto livello test è che sono complicati e molto fragile. Non è raro che un cambiamento estranei a rompere una suite completa di test di alto livello. In verità, tutto ciò che riguarda alto livello test viene sempre con un implicito " draghi essere qui ".
Sono stato responsabile di una quota equa di authoring di alto livello test. Nonostante i miei sforzi, non ho mai trovato il modo di scrivere di alto livello test che non sono pieni di ritocchi sottile e complicato. Tale livello di complicazione è uguale solo crepacuore per i compagni di squadra che hanno meno familiarità con il test di alto livello. Le problematiche spesso nascono dalla concorrenza, spegnendo le risorse esterne, proprietà di configurazione, l'esposizione dello stato interno e la manipolazione, componenti 3rd party, e tutto ciò che è necessario per testare l'applicazione in produzione-come le circostanze.
A peggiorare le cose, questi test sono l'ultima linea di difesa. La maggior parte dei problemi che questi test avrebbe raggiunto è catturato da una prova di livello inferiore che è meglio progettato per pin-punto in cui il problema ha origine.L'ultima goccia - la stragrande maggioranza delle volte che i test sono rotto è dovuto alla infrastruttura di test (non un difetto vero nell'applicazione) e ci vuole una notevole quantità di tempo per capire come risolvere il infrastrutture.
io ' hai buttato via la mia giusta quota di alto livello test. Intera suite. Impossibile da mantenere e costantemente test rotto a causa di falsi negativi semplicemente non portano il loro peso. D'altra parte ho trovato un sacco di successo con i test di alto livello che ho scritto. Per un po 'ho pensato che il mio successo con i test di alto livello provenienti da una combinazione di mia dedizione a loro rendendo più semplice possibile con cui lavorare e che non ho mai concesso più di una dozzina di loro.
entrai una nuova squadra a febbraio. La mia nuova squadra ha un sacco di alto livello test - circa 50 di loro. Mi considerano in questione. Non molto tempo dopo ho iniziato ad aggiungere nuove funzionalità ho bisogno di scavare nel di alto livello delle infrastrutture di test. E 'molto complicato. Mi considerano scettico. Nel corso dei prossimi mesi ho continuato a rivalutare o meno ho pensato che fossero vale la quantità di sforzo stavo mettendo in loro. Ho interrogato alcuni compagni uno per ottenere il loro livello di felicità. Dopo 5 mesi di lavoro con loro ho cominciato il mio attacco.
Ogni volta che i miei test funzionali rotto ho speso non più di 5 minuti da solo in cerca di un problema evidente. Se non riuscivo a trovare il problema che ho interrotto Mike, il ragazzo che ha scritto la maggior parte delle prove e delle infrastrutture. Più spesso Mike fu in grado di modificare i test in modo rapido ed entrambi abbiamo passati. Ho anticipato che Mike sarebbe stato in grado di risolvere tutte le problematiche di alto livello sulle prove in tempi relativamente brevi, tuttavia, mi aspettavo che avrebbe stanchi dello sforzo e ci sarebbe cercare una più piccola e più gestibile di alto livello suite di test.
Poche settimane più passate con Mike felicemente mettendo in campo tutti i miei problemi di alto livello di test. Questo risultato ha iniziato a sentire familiari, avevo interpretato il ruolo stesso identico su progetti precedenti. Ho capito il motivo che mi aveva avuto successo con i test di alto livello che avevo scritto era probabilmente dovuto esclusivamente al fatto che avevo scritto. La complessità di alto livello delle infrastrutture di test assicura quasi che un individuo sarà l'esperto e di apportare modifiche al che le infrastrutture sono così semplici come spostare alcune variabili nel loro mondo. Sul mio nuovo team, Mike era quello esperto. Ho cominciato a chiamare Mike ad alto livello Whisperer test.
Nei punti precedenti nella mia carriera avrei potuto essere rivoltato da l'idea di avere una zona del codice che ha richiesto un esperto. Tuttavia, dopo aver svolto questo ruolo più volte sono abbastanza comodi, con i rischi associati. Invece di combattere lo stato attuale delle cose, ho deciso di abbracciare la situazione. Non solo mi afferra Mike quando si verificano problemi con il test di alto livello, gli ho anche chiesto di scrivere a me non superano le prove, quando i nuovi sono appropriate per le caratteristiche su cui sto lavorando. Gli ci vogliono pochi minuti per montare alcuni scenari e verifica degli stessi in (commentato). Poi ho non superano le prove che posso lavorare con, implementando alcune nuove funzionalità. Noi ottenere i benefici di alto livello test senza il dolore.
Ovviamente questo set-up funziona solo se entrambe le parti sono d'accordo con la divisione delle responsabilità. Per fortuna, Mike e io siamo entrambi felici con i nostri ruoli dato l'attuale elevato livello di suite di test. Inoltre, abbiamo aggiunto altri 2 processi (un aumento del 50%) da quando sono entrato. . Per entrambi questi processi ho creato l'alto livello test e le relative infrastrutture - e mi occupo anche di qualsiasi attività di manutenzione associate
Si tratta di un caso specifico di un disegno più generale che ho osservato di recente: se il costo di mantenendo 2 persone istruite su un pezzo di tecnologia è superiore alla prestazione, non fatelo - rischio bus sarà condannato.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.