Il titolo dice tutto. Alcuni dipendenti della nostra azienda ritengono che i test automatici siano "facili" e che "dovrebbero prendere 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. Questo non è il problema. Test e processi automatizzati vengono promossi e richiesti in ogni momento. Il problema è che alcune persone non capiscono che l'automazione non è "facile" né è "veloce".
La prossima volta che ricevi una richiesta prova a suddividere il processo di automazione in blocchi di tempo. Penso che quando realizzeranno che occorrono 5 minuti per campo di testo o pulsante, iniziano a capire quanto tempo ci vuole.
Per esempio, forse perché ci vuole così tanto tempo è che iniziano a introdurre l'interdipendenza tra i campi: ad es. permetti solo loro di procedere se questo è compilato ma non se questo non lo è, tranne quando ....
Cerca di educarli su PERCHÉ ci vuole così tanto tempo, ma non tanto quanto li perdi durante il processo di "apprendimento".
Nei miei ruoli mi sono imbattuto in molte persone "x is easy", in particolare nei progetti di sviluppo. Nella mia mente ci sono tre ragioni per questo:
1) Non capiscono davvero di cosa stiano parlando, ma amano molto suonare come fanno loro.
2) Hanno letto un paio di libri e pensano di sapere di cosa stanno parlando
3) Infine, le persone danno per scontato perché un computer sta facendo il test velocemente, perché i computer sono veloci.
L'unico modo sicuro per combattere questo è di coinvolgere gli utenti su base regolare, le strategie di comunicazione per i progetti sono fondamentali, sicuramente spiegando i dettagli dei test automatizzati agli utenti non tecnici sarà futile ma rendendoli consapevoli di i processi coinvolti possono essere utili. Puoi farlo tramite documentazione, workshop o solo una chat amichevole al prossimo passaggio.
Ho persino visto un BA emettere il più strong tra queste persone "x is easy" e semplicemente invitarle per un giorno nel dipartimento, con il pensiero che se ne andranno o capiranno di più su ciò che fai OPPURE saranno semplicemente venuti via pensando "dio, davvero non so di cosa sto parlando, penso di essermi sbagliato".
Il software è l'attività di automazione delle cose.
Scriviamo software per rendere più noiose le attività noiose, ripetitive e laboriose. Scriviamo software per automatizzare la creazione di report, la raccolta di dati, la comunicazione con altri, ecc. La scrittura di test automatici è in realtà solo la scrittura di software per garantire che il nostro altro software funzioni nel modo in cui ci aspettiamo.
Se i tuoi colleghi comprendono che il software di scrittura è difficile e richiede tempo, dovrebbe essere abbastanza facile mostrare loro che scrivere più software dovrebbe essere difficile e richiedere tempo. Sarebbe bello avere tutti i vantaggi dell'automazione gratuitamente, ma, come sempre, abbiamo bisogno di mettere il lavoro in primo piano per ottenere i benefici più tardi.
Se non lo capiscono, devi lavorare per insegnarglielo o lavorare per migliorare il tuo curriculum.
La maggior parte dei dipendenti trascorre il proprio tempo nella parte "anteriore" (cliente-capo- stakeholder) della società o nel "ritorno" (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 fraintendimenti tra i due gruppi.
Il modo migliore per educare, ad es. "frontali", è di avere uno o alcuni di loro passare un giorno nella "schiena". Se completassero "Un giorno nella vita di ...", avrebbero un'idea più realistica di ciò che può essere fatto in un giorno e perché ci vuole più tempo e sforzi per eseguire test automatici. Allo stesso modo, le persone "dietro" potrebbero trarre beneficio da un giorno o due nel "fronte".
In "Come essere ricco", John Paul Getty (un magnate per il suo tempo) sosteneva un simile "cross training". Dal suo punto di vista, un venditore che passava del tempo sulla catena di montaggio dove il prodotto era fabbricato avrebbe fatto un lavoro molto migliore di vendita, e allo stesso modo un ingegnere che passava un giorno con i clienti avrebbe fatto un lavoro migliore di "debugging".
The issue is that some individuals don't understand that automation is not "easy" nor is it "fast".
Non sono d'accordo con la tua premessa qui.
Sono un grande sostenitore dei test automatici, indipendentemente dal fatto che si tratti di test unitari, test di integrazione o test dell'interfaccia utente. Ci sono molti ottimi strumenti disponibili per implementare test automatici.
Confrontiamo i test automatici con quelli manuali in base all'esempio seguente:
In un'applicazione web, prova la funzionalità "Cambia password" di un utente esistente utilizzando un browser.
Test manuale :
Facile? Non proprio. Ci sono molte possibili insidie nel processo.
veloce? No. Il lavoro manuale richiede tempo.
Ora, proviamo a scrivere un test automatizzato :
Facile? No! Avevamo bisogno di ricercare gli strumenti, implementarli, correggere alcuni bug nei nostri test.
veloce? No! Ci vuole anche più tempo del test manuale.
Ma qui c'è una grande differenza: per i test futuri, devi solo scrivere il test stesso , l'ultimo punto elenco nella lista - che è stato fatto veloce comparabile Tutte le ricerche e gli script di init non devono essere eseguiti per ulteriori test.
E dopo aver scritto il test, puoi iniziare con facilità. In pochi secondi (o forse pochi minuti, se l'avvio del database e l'applicazione web richiedono molto tempo) si vede se la routine "Cambia password" funziona o non funziona. Se c'è un bug, correggilo ed esegui di nuovo il test: immediatamente vedi se il bug è corretto. Veloce e facile .
Scrivere test automatici non è né facile né veloce in primo luogo, ma eseguirli è
E questo è il punto in cui il tempo investito ritorna.
I test in generale non sono facili, né dovrebbero essere. Se la Boeing o la Mercedes non testassero i loro prodotti con la stessa severità con cui lo fanno, allora sarebbero in bancarotta a causa di cause legali o cesseranno l'attività per la vendita di articoli di scarsa qualità. Guideresti con un'auto a 70 miglia all'ora sapendo che il volante potrebbe non 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 dirigenti e dei direttori pensa ai costi e viene giudicata in base a ciò che viene prodotto. L'utilizzo di questi criteri rende molto difficile per loro giustificare il tempo trascorso con i test. Se questo è il tuo caso, dovrai trovare dei modi per presentare questo compito come utile a lungo termine, che naturalmente è.
Solo perché il software non è tangibile non significa che possiamo andare via senza pensare alle implicazioni dei sistemi che non costruiamo. Scommetto che Amazon ha effettuato test automatici e scommetto che ci sono persone che conoscono fin troppo bene le implicazioni sui costi dei loro siti web / servizi che falliscono.
2 +2 = 4 è uno dei pezzi di codice più semplici che tutti comprendono; E puoi vedere come è facile capire. 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 le metodologie di test del software e del software. Il livello di astrazione che richiede un pezzo di codice richiede molto lavoro.
È vero che una buona pratica porta a riutilizzare classi e oggetti ma ugualmente, per raggiungere questo stato è necessario per investire tempo e sforzi .
Ci sono due lati di questa domanda.
Dalla tua parte, sembra che tu stia facendo un buon lavoro e che il gruppo "Automazione è facile" non sappia di cosa stanno parlando.
Dalla loro parte, da quello che dici, vedono i test automatici che richiedono (a loro avviso) molto tempo per produrre.
Da questa distanza, con il poco che dobbiamo andare avanti, non sappiamo chi è "giusto", o se qualcuno è "giusto".
Come gestire l'automazione è una mentalità semplice
Parla con loro. Chiedi onestamente le loro idee su come può essere fatto meglio. Fatti coinvolgere e coinvolgere. È l'unico modo per scoprire se hanno davvero qualcosa di positivo da offrire. Forse hanno dei contributi utili da fare, e puoi ottenere una vittoria / vittoria.
Se non hanno alcuna idea reale di come funzionano la programmazione e le prove automatizzate o di idee realistiche su come migliorare la produttività, dopo averle coinvolte positivamente puoi mostrare come è fatto e dove è il momento. Sii umile e positivo, ringraziandoli per i loro suggerimenti / idee. Pensa a quello che hanno detto: forse i loro suggerimenti attiveranno un modo diverso di pensare per te. Se è così, dai loro quel feedback. Essendo umile e positivo, puoi anche fare una vittoria / vittoria.
Prima di parli con loro pensa a come costruisci, esegui e gestisci i tuoi test. Quali strutture utilizzate? Ci sono altri che potrebbero essere migliori? Avete un boilerplate "standard" che adattate? La creazione dei test potrebbe essere più automatizzata? Cosa ti trattiene?
Leggi altre domande sui tag project-management quality automation