Come rendere popolari i test automatici? [chiuso]

Naviga le tue risposte
13

La nostra base di codici è in crescita da 20 anni. Siamo circa 10 sviluppatori + sqa che lavorano con 500kloc. Qualche tempo fa un piccolo team 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 risolvere il problema e ridurre i falsi positivi e stiamo facendo buoni progressi in questo senso. Ma i dettagli non dovrebbero avere importanza.

Funziona bene e continuiamo a migliorarlo. Noi (la piccola squadra) ci piace molto. Se rompiamo qualcosa, ci accorgiamo il giorno dopo e non 2 mesi dopo quando sqa dà un'occhiata. Inoltre, i nostri manager (dev + sqa) amano l'idea. Ma le altre persone del team ignorano semplicemente i risultati del test. Nella loro mente, se i test falliscono dopo un check-in, è un problema del test e non del cambio di codice ed è solo il nostro progetto giocattolo. Abbiamo discusso diverse volte se un test in errore è un errore reale. La maggior parte delle volte lo è.

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

    
posta Peter Schneider 12.10.2017 - 20:58
fonte

3 risposte

4

responsabilità

Anche se potrei sembrare un manager, ho scritto questo come sviluppatore che doveva anche essere convinto che i test automatici sono buoni.

Devi capire la psicologia di base degli sviluppatori. È un bisogno radicato 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, quindi è una cosa brutta. Da qui la resistenza.

Quello che devi sottolineare è che, mentre i test automatici li rallentano a breve termine, alla lunga li salverà un sacco di dolore e in realtà li accelera, perché saranno in grado di concentrarsi maggiormente su lo 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 la scrittura di test automatici obbligatori e non negoziabili. Col tempo, gli sviluppatori si abitueranno a loro. Ciò che può essere d'aiuto è se puoi escogitare alcune metriche che mostrino 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 dimostrare di utilizzare numeri solidi che i test automatici sono buoni, non avrai alcuna resistenza da parte loro.

    
risposta data 13.10.2017 - 10:09
fonte
11

In their mind, if tests are failing after a checkin, it's a problem of the test and not of the code change and it's just our toy project. We had discussions several times if a failing test is a real error. Most times it is.

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

    
risposta data 12.10.2017 - 21:22
fonte
6

We can't and don't want to enforce something.

Dovresti sicuramente applicarlo! Se qualcuno spinge un nuovo codice e i test falliscono, il codice dovrebbe essere rifiutato! È l'unico modo per gestire in modo affidabile un progetto software più ampio.

    
risposta data 13.10.2017 - 09:34
fonte

Leggi altre domande sui tag

Nel concatenare i valori letterali stringa adiacenti XSLT e possibili alternative [chiuso]