Come affrontare la mentalità "L'automazione è facile"?

Il titolo dice tutto. Alcuni dipendenti della nostra azienda ritengono che i test automatizzati siano "facili" e che "dovrebbe richiedere un giorno" per scrivere suite di test COM e UI. Cosa si può fare per contrastare questo?

Nota: non sto chiedendo come promuovere l'automazione. Non è questo il problema. Test e processi automatizzati vengono promossi e richiesti in ogni momento qui. Il problema è che alcune persone non capiscono che l'automazione non è "facile" né "veloce".

La prossima volta che ricevi una richiesta, prova a scomporre gran parte del processo di automazione in blocchi di tempo. Penso che quando si rendono conto che ci vogliono 5 minuti per campo di testo o pulsante, iniziano a rendersi conto di quanto tempo impiega.

Ad esempio, forse perché ci vuole così tanto tempo è che iniziano a introdurre l'interdipendenza tra i campi: ad es. Consentire loro di procedere solo se questo è compilato, ma non se ciò non lo è, tranne quando ...

Cerca di educarli sul PERCHÉ ci vuole così tanto tempo, ma non tanto quanto li perdi attraverso il processo di "apprendimento".

Nei miei ruoli mi sono imbattuto in molte persone "x is easy" soprattutto nei progetti di sviluppo. Nella mia mente ci sono tre ragioni per questo:

1) Davvero non capiscono di cosa stiano parlando, ma piace molto sembrare come loro.

2) Hanno letto un paio di libri e pensano di sapere di cosa stanno parlando

3) Infine le persone assumono perché un computer sta eseguendo i test velocemente, perché i computer sono veloci.

L'unico modo sicuro per combattere questo è coinvolgere gli utenti su base regolare, le strategie di comunicazione per i progetti sono fondamentali, sicuramente spiegare i dettagli dei test automatizzati agli utenti non tecnici sarà inutile ma rendendoli consapevoli dei processi coinvolti può essere utile. Puoi farlo tramite documentazione, workshop o semplicemente una chat amichevole la prossima volta che passi.

Ho anche visto un BA individuare il più forte di queste persone "x is easy" e semplicemente invitarle per un giorno nel dipartimento, con il pensiero che o se ne andranno capendo di più su quello che fai OPPURE semplice vieni via pensando "Dio non so proprio di cosa sto parlando, penso di aver sbagliato".

Il software è il compito di automatizzare le cose.

Scriviamo software per semplificare le attività noiose, ripetitive e ad alta intensità di lavoro. Scriviamo software per automatizzare la creazione di report, la raccolta di dati, la comunicazione con gli altri, ecc. Scrivere test automatici è in realtà solo scrivere software per assicurarsi che il nostro altro software funzioni come ci aspettiamo.

Se i tuoi colleghi comprendono che scrivere software è difficile e richiede tempo, dovrebbe essere abbastanza facile mostrare loro che scrivere più software dovrebbe essere difficile e richiedere tempo. Sarebbe bello ottenere gratuitamente tutti i vantaggi dell'automazione, ma, come sempre, dobbiamo anticipare il lavoro per ottenere i benefici in un secondo momento.

Se non lo capiscono, o devi lavorare per insegnarglielo o per lucidare il tuo curriculum.

La maggior parte dei dipendenti trascorre il proprio tempo nella parte "anteriore" (cliente-capo-parti interessate) della società o nella parte "posteriore" (dove viene svolto il lavoro "reale"). Queste due funzioni sono diverse, quasi opposte. (E pochissime persone hanno lavorato in entrambi). Di conseguenza, ci sono spesso incomprensioni tra i due gruppi.

Il modo migliore per educare, ad esempio, le persone "frontali", è far sì che una o alcune persone trascorrano una giornata nella "parte posteriore". Se completassero "Un giorno nella vita di ...", avrebbero un'idea più realistica di cosa si può fare in un giorno e perché ci vogliono più tempo e sforzi per eseguire test automatici. Allo stesso modo, le persone "posteriori" potrebbero beneficiare di un giorno o due al "fronte".

In "Come essere ricchi", John Paul Getty (un magnate per il suo tempo) ha sostenuto tale "allenamento incrociato". A suo avviso, un venditore che trascorreva del tempo sulla catena di montaggio in cui veniva fabbricato il prodotto avrebbe svolto un lavoro di vendita molto migliore, e allo stesso modo un ingegnere che aveva trascorso una giornata con i clienti avrebbe svolto un lavoro migliore di "debug".

Il problema è che alcune persone non capiscono che l'automazione non è "facile" né "veloce".

Non sono d'accordo con la tua premessa qui.

Sono un grande sostenitore dei test automatizzati, non importa se si tratta di test unitari, test di integrazione o test dell'interfaccia utente. Ci sono molti ottimi strumenti disponibili per implementare test automatici.

Confrontiamo i test automatizzati con i test manuali basati sul seguente esempio:

In un'applicazione Web, testare la funzionalità "Cambia password" di un utente esistente utilizzando un browser.

Test manuale :

• Avvia l'applicazione Web
• Apri il browser
• Accidenti, c'è un errore. Perché? Oh, ho dimenticato di avviare il database!
• Ok, chiudi l'applicazione web
• Avvia il database
• Avvia l'applicazione Web
• Aggiorna il browser
• Hmm, qual era di nuovo la password del nostro utente test?
• Dai un'occhiata al database
• Oh, la tabella degli utenti è vuota! Devo creare un nuovo utente.
• Registrare un nuovo utente nell'applicazione Web: immissione di nome utente, password, indirizzo e-mail
• Perché non riesco ad accedere con il mio nuovo utente? Oh, devo fare clic sul link di conferma nell'email!
• Bene, ho dato all'utente un'e-mail come "test@example.com". Andiamo al database e impostiamo la colonna "attiva" su "Sì".
• Accesso. Questa volta funziona!
• Hmm, cosa volevo testare di nuovo ...?

