Come rendere popolari i test automatici? [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 2 anni fa .

La nostra base di codice è in crescita da 20 anni. Siamo circa 10 sviluppatori + sqa che lavorano con 500kloc. Qualche tempo fa un piccolo gruppo di noi (2 sviluppatori, uno di sqa) ha iniziato a lavorare su un programma di test automatizzato. Attualmente una corsa dura 11 ore ed è in qualche modo un test di integrazione. Ci stiamo lavorando per rimediare e ridurre i falsi positivi e stiamo facendo buoni progressi. Ma i dettagli non dovrebbero importare.

Funziona bene e continuiamo a migliorarlo. A noi (la piccola squadra) piace molto. Se rompiamo qualcosa, notiamo un giorno dopo e non 2 mesi dopo quando sqa dà un'occhiata. Inoltre, ai nostri manager (dev + sqa) piace l'idea. Ma altre persone nel team ignorano i risultati dei test. Nella loro mente, se i test falliscono dopo un check-in, è un problema del test e non della modifica del codice ed è solo il nostro progetto giocattolo. Abbiamo discusso più volte se un test fallito è un vero errore. Molte volte lo è.

Non possiamo e non vogliamo far valere qualcosa. Come possiamo dimostrare che i test automatici sono una cosa?

testing integration-tests

— Peter Schneider
fonte

Questo non è un problema di ingegneria del software; è un problema di persone.

— Robert Harvey,

@RobertHarvey Ho ottenuto i voti negativi su SO perché "basato sull'opinione" e un commento che questo sito si adatterebbe perfettamente (e voti su quel commento). Quindi: dove dovrei chiedere? Educami

— Peter Schneider,

Sono con @RobertHarvey riguardo al fatto che questo è un problema di persone. Ma per quanto riguarda Workplace, probabilmente la tua domanda sarà considerata un inganno. Ad esempio, vedi questa domanda che è fondamentalmente ciò che stai chiedendo sul posto di lavoro.stackexchange.com/questions/44964/…

— Peter M

Non lasciare che quei downvoter (o anche i voti stretti) ti scoraggino! Alcune persone possono capire che tali domande sono importanti e forse possono fornire aiuto. A proposito, anche i miei colleghi non riescono a vedere l'utilità dei test automatizzati, nonostante la versione precedente (senza alcun test automatizzato) sia una scatola di bug. Basta cambiare una cosa e spezzarne alcune altre, apparentemente non correlate. Alcune persone semplicemente non vogliono imparare (c'è una resistenza aperta contro l'apprendimento di cose nuove).

— Bernhard Hiller,

È un peccato che questa domanda sia stata chiusa. Se l'ingegneria del software significa qualcosa, significa che i problemi di lavorare con persone reali e le risposte a tali problemi comporteranno l'opinione. Detto questo, un paio di idee rapide: (1) se i test danno falsi negativi, questo aumenterà sicuramente il respingimento perché i risultati sembreranno una perdita di tempo; (2) ridurre il tempo di esecuzione, se possibile. 11 ore non sono immediate, anche se sono molto meglio di due mesi; (3) sqa adotterà questi test come parametri che guardano. sono già riconosciuti dalla tua organizzazione in quest'area.

— Dale Hagglund,

Risposte:

disconoscimento

Anche se posso sembrare un manager, ho scritto questo come sviluppatore che doveva anche essere convinto che i test automatizzati fossero buoni.

Devi capire la psicologia di base degli sviluppatori. È una necessità radicata degli sviluppatori di impegnare il codice. Tutto ciò che impedisce loro di farlo è una cosa molto, molto brutta. Il test fallito è sicuramente qualcosa che impedisce loro di farlo, ergo è una cosa negativa. Da qui la resistenza.

Quello che devi sottolineare è che, mentre i test automatici li rallentano a breve termine, a lungo termine li farà risparmiare molto dolore e li accelererà, perché saranno in grado di concentrarsi maggiormente sullo sviluppo di nuove cose e perderà meno tempo facendo l'altra cosa che gli sviluppatori odiano fare: correggere i bug.

E sì, devi applicarlo. È necessario ottenere il supporto incondizionato dalla direzione e rendere obbligatoria e non negoziabile la scrittura di test automatici. Nel tempo, gli sviluppatori si abitueranno a loro. Ciò che ti aiuterà è se riesci a escogitare alcune metriche che mostreranno quanto più nuovo sviluppo è stato fatto e da quanto il numero di bug è stato ridotto da quando hai introdotto i test automatici. Le parole sono volatili. I numeri sono solidi. E i numeri sono qualcosa che uno sviluppatore medio capisce meglio delle parole. Se riesci a provare usando numeri solidi che i test automatici sono buoni, otterrai poca o nessuna resistenza ad essi.

— Vladimir Stokic
fonte

Nella loro mente, se i test falliscono dopo un check-in, è un problema del test e non della modifica del codice ed è solo il nostro progetto giocattolo. Abbiamo discusso più volte se un test fallito è un vero errore. Molte volte lo è.

C'è il tuo problema Se i tuoi test sono traballanti (anche se sono affidabili "la maggior parte delle volte"), le persone tenderanno a ignorare i risultati. Il team di automazione dovrebbe concentrarsi sull'eliminazione di quei falsi negativi. Solo allora il resto della squadra acquisirà abbastanza fiducia nei risultati per fidarsi realmente di loro.

— Eternal21
fonte

Poi di nuovo, potrebbe essere qualcos'altro. Come la resistenza al cambiamento. Se un test fallisce, c'è sempre qualcosa da risolvere, il codice o il test, quindi l'atteggiamento che le persone ignoreranno i test perché i test sono traballanti è fuori luogo.

— Robert Harvey,

Abbiamo parlato con loro quando eravamo sicuri che qualcosa non funzionava (ad esempio Test fallito 3 volte di seguito dopo che il suo check-in ha influito sulla funzionalità in questione). Ma sì, aumentare l'affidabilità è la priorità attuale.

— Peter Schneider,

@PeterSchneider un test può fallire 100 volte di seguito, lo farà specialmente se il test è sbagliato.

— Pieter B,

D'altra parte, un test che non fallisce mai è molto probabilmente completamente inutile

— Vladimir Stokic,

+1 I test fragili sono sicuramente un problema. Gli sviluppatori devono essere convinti che i test che scrivono siano utili, non introducano complicazioni inutili e non siano occupati .

— Andres F.,

Non possiamo e non vogliamo far valere qualcosa.

Dovresti assolutamente farcela! Se qualcuno inserisce un nuovo codice e i test falliscono, il codice dovrebbe essere rifiutato! È l'unico modo per mantenere in modo affidabile un progetto software più ampio.

— Banan
fonte

Immagino che dipenda dal sistema, dai test, dalla scala e dal processo di sviluppo. Non tutti i bug possono essere risolti immediatamente, né tutti i problemi devono essere risolti immediatamente.

— NickL