Quattro candidati al QA su cinque vogliono imparare a lavorare con i test automatizzati. Non tutte le aziende possono soddisfare tali desideri dei tester manuali durante l'orario di lavoro. Wrike ha tenuto una scuola di automazione per i dipendenti e ha realizzato questo desiderio di molti. Ho partecipato a questa scuola proprio come studentessa QA.
Ho imparato a lavorare con Selenium e ora supporto in modo indipendente un certo numero di autotest praticamente senza alcun aiuto esterno. E, sulla base dei risultati della nostra esperienza congiunta e delle mie conclusioni personali, cercherò di ricavare la formula stessa per la scuola di automazione più ideale.
L'esperienza di Wrike nell'organizzazione di una scuola
Quando la necessità di una scuola di automazione divenne chiara, la sua organizzazione passò a Stas Davydov, responsabile tecnico dell’automazione. Chi altri se non lui può spiegare perché hanno ideato questa iniziativa, se hanno ottenuto risultati e se si pentono del tempo impiegato? Diamogli la parola:
— Nel 2016 abbiamo scritto un nuovo framework per gli autotest e abbiamo fatto in modo che diventasse facile scrivere i test: sono comparsi passaggi normali, la struttura è diventata molto più comprensibile. Ci è venuta un'idea: dobbiamo coinvolgere tutti coloro che vogliono scrivere nuovi test e, per facilitarne la comprensione, abbiamo creato un ciclo di lezioni. Abbiamo elaborato collettivamente un piano di argomenti, ciascuno dei futuri docenti ne ha preso uno per sé e ha preparato una relazione al riguardo.
— Quali difficoltà hanno avuto gli studenti?
— Principalmente, ovviamente, l'architettura. C'erano molte domande sulla struttura dei nostri test. Nel feedback è stato scritto molto su questo argomento e abbiamo dovuto tenere ulteriori lezioni per spiegarlo in modo più dettagliato.
— La scuola ha dato i suoi frutti?
- Sì, sicuramente. Grazie a lei, molte persone sono state coinvolte nella scrittura dei test e, in media, in ospedale tutti hanno iniziato a capire meglio cosa sono gli autotest, come vengono scritti e come vengono lanciati. Anche il carico sugli ingegneri dell'automazione è diminuito: ora riceviamo molte meno richieste di aiuto nell'analisi dei test, poiché tester e sviluppatori hanno iniziato a farcela da soli in quasi tutte le situazioni. Ebbene, ci sono diversi vantaggi interni per il dipartimento: abbiamo acquisito esperienza in presentazioni e lezioni, grazie alla quale alcuni ingegneri dell'automazione sono già riusciti a fare presentazioni alle conferenze, e abbiamo anche ricevuto un potente set di video e presentazioni per l'onboarding dei nuovi arrivati.
A nome mio, aggiungerò che la comunicazione tra i nostri dipartimenti è stata semplificata a un livello assolutamente ridicolmente semplice. Ad esempio, ora praticamente non ho bisogno di pensare a quali casi e a quale livello di atomicità automatizzare. Di conseguenza, tutte le parti interessate si prendono cura della copertura dei test, che è in costante crescita. Nessuno pretende l’impossibile dagli altri.
In generale, l’impatto sul lavoro dei team è decisamente positivo. Forse anche i colleghi che leggono questo articolo stanno pensando di fare qualcosa di simile? Allora il consiglio sarà semplice: ne vale la pena se per te i test automatizzati sono una priorità. Successivamente parleremo di una questione più complessa: come organizzare tutto questo nel modo più corretto possibile, in modo che i costi di tutte le parti siano minimi e il risultato sia massimo.
Suggerimenti per l'organizzazione
La scuola era utile, ma, come ammetteva Stas, c'erano alcune difficoltà, per cui era necessario organizzare lezioni aggiuntive. Ed è stato quando uno studente recente ha confrontato me stesso nell'ignoranza e me stesso ora che ho formulato i seguenti passaggi per creare, a mio avviso, il modo ideale per insegnare ai tester a comprendere i test automatizzati.
Passaggio 0. Crea un dizionario
Naturalmente, questo passaggio è necessario non solo per il QA. Tuttavia, voglio che sia esplicito: il codice di automazione deve essere mantenuto in forma leggibile. Linguaggi di programmazione - non ultimo lingue, e da qui potrai iniziare la tua immersione.
Ecco uno screenshot di una visualizzazione attività con i nomi degli elementi. Immaginiamo che tu stia testando TaskView come una scatola nera e non hai mai visto il selenio in vita tua. Cosa fa questo codice?
(Spoiler: l'attività viene eliminata tramite rest per conto dell'amministratore e quindi vediamo che ce n'è una registrazione nello stream.)
Questo passo da solo avvicina i linguaggi QAA e QA. È più semplice per i team di automazione spiegare i risultati di un'esecuzione; i tester manuali devono dedicare meno sforzi alla creazione dei casi: possono essere resi meno dettagliati. Eppure tutti si capiscono. Abbiamo ricevuto le vincite ancor prima che iniziasse la formazione vera e propria.
Passaggio 1. Ripeti le frasi
Continuiamo il parallelo con il linguaggio. Quando impariamo a parlare da bambini, non partiamo dall’etimologia e dalla semantica. Ripetiamo “mamma”, “compra un giocattolo”, ma non entriamo subito nelle radici proto-indoeuropee di queste parole. Anche qui è così: è inutile tuffarsi nel profondo delle caratteristiche tecniche degli autotest senza provare a scrivere qualcosa che funzioni.
Sembra un po’ controintuitivo, ma funziona.
Nella prima lezione vale la pena fornire le basi su come scrivere direttamente gli autotest. Aiutiamo a configurare l'ambiente di sviluppo (nel mio caso, Intellij IDEA), spieghiamo le regole linguistiche minime necessarie per scrivere un altro metodo in una classe esistente utilizzando i passaggi esistenti. Scriviamo con loro uno o due test e diamo loro dei compiti, che io formatterei così: dal master si dirama un ramo, ma da esso sono stati rimossi diversi test. Rimangono solo le loro descrizioni. Chiediamo ai tester di ripristinare questi test (non tramite show diff, ovviamente).
Di conseguenza, colui che ha ascoltato e fatto tutto sarà in grado di:
- imparare a lavorare con l'interfaccia dell'ambiente di sviluppo: creazione di rami, tasti di scelta rapida, commit e push;
- padroneggiare le basi della struttura del linguaggio e delle classi: dove inserire le iniezioni e dove importare, perché sono necessarie le annotazioni e che tipo di simboli si trovano lì, oltre ai passaggi;
- comprendere la differenza tra azione, attesa e verifica, dove usare cosa;
- notare la differenza tra autotest e controlli manuali: negli autotest è possibile estrarre l'uno o l'altro gestore invece di eseguire azioni tramite l'interfaccia. Ad esempio, invia un commento direttamente al backend invece di aprire una visualizzazione attività, selezionare l'input, digitare testo e fare clic sul pulsante Invia;
- formulare domande a cui verrà data risposta nel passaggio successivo.
L'ultimo punto è molto importante. Queste risposte possono essere facilmente fornite in anticipo, ma è un importante principio didattico che le risposte senza domande formulate non vengano ricordate e non vengano utilizzate quando finalmente necessarie.
L'ideale sarebbe se in questo momento un ingegnere dell'automazione del team QA gli assegnasse il compito di scrivere un paio di test in battaglia e gli permettesse di sottomettersi al suo ramo.
Cosa non regalare:
- conoscenza più approfondita delle funzionalità dell'ambiente di sviluppo e del linguaggio di programmazione stesso, che sarà necessaria solo quando si lavora con le filiali in modo indipendente. Non verrà ricordato, dovrai spiegarlo due o tre volte, ma diamo valore al tempo degli ingegneri dell’automazione, giusto? Esempi: risolvere conflitti, aggiungere file a Git, creare classi da zero, lavorare con le dipendenze;
- tutto ciò che riguarda xpath. Sul serio. Devi parlarne separatamente, una volta e in modo molto concentrato.
Passaggio 2. Uno sguardo più approfondito alla grammatica
Ricordiamo lo screenshot della visualizzazione attività del passaggio n. 0. Abbiamo un passaggio chiamato checkCommentWithTextExists. Il nostro tester capisce già cosa fa questo passaggio e possiamo guardarlo all'interno e scomporlo un po'.
E all'interno abbiamo quanto segue:
onCommentBlock(userName).comment(expectedText).should(displayed());Dove si trova onCommentBlock
onCommonStreamPanel().commentBlock(userName);Ora impariamo a dire non “compra un giocattolo”, ma “compra un giocattolo dal negozio Detsky Mir, situato nell’armadietto blu sul terzo ripiano dall’alto”. È necessario spiegare che indichiamo un elemento in sequenza, da elementi più grandi (stream -> blocco con commenti di una determinata persona -> quella parte di questo blocco dove si trova il testo specificato).
No, non è ancora il momento di parlare di xpath. Basta menzionare brevemente che tutte queste istruzioni sono descritte da loro e l'ereditarietà passa attraverso di loro. Ma di tutti questi matcher e camerieri bisogna parlare, riguardano proprio questo passaggio e sono necessari per capire cosa sta succedendo. Ma non sovraccaricarti: il tuo studente potrà studiare da solo le asserzioni più complesse in seguito. Molto probabilmente, waitUntil,display();,exist();,not(); dovrebbero essere sufficienti.
Il compito è ovvio: un ramo in cui sono stati rimossi i contenuti di alcuni passaggi necessari per un certo numero di test. Lascia che i tester li ripristini e rendano la corsa di nuovo verde.
Inoltre, se il team di testing non ha solo nuove funzionalità nel suo lavoro, ma anche alcune correzioni di bug, puoi chiedergli di scrivere immediatamente dei test per questi bug e di rilasciarli. Molto probabilmente tutti gli elementi sono già stati descritti; potrebbero mancare solo un paio di passaggi. Questo sarà l'allenamento perfetto.
Passaggio 3. Immersione completa
Il più completo possibile per un tester che continuerà a svolgere i suoi compiti diretti. Infine, dobbiamo parlare di xpath.
Innanzitutto, chiariamo che tutti questi onCommentBlock e comment sono descritti da loro.
Totale:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"L'ordine della storia è molto importante. Innanzitutto, prendiamo qualsiasi XPath esistente e mostriamo come la scheda Elements contenga uno e un solo elemento. Successivamente parleremo della struttura: quando è necessario utilizzare WebElement e quando è necessario creare un file separato per un nuovo elemento. Ciò ti consentirà di comprendere meglio l'ereditarietà.
Deve essere dichiarato esplicitamente che un singolo elemento è l'intera visualizzazione attività, contiene un elemento figlio - l'intero flusso, che contiene un elemento figlio - un commento separato, ecc. Gli elementi figlio si trovano all'interno degli elementi genitore sia sulla pagina che nella struttura del framework di autotest.
A questo punto, il pubblico dovrebbe aver capito bene come vengono ereditati e cosa può essere inserito dopo il punto in onCommentBlock. A questo punto spieghiamo tutti gli operatori: /, //, ., [] e così via. Aggiungiamo la conoscenza sull'uso nel carico @class e altre cose necessarie.
Gli studenti dovrebbero capire come tradurre xpath in questo modo. Per consolidare: esatto, compiti a casa. Eliminiamo le descrizioni degli elementi, lasciamo che ripristini il lavoro dei test.
Perchè questo particolare percorso?
Non dovremmo sovraccaricare una persona con conoscenze complesse, ma dobbiamo spiegare tutto in una volta, e questo è un dilemma difficile. Questo percorso ci permetterà prima di far sì che gli ascoltatori facciano domande e non capiscano qualcosa e di rispondere il momento successivo. Se parli dell'intera architettura, quando verrà analizzato l'argomento Steps o XPath, le sue parti più importanti saranno già dimenticate a causa della loro incomprensibilità.
Tuttavia, alcuni di voi probabilmente saranno in grado di condividere la propria esperienza su come ottimizzare ulteriormente il processo. Sarò felice di leggere suggerimenti simili nei commenti!
Fonte: habr.com