Facile? Non proprio. Ci sono molte possibili insidie ​​nel processo.

Veloce? No. Il lavoro manuale richiede tempo.

Ora, proviamo a scrivere un test automatizzato :

• Dobbiamo trovare gli strumenti per il nostro linguaggio di programmazione per avviare automaticamente il database e il web server. La ricerca e l'implementazione richiedono tempo.
• Il database deve essere in uno stato pulito all'avvio del test. La creazione degli script richiede tempo.
• Dobbiamo scrivere il test. Poiché abbiamo bisogno di un utente, dobbiamo anche registrarne uno nuovo per il nostro test. Ci vuole tempo.
• Finalmente, possiamo scrivere ciò che vogliamo testare: cambiare la password dell'utente. Con il nostro strumento di test del browser, questo viene fatto abbastanza rapidamente rispetto alle attività precedenti.

Facile? No! Avevamo bisogno di ricercare gli strumenti, implementarli, correggere alcuni bug nei nostri test.

Veloce? No! Ci vuole anche più tempo di un test manuale.

Ma qui c'è una grande differenza: per i test futuri, devi solo scrivere il test stesso , l'ultimo punto elenco nell'elenco - che è stato fatto velocemente alla pari. Non è necessario eseguire tutti gli script di ricerca e init per ulteriori test.

E dopo aver scritto il test, puoi avviarlo facilmente. In pochi secondi (o forse minuti, se l'avvio del database e l'applicazione web impiegano molto tempo) si vede se la routine "Cambia password" funziona o no. Se è presente un errore, correggilo ed esegui nuovamente il test: vedrai immediatamente se l'errore è stato corretto. Facile e veloce .

Scrivere test automatizzati non è né facile né veloce in primo luogo, ma eseguirli lo è.

E questo è il punto in cui ritorna il tempo investito.

Testare in generale non è facile, né dovrebbe esserlo. Se Boeing o Mercedes non avessero testato i loro prodotti in modo rigoroso come loro, sarebbero stati in bancarotta a causa di azioni legali o sarebbero andati fuori mercato per la vendita di articoli di scarsa qualità. Guideresti un'auto a 70 miglia all'ora sapendo che il volante può o non può cadere a pezzi?

È molto difficile suggerire modi per affrontare la mentalità senza capire chi siano queste persone o le loro ragioni. La maggior parte dei manager e dei direttori pensa ai costi e viene giudicata da ciò che viene prodotto. L'uso di questi criteri rende molto difficile per loro giustificare il tempo dedicato ai test. Se questo è il tuo caso, dovrai trovare modi per presentare questo compito come benefico a lungo termine, che ovviamente lo è.

Solo perché il software non è tangibile non significa che possiamo cavarcela senza pensare alle implicazioni che i sistemi che costruiamo non funzionano. Scommetto che Amazon ha test automatizzati e scommetto che ci sono persone che conoscono fin troppo bene le conseguenze sui costi del fallimento dei loro siti Web / servizi.

2 +2 = 4 è uno dei codici più semplici che tutti capiscono; E puoi vedere come è facilmente comprensibile. Ma questo non significa che sia un'equazione "facile". Il livello di astrazione necessario per raggiungere l'equazione semplice è piuttosto complesso. Lo stesso accade con il software e le metodologie di test del software. Il livello di astrazione che richiede un pezzo di codice richiede molto lavoro.

È vero che una buona pratica porta al riutilizzo di classi e oggetti ma allo stesso modo, per raggiungere questo stato è necessario investire tempo e fatica .

Ci sono due lati di questa domanda.

Da parte tua, sembra che tu stia facendo un buon lavoro e che il gruppo "L'automazione è facile" non sappia di cosa stiano parlando.

Da parte loro, da quello che dici, vedono i test automatici richiedere (a loro avviso) molto tempo per produrre.

Da questa distanza, con il poco che dobbiamo andare avanti, non sappiamo chi è "giusto" o se qualcuno ha "ragione".

Come gestire l'automazione è una mentalità semplice

Parla con loro. Chiedi onestamente le loro idee su come fare meglio. Falli coinvolgere e coinvolgere. È l'unico modo per scoprire se hanno davvero qualcosa di positivo da offrire. Forse hanno dei contributi utili da dare e puoi ottenere una vittoria / vittoria.

Se non hanno alcuna idea reale di come funzionano i test di programmazione e automatizzati o idee realistiche su come migliorare la produttività, dopo averli coinvolti in modo positivo puoi mostrare come è fatto e dove va il tempo. Sii umile e positivo, ringraziandoli per il loro contributo / idee. Pensa a quello che hanno detto: forse i loro suggerimenti attiveranno un modo diverso di pensare per te. In tal caso, dai loro quel feedback. Essendo umile e positivo puoi renderlo anche una vittoria.

Prima di parlare con loro, pensa a come costruisci, esegui e gestisci i tuoi test. Che framework stai usando? Ce ne sono altri che potrebbero essere migliori? Avete una piastra "standard" che adattate? La costruzione dei test potrebbe essere più automatizzata? Cosa ti trattiene?